From owner-ipsec@lists.tislabs.com Thu Nov 1 07:01:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1F1V819208; Thu, 1 Nov 2001 07:01:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15111 Thu, 1 Nov 2001 08:42:47 -0500 (EST) Message-ID: <3BE09989.D3771A59@cisco.com> Date: Wed, 31 Oct 2001 19:38:33 -0500 From: Leo Temoshenko X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning CC: john.shriver@intel.com, rks@cisco.com, ipsec@lists.tislabs.com, leot@cisco.com Subject: Re: Status of ID: IPsec Flow Monitoring MIB References: <3BDF4442.C8FAFF83@cisco.com> <15328.12958.21408.546543@pkoning.dev.equallogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Everyone represents themselves as individuals in the IETF WG discussions as opposed to representing companies/vendors/organizations/etc. We are all equals in helping to influence the future. In reality or perception, this may not be totally true. Thus I would like to make it quite clear that I was representing MY opinions and NOT claiming to represent any company (Cisco) as Paul states. And take full responsibility for MY comments. If my comments where found offensive, please accept my sincere apology. The comment that Paul points out was actually meant to be a complement to John Shriver (who I have great respect for), but I can understand how it could be viewed otherwise. I sincerely believe in IPsec and want to see it be VERY successful, but believe strongly that the management direction has major problems. Paul Koning wrote: > > >>>>> "Leo" == Leo Temoshenko writes: > > Leo> I believe all of points were addressed by rks in his response to > Leo> Tim Jenkins (timestamp Tue, 30 Oct 2001 12:21:11 -0800). His > Leo> responses were great and right-on-the-money. > > Leo> I would like to add several comments... > > Leo> 1) Your note is very interesting and touching. It covers all > Leo> the points that one learns in an "how to influence others" class > Leo> - fear, justification, authorization advice and ends with > Leo> sympathy. Very nice. > > I've been watching this argument for a while now. > > Frankly, a lot of it has been at a level that prompts me to reach for > the Delete key right away. I haven't been able to find much substance > in between all the childish remarks, unfortunately. In particular, > I've seen a lot of messages that are not even close to the level of > maturity and technical substance one would expect to see from people > who claim to represent Cisco. > > It may help feed your own sense of self-importance to write comments > such as the one quoted above, but it does not help at all in advancing > your argument to a disinterested observer. If you have a desire to > influence the direction of the group, maybe you should have a > conversation with some of your more senior colleagues on what to do > and what not to do in IETF WG interactions. > > paul From owner-ipsec@lists.tislabs.com Thu Nov 1 07:01:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1F1W819216; Thu, 1 Nov 2001 07:01:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15227 Thu, 1 Nov 2001 09:12:56 -0500 (EST) X-Originating-IP: [63.114.32.70] From: "cliff wang" To: ipsec@lists.tislabs.com Subject: RE: Status of ID: IPsec Flow Monitoring MIB Date: Wed, 31 Oct 2001 19:51:15 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Oct 2001 19:51:15.0540 (UTC) FILETIME=[6685E140:01C16245] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can't agree more. The mailing list should only be used for technical discussion. unfortunately, people takes his personality into the discussion, poisoning both the list and his company. -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Wednesday, October 31, 2001 12:19 PM To: leot@cisco.com Cc: john.shriver@intel.com; rks@cisco.com; ipsec@lists.tislabs.com Subject: Re: Status of ID: IPsec Flow Monitoring MIB >>>>>"Leo" == Leo Temoshenko writes: Leo> I believe all of points were addressed by rks in his response to Leo> Tim Jenkins (timestamp Tue, 30 Oct 2001 12:21:11 -0800). His Leo> responses were great and right-on-the-money. Leo> I would like to add several comments... Leo> 1) Your note is very interesting and touching. It covers all Leo> the points that one learns in an "how to influence others" class Leo> - fear, justification, authorization advice and ends with Leo> sympathy. Very nice. I've been watching this argument for a while now. Frankly, a lot of it has been at a level that prompts me to reach for the Delete key right away. I haven't been able to find much substance in between all the childish remarks, unfortunately. In particular, I've seen a lot of messages that are not even close to the level of maturity and technical substance one would expect to see from people who claim to represent Cisco. It may help feed your own sense of self-importance to write comments such as the one quoted above, but it does not help at all in advancing your argument to a disinterested observer. If you have a desire to influence the direction of the group, maybe you should have a conversation with some of your more senior colleagues on what to do and what not to do in IETF WG interactions. paul _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ipsec@lists.tislabs.com Thu Nov 1 09:04:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1H4I802260; Thu, 1 Nov 2001 09:04:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15372 Thu, 1 Nov 2001 10:59:19 -0500 (EST) From: "Joseph D. Harwood" To: "Ipsec" Subject: Sequence Number Extension Date: Thu, 1 Nov 2001 08:07:49 -0800 Message-ID: <000401c162ef$5a102d80$c7d0fea9@vesta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In this document: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt It says: "As a result, iSCSI, iFCP and FCIP implementations operating at speeds of 1 Gbps or less MAY implement the IPsec sequence number extension, described in [49]. 10 Gbps or faster implementations SHOULD implement the extension specification." [49] is: Steve Kent, IPsec sequence number extension proposal, IETF 50. Has any work been done on this since IETF 50? Is there draft text for it yet? Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com From owner-ipsec@lists.tislabs.com Thu Nov 1 09:21:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA1HL0802721; Thu, 1 Nov 2001 09:21:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15410 Thu, 1 Nov 2001 11:29:44 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <000401c162ef$5a102d80$c7d0fea9@vesta> References: <000401c162ef$5a102d80$c7d0fea9@vesta> Date: Thu, 1 Nov 2001 11:35:25 -0500 To: "Joseph D. Harwood" From: Stephen Kent Subject: Re: Sequence Number Extension Cc: "Ipsec" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:07 AM -0800 11/1/01, Joseph D. Harwood wrote: >In this document: > >http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt > > >It says: > >"As a result, iSCSI, iFCP and FCIP implementations operating at speeds of 1 >Gbps or less MAY implement the IPsec sequence number extension, described in >[49]. 10 Gbps or faster implementations SHOULD implement the extension >specification." > > >[49] is: > >Steve Kent, IPsec sequence number extension proposal, IETF 50. > > >Has any work been done on this since IETF 50? Is there draft text for it >yet? > > >Best Regards, >Joseph D. Harwood >(408) 838-9434 >jharwood@vesta-corp.com >www.vesta-corp.com I am currently editing a revised ESP document which includes extended sequence number support, which accommodates combined encryption/integrity mode algorithms, and which includes some new features for traffic flow confidentiality. I plan to submit it in time for the next IETF meeting, i.e., post it next week. Steve From owner-ipsec@lists.tislabs.com Fri Nov 2 09:59:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2HxR805919; Fri, 2 Nov 2001 09:59:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21727 Fri, 2 Nov 2001 11:42:19 -0500 (EST) Message-ID: <003001c163bf$f2fc02f0$032745ab@sfanninglaptop> From: "Scott Fanning" To: Subject: Status of draft-ietf-ipsec-ike-lifetime-00.txt Date: Fri, 2 Nov 2001 09:01:00 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C1637C.E4A94E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C1637C.E4A94E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I will be updating this document to fix the DOI to IPsec in Section 4. = Are there any other comments about the draft? Regards Scott ------=_NextPart_000_002D_01C1637C.E4A94E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I will be updating this document to fix = the DOI to=20 IPsec in Section 4. Are there any other comments about the = draft?
 
Regards
Scott
------=_NextPart_000_002D_01C1637C.E4A94E80-- From owner-ipsec@lists.tislabs.com Mon Nov 5 11:33:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5JXO812077; Mon, 5 Nov 2001 11:33:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA27056 Mon, 5 Nov 2001 13:07:26 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Mason, David'" , "'Marco Ender'" , Subject: RE: IKE encryption in aggressive mode Date: Sun, 4 Nov 2001 18:06:09 -0500 Message-Id: <000101c16625$88942d80$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <8894CA1F87A5D411BD24009027EE783812835A@ROC-76-204.nai.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In light of the weakness of the phase 1 authentication hash, encrypting the third message provides at least some assurance that a notify payload (e.g. initial contact) was not forged. Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mason, David > Sent: Monday, October 22, 2001 5:10 AM > To: 'Marco Ender'; ipsec@lists.tislabs.com > Subject: RE: IKE encryption in aggressive mode > > > RFC 2409: The final message MAY NOT be sent under protection > of the ISAKMP > SA allowing each party to postpone exponentiation, ... The graphic > depictions of Aggressive Mode show the final payload in the > clear; it need > not be. > > So the third message may or MAY NOT be encrypted. The > preferred method is > not to encrypt since it provides not benefit except perhaps > for Signatures > where the certificate identity of the Initiator is protected > (but if that > property is desired then Main Mode w/ Identity protection is > available). > > -dave > > -----Original Message----- > From: Marco Ender [mailto:marco.ender@dungeonmaster.at] > Sent: Saturday, October 20, 2001 10:33 AM > To: ipsec@lists.tislabs.com > Subject: IKE encryption in aggressive mode > > > I have a small question regarding the point at which the encryption > using SKEYID_e starts in aggressive mode. In Main Mode, all parts of > the pakets 4 & 5 are encrypted using the SKEYID_e. Which parts of the > _second_ paket in Aggressive Mode are encrpted using SKEYID_e with > each authentication method? Am i correct that again the complete third > paket is encrypted using SKEYID_e? > > tia > > Marco > From owner-ipsec@lists.tislabs.com Tue Nov 6 00:32:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA68W1812884; Tue, 6 Nov 2001 00:32:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01947 Tue, 6 Nov 2001 02:35:28 -0500 (EST) Reply-To: From: "Masafumi Tsuruta" To: Subject: Flag Field of ISAKMP header Date: Tue, 6 Nov 2001 16:37:45 +0900 Message-ID: <000201c16695$edf8f280$8300a8c0@tsuruta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all. I 'm Japanese and not good at English. Sorry. I have some questions about Flags field of ISAKMP header. In ISAKMP header, we have 3 bit-fields, "Encryption Bit" "Commit Bit" "Authentication Only Bit". In the case of Commit Bit, a merit we receive is at least one point I think. 1) It is used to ensure that encrypted material is not received prior to completion of the SA establishment. That is , in short, the merit is notifying the finishing of receipt all payload before making complete SA establishment. But in the case of not to use Commit Bit, I think the negotiation will be running smoothly because of Commit Bit is optional flag. In RFC 2408 section 3.1 means Commit Bit setting is either will do (i.e. that is optional). However Commit Bit is in the Flag field, actually. So it must be clearly merits of the existance, which is not the above. So please tell me another merits of Commit Bit existence. And also in the Authentication Only Bit case, what are the merits we set the Authentication Only Bit for non-encrypted payload send? In addition, I don't know Emergency Mode, too. What is this mode? Please give me any suggestion or comments about these points(such as URLs, RFCs). At last, If someone knows about security related problems (or solution) about these Commit Bit, Authentication Only Bit, and all over Flag field. Please tell me. Thank you very much. Masafumi Tsuruta tsuruta@insi.co.jp From owner-ipsec@lists.tislabs.com Tue Nov 6 23:27:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA77RO827186; Tue, 6 Nov 2001 23:27:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06076 Wed, 7 Nov 2001 01:16:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message Subject: RE: NAT traversal documents: are we close to done? Date: Tue, 6 Nov 2001 22:24:09 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE68B5@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: NAT traversal documents: are we close to done? thread-index: AcFiHeIeqslEIus9S6qfJz1ro/2skwFNfNFA From: "William Dixon" To: "Markus Stenberg" , X-OriginalArrivalTime: 07 Nov 2001 06:24:11.0166 (UTC) FILETIME=[D03D0BE0:01C16754] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There may be a clarification required for how UDP-ESP implementations should attempt to use this mode to pass through an "IPsec aware NAT", one that is tracking UDP 500 cookie session state, and for perhaps several reasons drop the UDP-ESP packets. I'd like to discuss one solution after my test results with the authors first, probably by end of week, then post the detail to the list. Interesting our original premise - don't change NATs, and the NATs changed.... Many of them do this IPSec passthrough mode for the IPSec tunnel mode clients. They can obviously change again, but now there's a generation of NATs out there with this issue. -----Original Message----- From: Markus Stenberg [mailto:mstenber@ssh.com] Sent: Tuesday, October 30, 2001 11:43 PM To: ipsec@lists.tislabs.com Subject: Re: NAT traversal documents: are we close to done? paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > Greetings again. The past few weeks have seen new drafts for the two > main NAT traversal documents, draft-ietf-ipsec-nat-t-ike-01.txt > (Negotiation of NAT-Traversal in the IKE and > draft-ietf-ipsec-udp-encaps-01.txt (UDP Encapsulation of IPsec > Packets). Are there any outstanding issues on them? Might we have > these finished soon? I believe they're done (although we noted later on that our Expires: header in the draft-ietf-ipsec-nat-t-ike-01 looks amusing, but apparently it's not checked by anyone ;->). At least, those are all to-do items related to drafts that I know of (the IKE draft contains few clarifications and udp-encap draft removed AH support and had some clarifications). > --Paul Hoffman, Director > --VPN Consortium -Markus From owner-ipsec@lists.tislabs.com Wed Nov 7 12:21:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA7KLN810781; Wed, 7 Nov 2001 12:21:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA07227 Wed, 7 Nov 2001 13:48:53 -0500 (EST) Message-ID: <3BE9851A.92E4EEAF@redcreek.com> Date: Wed, 07 Nov 2001 11:01:46 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: ".ipsec" Subject: son-of-ike latest version? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I've got a May '99 copy of son-of-ike (draft-ietf-ipsec-ike-00.txt). Have there been any revisions since then? Is there another draft release we should anticipate in the near future? -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : Redcreek Communications : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Thu Nov 8 14:47:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8Ml7820131; Thu, 8 Nov 2001 14:47:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09594 Thu, 8 Nov 2001 16:14:16 -0500 (EST) Message-ID: From: "Dawson, Willard" To: "'ipsec@lists.tislabs.com'" Subject: www.bakeoff.ipsec.com Date: Thu, 8 Nov 2001 16:16:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1689A.90E084D0" ------_=_NextPart_001_01C1689A.90E084D0 Content-Type: text/plain Hello, I'm not currently a member of this mailing list, so I do not (yet) know if my query will make it to the list. I found the message at http://www.vpnc.org/ietf-ipsec/mail-archive/msg01455.html that references the URL www.bakeoff.ipsec.com . Unfortunately, that website is no longer there. Is there another webpage with the bakeoff results available? Thanks in advance for any info you can give me. ------_=_NextPart_001_01C1689A.90E084D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns=3D"http://www.w3.org/TR/REC-html40"> Hello, I'm not currently a member of this mailing list, so = I do not (yet) know if my query will make it to the list. I found the message at <3d.htm>http:= //www.vpnc.org/ietf-ipsec/mail-archive/msg01455.<3d.htm>html that references the URL <3d.htm>www.bakeoff.ipsec.<3d.htm>com. Unfortunately, that = website is no longer there. Is there another = webpage with the bakeoff results available? Thanks in advance for any info you can give = me. ------_=_NextPart_001_01C1689A.90E084D0-- --------------InterScan_NT_MIME_Boundary-- From owner-ipsec@lists.tislabs.com Thu Nov 8 15:00:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8N0x820406; Thu, 8 Nov 2001 15:00:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09706 Thu, 8 Nov 2001 17:00:24 -0500 (EST) Message-ID: From: "Shriver, John" To: ipsec@lists.tislabs.com Cc: "Shriver, John" , rks@cisco.com, "'Leo Temoshenko'" Subject: discussion of IPsec MIB requirements and goals, and my review of IPsec Flow Monitoring MIB Date: Thu, 8 Nov 2001 14:10:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, I have finally had a chance to do a thoughtful review of the IPsec Flow Monitoring MIB. Took a while until I could take the time away from pressing deliverables to do so. Now I can participate in an informed discussion. (This is a LONG message.) I should start with how I got involved in the IPsec MIB. It was a combination of two things. One, I was working at Shiva with BBN on a proprietary IPsec MIB for a product I was then involved with. Two, I saw Tim Jenkins' MIB work, and saw that it showed a lot of work, but didn't meet BBN's criteria (lots of artificial indices), and it really didn't meet David Perkins' "MIB design rules". (For those who are designing SNMP MIBs, "Understanding SNMP MIBs" is a must-read.) So, I started providing lots of comments to Tim. I was about the only person commenting. So many comments that Tim offered to make me a co-author, which I accepted. There were a set of criteria that we developed as we worked on the MIB. I think I can put most of them in a list here: 1. Well-formed by Perkins' criteria. 2. Meaningful indices on tables wherever possible, rather than synthetic indexes (starting at 1). 3. Ability to look things up directly via an index, rather than a table search, wherever possible. 4. Layered. Start with IPsec, since that's mandatory. Then ISAKMP, since it was a protocol in its own right. Then IKE on top of ISAKMP. 5. Augment rows wherever possible when going up through the MIB documents/layers. Some are full formal AUGMENTS, others are sparse augmentation, which isn't formally expressable in SMIv2. 6. Extensible without having to change the base MIB. No assignments of IPsec magic numbers by the IANA should break or obsolete the MIB. (The magic numbers are what I have in the Textual-Conventions MIB, which would be updated by the IANA after release.) If you don't do this, the MIBs will never reach Full Standard, because they will always be tracking new assignments. (Consider the frustrating fate of the dot3 MIB, trying to keep up with the IEEE defining new flavors of Ethernet.) 7. Allow what the IPsec specifications allow, rather than limiting the MIB to current conventional IPsec useage. 8. Minimize revealing much more than you could learn by sniffing the wire. While there are parts of the MIB which deserve access controls, there's nothing SENSITIVE like keys in it. 9. There should be MIBs for the raw IPsec unidirectional security associations. 10. Allow key negotiations other than IKE to be supported over ISAKMP. 11. Avoid counters that could help a cracker tell if they finally found the right value in a keyspace search. (Things like authentication error counters, etc.) Even more so with traps. 12. Be careful about the length of OID's, especially large index variables. 13. Try and make all index variables definite-length, to avoid the pain of having to insert the length sub-identifier and sort by it. 14. Maximize compatibility with management via SNMPv1 with SMIv1. Basically, be stingy with Counter64, and careful about the Notification OIDs. One frustration that we had was the hopeless generality of the IPsec specifications. There was little "pruning" of the requirements before switching to the protocol development stage. Thus IPsec is everything to everyone. An example of this is identities for Phase 2 key exchanges in IKE. In the spec, the number space is the same one used for Phase 1 key exchanges in ISAKMP. But many of these make absolutely no sense in Phase 2. Like what would "user fully-qualified domain name" mean in this context? In reality, only the address-based identities make sense in this context. When we were trying to add identities to the Phase 2 tables, we queried the list as to whether we could assume that they would always be one of the address types? Someone authoritatively replied "no". I think it was Dan Harkins, who at that time did not like the idea of putting any restrictions on IKE. (I do think Dan's viewpoint has shifted...) The same sort of problem came up trying to build a table of ISAKMP Phase 1 associations. It would be simple to just do it by the two IP addresses. But, because the ISAKMP/IKE specs do not resolve how to handle collision of establishment of Phase 1 associations, even whether to consider tearing one down, one is forced to add the two cookies as indexes, as that is the only way to uniquely identify the connections. So, as I note, the rambling generality of IPsec's specifications complicates MIB writing, if you want to write a MIB to the spec, rather than to what people just happen to be doing today. Now, one of the underlying assumptions I made above is probably non-functional now. That is the layering of ISAKMP and IKE into separate layers. If I understand the intent of the working group correctly these days, the intent is to merge them into one specification now, and to remove ISAKMP's support for any protocol other than IKE. If this is the case, and the assignment of ISAKMP magic numbers is being frozen, I can definitely see that it would be fully appropriate for us to merge our ISAKMP and IKE MIBs, removing a bunch of obsolete columns from the ISAKMP part. Since almost all the tables are augmenting, this will greatly reduce the number of tables. But, we need strong assurances that this would be the right direction to go in! So, now let's wander through the IPsec Flow Monitoring MIB, and consider the design problems in it. Consider section 4, bullet 1. This is about the need to modity ipSecEndPtTable to support a new identity type, based on SCTP. This table corresponds to our selectorTable (IPsec Monitoring MIB). The difference is that selectorTable returns the raw data from the IKE negotiation, with a Ident Type and raw identity data. No attempt is made at pretty formatting. Nor did we reduce this to supporting only the identity types that were meaningful in this context. The ipSecEndPtTable does make the assumption that only the address based identity types made any sense. (I somewhat agree with that.) But, then it gets skewered on my design goal 6 above, as adding a new identity type breaks it. Neither solution is really pretty, the raw ID's are a pain to parse, the change tracking is a loser too. Perhaps it could be like my group table, there is a table for each ID type, with the correct rows, and the base table has a "pointer" to the right table/row to describe the identity. As for section 4, bullet 4, this brings up the need to layer things. This MIB should not be changed to support NAT and IPsec over UDP. These should be layered MIBs, hopefully done by AUGMENTing existing rows in the final IPsec MIBs. We know that the hard part of SNMP instruementation is generating the table index data structures for efficient GET and GET-NEXT operations, so that if multiple SNMP table share the same set of indices, you aren't repeating the "hard" part of the code. To the MIB text proper. The IkePeerType TC is very similar to the InetAddressType in RFC 2851, "Textual Conventions for Internet Network Addresses". I think we're pretty much mandated to use that MIB when we are putting IP addresses into other MIBs. However, there is one type there which isn't an IP address, which is id_dn (I presume X.500 Distinguished Name). However, this is the core a bunch of serious MIB problems, which are discussed later. I don't see why TruthValue isn't suitable instead of defining TrapStatus. The Flow Monitoring MIB's ikaGlobalStats section is very much like our isakmpNegStats and IkeGlobals. But, it has a lot of very intersting counters. These are very well considered counters, obviously added due to very real-world issues. These are a very valuable contribution to the whole MIB discussion. Perhaps a little effort is in order making the definitions of these counters a little more rigorous? However, I'm a little worried (for security reasons) about ikeGlobalAuthFails. Could be too useful to a cracker. Then, I come to another one of the layering issues. The Flow Monitoring MIB appears to include support for the XAUTH and config-mode protocols, starting at ikeGlobalInXauthFailures. While I know as much as anyone that these expired Internet-Drafts are expired, at present they are not on the standards track. Each should be implemented in a seperate MIB, which at present would have to remain proprietary. I don't think the working group wants to MIBify protocols which they couldn't reach consensus on. The Flow Monitoring MIB ikePeerTable runs into a structural problem. It can't be validly implemented. The reason is that when ikePeerLocalType and/or ikePeerRemoteType is id_dn, ikePeerLocalValue and/or ikePeerRemoteValue may very readily be so long that the Object Identifier will exceed the maximum number of sub-identifiers (230 if I remember). Moreover, having these indexes be indefinite-length strings invokes the annoying requirement of a sub-identifier of length in the OID/index. This is why our IKE MIB has the ikeEndpointTable. This is a table of endpoints, indexed by an arbitrary indexes (violating our own no-search rules), containing the endpoint data. Then we can use this arbitrary index to index other tables that need to be indexed by endpoint. It wasn't something we were very happy with, but for Phase 1 identities, there really wasn't any other choice for valid SNMP SMIv2. Another problem with the id-dn identity type is that you haven't documented the encoding of the related value. Is it in DER? If I remember right, there are some knotty issues about certs with the same name, but coded in different language, and whether they are the same or different... Also, the coding of ikePeerLocalType and ikePeerRemoteType is too limited. While there are real restraints on Phase 2 identity types, there are no restrictions on Phase 1 identity types. I don't think that "user FDQN" or "X.500 GeneralName" or "IP V6 address range" have been deprecated yet. (See IpsecDoiIdentType in the DOI Textual Conventions MIB.) Meanwhile, there's no way short of table search to find an IKE Phase 1 SA by the IP addresses. We have that in index of the saTable in the ISAKMP MIB, and it's sparsely-augmented partner ikeSaTable in the IKE MIB. There are also bunch of helper tables in our MIBs (some of which could be made optional), that let you find the Phase 1 SA's created by particular peers, etc. As noted before, the ikePeerTable has a bunch of config-mode entries that need to be bumped up to a separte proprietary MIB. I do appreciate the purpose of the separation of ikePeerTable and ikeTunnelTable. This makes sense, and could be applied to our structure. But, ikeTunnelTable should be indexed by address types/addresses/cookies. The variable ikeTunDiffHellmanGrp does not allow for private groups or as-yet-undefined groups), yet IKE does. Unless IKE Version 2 plans to delete this, I think my saOakleyGroupDesc/saOakleyGroup variables meet the goal of supporting what the spec allows. It also avoids obsolescence problems. Remember that the supporting modpGroupTable, ecpGroupTable and ec2nGroupTable are only required if you actually choose to support negotiating new groups. I wonder why ikeTunStatus has a syntax of TunnelStatus, it could also have a restricted version of RowStatus instead, which might let management stations present it better. The counters of exchange types at the end of this table, starting with ikeTunInNewGrpRequests, and proceeding into more config-mode counter variables, again shows why I did the exchangeTable. Here, new exchange types just instantiate new index values, and no MIB changes are needed when you do things like add Config-Mode. ikePeerCorrTable has the same problem as before of supporting X.500 DistinguishedName strings as indices. Otherwise, it is the same concept as our suiteByCreatorsTable, but with different indices. I do like the various "Wraps" counters, such as ipSecGlobalInOctWraps, that's a nice way to provide SNMPv1 compatability. I do not view IPCOMP as part of IPsec, I would propose that the IPCOMP variables, such as ipSecGlobalInDecompOctets belongs in a IPCOMP MIB. The ipsecTunnelTable is essentially equivalent to our suiteTable. Both have an arbitrary index, as a proper index is just ridiculously long and complicated. The major difference is that suiteTable has references to rows in the IPsec MIB, for each of the raw SA's that make up a tunnel/suite. The Flow Monitoring MIB has flattened this out. I will admit that it is a perfectly valid topic to discuss whether there should be a MIB like the IPsec Monitoring MIB. Perhaps at current network/crypto bandwidths, these rows would be created and destroyed so fast that (1) they would vanish before you chased a reference to them and (2) it would be a computational burden updating the table indices all the time. Perhaps flattening the most essential elements into a higher level MIB is a better solution. On the other hand, how does one monitor a static-SA/static-key only IPsec/IPv4 implementation, which is perfectly valid? (Of course, it also makes for a rather useless product...) Also, I think that ipSecTunelTable assumes that only the canonical three transformations are used, in the canonical order. (Is this a restriction that Son-of-IKE will impose?) The ipSecEndPtTable was discussed earlier, how it cannot be stable with the introduction of new Phase 2 ID types. The ipSecSaTable is similar to our phase2SaTable, but folds in a bit of the IPsec Monitoring MIB. I presume that the intent here is to allow listing the raw SAs in the order that they are applied? I really don't have any issues with the history tables. They are a most interesting idea. They also could be in a MIB by themselves. They could be resource-intensive... I haven't looked at the notifications yet. Hopefully none can be used by key-crackers on a "traffic analysis" basis. I think by the time one changes the indices on the tables that have "structural problems", and allow more extensibility, the tables start to look a lot like the ones Tim and I have been working on for a few years. I think if we prune some things, maybe merge ISAKMP/IKE, and decide if we want an IPsec proper MIB, we can merge the excellent counters with the basic table strategy that has been evolving over two years. The claim that there are "major differences" doesn't ring completely true to me. There are many key similarities, often hidden by different terminology. From owner-ipsec@lists.tislabs.com Thu Nov 8 16:47:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA90lO822816; Thu, 8 Nov 2001 16:47:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09852 Thu, 8 Nov 2001 18:55:22 -0500 (EST) Message-Id: <200111090002.fA902HC09312@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, design@lists.freeswan.org cc: sommerfeld@East.Sun.COM Subject: Re: [Design] Re: opportunistic encryption deployment problems In-reply-to: Your message of "Mon, 20 Aug 2001 17:00:06 EDT." <200108202100.f7KL07022725@thunk.east.sun.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 Nov 2001 19:02:17 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: Bill> I'd like to suggest two changes to the proposal: Bill> 1) in the absence of a secured inverse zone, disallow use of a Bill> tunnel-to address different from the end system's address. Bill> Alternatively, just use transport mode.. I have no objection to such a statement in a draft. As this is an Information RFC, and it documents what we do (and we don't do this), I'm not sure it belongs in our draft. Bill> While it's outside the scope of a protocol specification, the spec Bill> should recommend that, in the absence of some form of certification, Bill> implementations should make {dnsname,address}->key mappings "sticky" Bill> using techniques similar to those currently used by ssh. I'll see if I can find a place to put this. The above comments apply again. Bill> I also think that some more thought should be given to ways to use Bill> opportunistic encryption in conjunction with the NAT traversal drafts; Bill> the current draft encourages using cleartext communications on the Bill> "inside" of the NAT, which is clearly the wrong answer when there's Bill> 802.11 on the "inside" of the NAT.. As long as the OE host behind the NAT is the initiator and the responder supports ESPUDP, I do not see any reason why this needs any special considerations. There is a section in the draft on what does and doesn't work already with NATs (section 8) which refers specifically to ESPUDP. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO+sc/IqHRg3pndX9AQGt1wP/VX/ygfsInyh8Ldfr3qx9w70LHn82wU6m 2vQaAHSM+CBD6z5rQSE2Q8r3d/gdX5isxnWH8mFInv0IOYqeC8fRr+MmMhmebtmp /wCO0UAtaH4M6H+N1OxnA+jTE+gqb45WwG1qu1xQkjJqmV35Ue33qEu4GXBIbzmf r0khye9Vj40= =osTK -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Nov 9 06:48:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9EmE818870; Fri, 9 Nov 2001 06:48:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10919 Fri, 9 Nov 2001 08:38:35 -0500 (EST) Message-Id: <200111090459.fA94xET10837@marajade.sandelman.ottawa.on.ca> To: design@lists.freeswan.org, ipsec@lists.tislabs.com CC: internet-drafts@ietf.org Subject: update to draft-richardson-ipsec-opportunistic.txt From: Michael Richardson Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 08 Nov 2001 23:59:14 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- A new draft is at: http://www.sandelman.ottawa.on.ca/SSW/freeswan/oeid/ ID secretary, please publish the version with change bars: draft-richardson-ipsec-opportunistic-03-change.txt Thank you. there is a version without change bars: draft-richardson-ipsec-opportunistic-03.txt HTML: draft-richardson-ipsec-opportunistic.html ChangeLog: 4.2 the forward reference to section 6.2 has been made more obvious. Section 5.6: "Interactions with COPS" has been removed. Section 5.7.1, phase 1 IDs, exception clarified. Section 6.2, use of TXT record, the following paragraph has been added to deal with key rollover: If there is more than one such TXT record with strongest (lowest numbered) precedence, one Security Gateway is picked arbitrarily from those specified in the strongest-preference records. All keys for that all listed Security Gateways are made available as candidates for signature checking. This mechanism is required to permit rollover of signature keys in a seamless fashion. Section 6.2.1 has been rewritten to include a note on the KEY record, on possible future use of the CERT record. A section has been added as section 10, "Renewal and Teardown". It has subsequently been moved to between: "Detailed description of process", and "Impacts on IKE". A section "Failure modes" completed was completed. A section "Multihoming" has been expanded. added lifetime/lifespan definitions. moved example from 5B to 5C. added reference to phase 1 IDs to 5D. cleared up text in aging section. added text about delegation of DNSSEC activity to a DNS server. spelt out DH group names. added text about ignoring TXT records unless DNSSEC is deployed (somerfeld) added example of TXT delegation using FQDN. clarified some text in NAT interaction section. clarified absense of TXT record need for host implementation -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO+tilIqHRg3pndX9AQFddwQAuhTJWap4yJN4/OfoYntqeL3daLJ1eNdD XmcUWY/gO+AIE2PO1Ys9zJMZlUOKH3j1Hs5NTKeh8Xs6+/VTAnJ1USVEvcAm+lIX KNhFxDCCVGruCuUWoyvCqPdK2VFfKdbA4tFz77gcrE7t+pm8YQ2o7H/hFrQMbHT7 UJyQn6M2DtQ= =j1Zz -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Fri Nov 9 08:12:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9GCC827879; Fri, 9 Nov 2001 08:12:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11254 Fri, 9 Nov 2001 10:25:02 -0500 (EST) Importance: Normal Subject: DSS Signature (r and s values) To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.6 December 14, 2000 Message-ID: From: "David Wierbowski" Date: Fri, 9 Nov 2001 10:33:18 -0500 X-MIMETrack: Serialize by Router on D01MLC96/01/M/IBM(Build V509_10152001.dev02 |October 31, 2001) at 11/09/2001 10:33:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a question relative to DSS Signature mode, RFC 2409 states that 'DSS signatures MUST be encoded as r followed by s.' Does this mean that r and s are encoded as normal, that is in an ASN1 sequence as follows: SEQUENCE { r INTEGER, s INTEGER } or Does this mean that just the two binary values for r and s are used without being wrapped in an ANS1 sequence ? From owner-ipsec@lists.tislabs.com Fri Nov 9 08:18:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9GIJ828108; Fri, 9 Nov 2001 08:18:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11248 Fri, 9 Nov 2001 10:21:50 -0500 (EST) From: dkt@hongkong.com Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: Date: Fri, 9 Nov 2001 23:19:25 +0800 (CST) To: ipsec@lists.tislabs.com Subject: ipsec, client behind NAT X-Priority: 3 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Is it possible for these two host to setup IPsec using tunnelling mode? Host A=======Firewall=====Internet=====Server Host A has a private IP address. The Firewall do NAT but I has no authority to change the setting. The Server is my home, it has a public IP and I have full control. Most probably I use Windows 2000 / Linux / FreeBSD for Host A and use Linux / FreeBSD as my Server. ---------------------------------------------- Åwªï¨Ï¥ÎHongKong.com¶l¥ó¨t²Î Thank you for using hongkong.com Email system From owner-ipsec@lists.tislabs.com Fri Nov 9 09:48:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9HmJ802427; Fri, 9 Nov 2001 09:48:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA11416 Fri, 9 Nov 2001 11:50:09 -0500 (EST) Message-ID: From: "Shahrier, Sharif M." To: seamoby@cdma-2000.org, "'mobile-ip@sunroof.eng.sun.com'" , "'ipsec@lists.tislabs.com'" , "'aaa-wg@merit.edu'" Cc: "Shahrier, Sharif M." Subject: [seamoby] Security tutorial Date: Fri, 9 Nov 2001 11:53:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there a security tutorial document published by the IETF, i.e. pulished as an Informational RFC? I am also interested in the key IETF documents on security, such as encryption, firewall, AAA, RADIUS and DIAMETER, etc. I was hoping that there is a document published by the IETF, that has pointers to thsese documents as well. I would be grateful if someone could provide me with this information. (Please copy me an e-mail directly, because I'm not currently subscribed to some of these lists). -Sharif. From owner-ipsec@lists.tislabs.com Fri Nov 9 11:06:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9J6j807092; Fri, 9 Nov 2001 11:06:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA11477 Fri, 9 Nov 2001 12:21:34 -0500 (EST) From: VAHUJA@aol.com Message-ID: Date: Fri, 9 Nov 2001 12:30:26 EST Subject: Re: [seamoby] Security tutorial To: Sharif.Shahrier@interdigital.com CC: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For IPSec, a useful start is with the Domain of Interpretation (DOI) RFC 2407; Sec Arch for the Internet Protocol RFC 1825; then there are several for ISAKMP etc etc... for iSCSI security there are others..perhaps you can point to what exactly you are looking for..with security..i.e. what you are trying to secure...there is PKI, SSL, IDS, etc etc.. From owner-ipsec@lists.tislabs.com Fri Nov 9 13:54:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9LsS814625; Fri, 9 Nov 2001 13:54:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11797 Fri, 9 Nov 2001 15:52:29 -0500 (EST) To: dkt@hongkong.com Cc: ipsec@lists.tislabs.com Subject: Re: ipsec, client behind NAT References: From: Derek Atkins Date: 09 Nov 2001 16:01:34 -0500 In-Reply-To: dkt@hongkong.com's message of "Fri, 9 Nov 2001 23:19:25 +0800 (CST)" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk See the nat-t drafts. I don't know who implements it yet. It only works if A is the intiator. -derek dkt@hongkong.com writes: > Hi, > > Is it possible for these two host to setup IPsec using tunnelling mode? > > Host A=======Firewall=====Internet=====Server > > > Host A has a private IP address. The Firewall do NAT but I has no authority to change the setting. The Server is my home, it has a public IP and I have full control. > > Most probably I use Windows 2000 / Linux / FreeBSD for Host A and use Linux / FreeBSD as my Server. > ---------------------------------------------- > Åwªï¨Ï¥ÎHongKong.com¶l¥ó¨t²Î > Thank you for using hongkong.com Email system > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 9 15:18:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA9NIk817990; Fri, 9 Nov 2001 15:18:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11888 Fri, 9 Nov 2001 17:17:20 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E02937148@CORPMX14> To: VAHUJA@aol.com, Sharif.Shahrier@interdigital.com Cc: ipsec@lists.tislabs.com Subject: RE: [seamoby] Security tutorial Date: Fri, 9 Nov 2001 17:15:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ignore RFC 1825 - it's obsolete! See RFC 2401 for the current IPsec architecture. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: VAHUJA@aol.com [mailto:VAHUJA@aol.com] > Sent: Friday, November 09, 2001 12:30 PM > To: Sharif.Shahrier@interdigital.com > Cc: ipsec@lists.tislabs.com > Subject: Re: [seamoby] Security tutorial > > > For IPSec, a useful start is with the Domain of > Interpretation (DOI) RFC > 2407; Sec Arch for the Internet Protocol RFC 1825; then there > are several for > ISAKMP etc etc... > > for iSCSI security there are others..perhaps you can point to > what exactly > you are looking for..with security..i.e. what you are trying to > secure...there is PKI, SSL, IDS, etc etc.. > From owner-ipsec@lists.tislabs.com Wed Nov 14 09:16:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAEHG6804738; Wed, 14 Nov 2001 09:16:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29428 Wed, 14 Nov 2001 10:51:14 -0500 (EST) Message-Id: <200111132357.fADNvM824732@marajade.sandelman.ottawa.on.ca> To: design@lists.freeswan.org, namedroppers@ops.ietf.org, ipsec@lists.tislabs.com cc: Simon Josefsson Subject: Re: draft-richardson-ipsec-opportunistic-02.txt In-reply-to: Your message of "Mon, 12 Nov 2001 12:32:58 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 13 Nov 2001 18:57:22 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Guys, I'm reposting to the design list and namedroppers, if for no other reason than for a record... The movie so far: 1) Simon emailed Henry, DHR and I about our use of TXT and KEY. 2) Michael responded, saying that we use KEY to store raw RSA keys for the endpoints. We use TXT records (see the draft) to provide authorization of delegation from end-nodes to gateways (and to discover the gateways) 3) Henry has responded, with the text below, which I'm quoting. 4) A large Aladdin-type Genie, but with Bruce Schneier's voice, pops out, and solves the global-PKI problem. >>>>> "Henry" == Henry Spencer >>>>> "Simon" == Simon Josefsson Simon> Ok -- right now the trends within the DNSEXT group seems to be that Simon> KEY should only be used for DNSSEC internal purposes as well, and to Simon> have some other RR for application related purposes. (The DNSSEC Simon> specs are being revised.) Henry> As Michael said, we're already using KEY for the purposes endorsed in RFC Henry> 2535. Changing that will involve some difficulties, because of the need Henry> to get support for an alternative record into BIND etc., but it could be Henry> done if necessary, sigh. Simon, your above statement suggests to me that you don't want us to use KEY to identify host info at all. Is there a document that explains this in detail? KEY seems to have lots of bits designed to distinguish different uses. We could certainly use two kinds of CERT record - one for the raw RSA host key, and the second for delegation authorization. The second one is discussed below: Simon> I have intended to write a draft that says CERT RRs should be regarded Simon> as containing "application security related information". Requiring Simon> that CERT must contained signed data is irrelevant from a DNS point of Simon> view... Henry> Indeed so. Relax *that* requirement -- which could be read as an accident Henry> of wording rather than a matter of fundamental intent -- and CERT would be Henry> a good match for our needs. I think that we are in agreement. I didn't take the "signed" part of the note too heavily anyway. Simon> With your permission, I'd like to include your IPSEC usage as a Simon> example of what the CERT RR could have as sub-types... Henry> Yes, by all means, go ahead. As Michael noted, there are two or three Henry> variations involved (IPv4 address, IPv6 address, DNS name), but that's Henry> a secondary issue if it's being used purely as an example. Simon> You would need to write the CERT sub-type registration yourself, if you Simon> think CERT RR's is a good idea. What do you think? I think that this would be appropriate for a "Opportunistic Encryption version 2" specification. We believe that there are a number of things unrelated to the syntax used to store the keys that need to be solved first. Our solution, while in-elegant is functionally identical to one that had CERT RRs instead. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO/GzXYqHRg3pndX9AQESNwQAp1yZ71ETFaJMWRFiPUfFQ03ynEtF+NG4 QVo/i21MXDDcAcx1qwST/Saa6gCTO1HCipTwCVi+Whi/wCFv+gAOySIvC4Ge6s23 CmhzhyKi8YNlSQNPlXs52RjGKhJNlokTilY69LPGdC6GHJFME8UeaTev52KzeuYQ 28ecYXHPfd0= =YQkQ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Nov 15 06:28:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAFES8801647; Thu, 15 Nov 2001 06:28:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA01302 Thu, 15 Nov 2001 08:14:49 -0500 (EST) Message-Id: <200111142152.fAELqAEH000531@coredump.cs.columbia.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: ipsec@lists.tislabs.com Subject: Just Fast Keying (JFK) draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Nov 2001 16:52:10 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Without further ado, here's the link to the just-submitted I-D: http://www.cs.columbia.edu/~angelos/Papers/draft-keromytis-jfk-00.txt There is ongoing work on formally verifying certain properties of the protocol, which we hope will be mature enough by December to be discussed at the WG meeting. Comments to all the authors as a group should be directed to jfk@crypto.com The members of said group are: Bill Aiello (AT&T Research Labs) Steve Bellovin (AT&T Research Labs) Matt Blaze (AT&T Research Labs) Ran Canetti (IBM T.J. Watson Research Center) John Ioannidis (AT&T Research Labs) Angelos Keromytis (Columbia University) Omer Reingold (AT&T Research Labs) -Angelos From owner-ipsec@lists.tislabs.com Fri Nov 16 02:03:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGA3C812804; Fri, 16 Nov 2001 02:03:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA03279 Fri, 16 Nov 2001 03:42:42 -0500 (EST) Reply-To: From: "Masafumi Tsuruta" To: Subject: About "Emergency Mode" Date: Fri, 16 Nov 2001 17:51:11 +0900 Message-ID: <002301c16e7b$d7b04210$8300a8c0@tsuruta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, all. In RFC 2408 [ISAKMP] Section 3.1, ISAKMP Header Format, explains components of ISAKMP header format including Flag field. In the part of Authentication Only Bit, line 4, there is a word "Emergency Mode". What is this mode? What is the different point from "Normal Mode"? I hardly understand this word means. Please give me some information such as URLs or RFC, and so on. Thank you. ------------------------- International Network Security, Inc Dept of tech, PKI unit Masafumi Tsuruta (Tsuruta@insi.co.jp) http://www.insi.co.jp From owner-ipsec@lists.tislabs.com Fri Nov 16 08:53:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGGr0819118; Fri, 16 Nov 2001 08:53:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03885 Fri, 16 Nov 2001 10:41:00 -0500 (EST) Message-ID: <6549284BE680D511815C0002A50A67770D131B@hdsmsx102.hd.intel.com> From: "Eissa, Mohamed" To: ipsec@lists.tislabs.com Subject: latest ipsec/pki bake off results Date: Fri, 16 Nov 2001 07:51:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, Can anybody help me to find to the latest bake off results, specially IKE/PKIX portion? I tried this link http://bakeoff.ipsec.com/ from the VPNC web site but it didn't work. Thank you in advance, Mohamed Eissa Intel of Canada From owner-ipsec@lists.tislabs.com Fri Nov 16 10:31:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGIV2828469; Fri, 16 Nov 2001 10:31:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA04130 Fri, 16 Nov 2001 12:21:03 -0500 (EST) Message-ID: <3BF54D49.8868782C@storm.ca> Date: Fri, 16 Nov 2001 12:30:49 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Eissa, Mohamed" CC: ipsec@lists.tislabs.com Subject: Re: latest ipsec/pki bake off results References: <6549284BE680D511815C0002A50A67770D131B@hdsmsx102.hd.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Eissa, Mohamed" wrote: > Can anybody help me to find to the latest bake off results, specially > IKE/PKIX portion? > There are some links in the documentation for FreeS/WAN, a Linux IPsec implementation: http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/web.html#interop If you find good links that aren't there, please post them so I can add them to that list. From owner-ipsec@lists.tislabs.com Fri Nov 16 12:06:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGK6n809907; Fri, 16 Nov 2001 12:06:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04268 Fri, 16 Nov 2001 14:02:14 -0500 (EST) Message-ID: <007f01c16ed2$8443ade0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Eissa, Mohamed" , References: <6549284BE680D511815C0002A50A67770D131B@hdsmsx102.hd.intel.com> Subject: Re: latest ipsec/pki bake off results Date: Fri, 16 Nov 2001 21:11:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Can anybody help me to find to the latest bake off results, specially > IKE/PKIX portion? We did post something to the list after the bakeoff, see the following link, the pointer in the mail, and Itojun's reply http://www.vpnc.org/ietf-ipsec/mail-archive/msg01455.html Jari From owner-ipsec@lists.tislabs.com Mon Nov 19 01:42:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJ9gs803880; Mon, 19 Nov 2001 01:42:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA08076 Mon, 19 Nov 2001 03:30:26 -0500 (EST) Date: Mon, 19 Nov 2001 09:36:15 +0100 From: Giaretta Gerardo Subject: ipsec in tunnel mode and dynamic routing To: ipsec@lists.tislabs.com Message-id: <9A761F39C9097F42977EAD1565F77E09243A20@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-type: text/plain; charset="iso-8859-1" Thread-Topic: ipsec in tunnel mode and dynamic routing Thread-Index: AcFw1UApT1eYPO+BTk2CEHUYZguq8w== content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id DAA08073 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I have a question about using ipsec in tunnel mode together with dynamic routing: I read draft-touch-ipsec-vpn-01.txt but I'm not sure that I understood it clearly. Consider this example: (it's really similar to the example made in the draft) B / \ 3 / \ 4 / \ X --...--> A D --...--> Y \ / 1 \ / 1 \ / C (the numbers near the link represent the weights of the links, regaring dinamic routing). (links A-B and A-C are untrusted) I think this is what happens: - a packet arrives in A with SA=X and DA=Y (SA= source address; DA=destination address) - A has to apply ipsec in tunnel mode for this packet because links A-B and A-C are untrusted - IPSec can't know if the optimal route to go to D is through A or B - Suppose that SPD and SAD are configured so that the packet is encapsulated with SA=A and DA=B (i.e. it's used the tunnel A-B and not the tunnel A-C) - The packet arrives to Y through A-B-D: this is clearly not the optimal route because it has weight 7 against weight 2 of A-C-D route. Obviously if link B-D goes down, there is no way to send the packet to D applying IPSec unless changing the ipsec configuration file. That is with ipsec we looose some of the dynamic routing advantages. Is this right? Is there any other problem using dynamic routing and ipsec together or this is the only one? Thank you in advance Gerardo From owner-ipsec@lists.tislabs.com Mon Nov 19 03:37:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJBbJ815156; Mon, 19 Nov 2001 03:37:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA08413 Mon, 19 Nov 2001 05:42:36 -0500 (EST) From: juha.ollila@nokia.com Message-ID: To: ipsec@lists.tislabs.com Subject: OSPF (IPv6) and IPsec Date: Mon, 19 Nov 2001 12:51:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello! Is it possible to secure a multicast OSPF (IPv6) traffic? I think that multicast traffic can be tunneled between the security gateways (a one to one connection), but it isn't an end to end solution. IPsec specifications mention Group Key Management Protocol (GKMP). Is it usable? MSEC and SMuG are standardizing protocols for securing multicast traffic, but work is still in progress. /Juha From owner-ipsec@lists.tislabs.com Mon Nov 19 05:45:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJDjX824040; Mon, 19 Nov 2001 05:45:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA08602 Mon, 19 Nov 2001 07:46:51 -0500 (EST) To: ipsec@lists.tislabs.com From: dharkins@tibernian.com Subject: IKEv2 (son-of-ike) draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2377.1006067452.1@SailPix.com> Date: Sat, 17 Nov 2001 23:10:52 -0800 Message-Id: <20011118071052.0F71654C53@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This draft was submitted but hasn't shown up yet in the repository (the I-D editor is, no doubt, swamped) so in the interest of giving people more time to look at it prior to Salt Lake here's a link: http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt Please send comments to the list. Dan. From owner-ipsec@lists.tislabs.com Mon Nov 19 06:00:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJE0D824378; Mon, 19 Nov 2001 06:00:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08773 Mon, 19 Nov 2001 08:19:34 -0500 (EST) Message-Id: <200111191328.IAA26753@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Date: Mon, 19 Nov 2001 08:28:49 -0500 Sender: owner-ipsec@lists.tislabs.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 : Protocol Requirements for Son-of-IKE Author(s) : C. Madson Filename : draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt Pages : 13 Date : 16-Nov-01 Various proposals have been made for updating the IKE protocol. One thing which is missing from the dicussion is an evaluation of the scope of IKE, identifying which problems it should solve. Once this scoping is done, it becomes easier to specify the requirements for the protocol, as well as the protocol itself. Sections of this document discuss various scenarios that are considered important for IKE; this list needs to be refined by the WG. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-son-of-ike-protocol-reqts-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011116141926.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-son-of-ike-protocol-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116141926.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 19 06:00:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJE0G824391; Mon, 19 Nov 2001 06:00:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08797 Mon, 19 Nov 2001 08:20:05 -0500 (EST) Message-Id: <200111191329.IAA26819@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-00.txt Date: Mon, 19 Nov 2001 08:29:14 -0500 Sender: owner-ipsec@lists.tislabs.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 Internet Key Exchange (IKE) Protocol Author(s) : D. Harkins, C. Kaufman, R. Perlman Filename : draft-ietf-ipsec-ikev2-00.txt Pages : 64 Date : 16-Nov-01 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE performs mutual authentication and establishes an IKE security association that can be used to efficiently establish SAs for ESP, AH and/or IPcomp. This version greatly simplifies IKE by replacing the 8 possible phase 1 exchanges with a single exchange based on public signature keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ikev2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011116142014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142014.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 19 06:00:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJE0K824404; Mon, 19 Nov 2001 06:00:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08779 Mon, 19 Nov 2001 08:19:41 -0500 (EST) Message-Id: <200111191328.IAA26769@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-xcbc-mac-00.txt Date: Mon, 19 Nov 2001 08:28:56 -0500 Sender: owner-ipsec@lists.tislabs.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 AES-XCBC-MAC-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, H. Herbert Filename : draft-ietf-ipsec-ciph-aes-xcbc-mac-00.txt Pages : 10 Date : 16-Nov-01 A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for mes- sages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ciph-aes-xcbc-mac-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011116141937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-xcbc-mac-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-xcbc-mac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116141937.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 19 06:01:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJE12824441; Mon, 19 Nov 2001 06:01:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08767 Mon, 19 Nov 2001 08:19:26 -0500 (EST) Message-Id: <200111191328.IAA26735@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-jfk-00.txt Date: Mon, 19 Nov 2001 08:28:43 -0500 Sender: owner-ipsec@lists.tislabs.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 : Just Fast Keying (JFK) Author(s) : W. Aiello, S. Bellovin, M. Blaze et al. Filename : draft-ietf-ipsec-jfk-00.txt Pages : Date : 16-Nov-01 Many public-key-based key setup and key agreement protocols already exist and have been implemented for a variety of applications and environments. Several have been proposed for the IPsec protocol, and one, IKE [rfc2409], is the current standard. IKE has a number of deficiencies, the three most important being that the number of rounds is high, that it is vulnerable to denial-of-service attacks, and the complexity of its specification. (This complexity has led to interoperability problems, so much so that, several years after its initial adoption by the IETF, there are still completely non-interoperating implementations.) A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-jfk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-jfk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011116141917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-jfk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-jfk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116141917.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 19 06:01:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJE1H824454; Mon, 19 Nov 2001 06:01:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08796 Mon, 19 Nov 2001 08:19:59 -0500 (EST) Message-Id: <200111191329.IAA26802@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt Date: Mon, 19 Nov 2001 08:29:07 -0500 Sender: owner-ipsec@lists.tislabs.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 HMAC-SHA-256-96 Algorithm and Its Use With IPsec Author(s) : S. Frankel, S. Kelly Filename : draft-ietf-ipsec-ciph-sha-256-00.txt Pages : 8 Date : 16-Nov-01 Ths document describes the use of the HMAC algorithm in conjunction with the SHA-256 algorithm as an authentication mechanism within the context of the IPsec Authentication Header and the IPsec Encapsulat- ing Security Payload. HMAC with SHA-256 provides data origin authen- tication and integrity protection. This version of the HMAC-SHA-256 authenticator specifies truncation to 96 bits, and is therefore named HMAC-SHA-256-96. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-sha-256-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ciph-sha-256-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-sha-256-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011116142001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-sha-256-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-sha-256-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142001.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 19 06:03:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJE3s824518; Mon, 19 Nov 2001 06:03:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08795 Mon, 19 Nov 2001 08:19:56 -0500 (EST) Message-Id: <200111191329.IAA26786@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-camellia-00.txt Date: Mon, 19 Nov 2001 08:29:02 -0500 Sender: owner-ipsec@lists.tislabs.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 Camellia Cipher Algorithm and Its Use With IPsec Author(s) : S. Moriai et al. Filename : draft-ietf-ipsec-ciph-camellia-00.txt Pages : 9 Date : 16-Nov-01 This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-camellia-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ciph-camellia-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-camellia-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011116141948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-camellia-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-camellia-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116141948.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 19 06:56:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJEur827974; Mon, 19 Nov 2001 06:56:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08930 Mon, 19 Nov 2001 08:58:02 -0500 (EST) Message-ID: <3BF9120E.1C641FA1@lmf.ericsson.se> Date: Mon, 19 Nov 2001 16:07:10 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: juha.ollila@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: OSPF (IPv6) and IPsec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk For routing protocol use, manually configured SAs might be an alternative. MSEC certainly isn't ready yet, and I'm not sure it would be a suitable tool for connecting a few routers anyway, it typically works for larger amounts of nodes. Jari From owner-ipsec@lists.tislabs.com Mon Nov 19 08:16:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJGGb805468; Mon, 19 Nov 2001 08:16:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09242 Mon, 19 Nov 2001 10:19:13 -0500 (EST) To: Giaretta Gerardo Cc: ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing References: <9A761F39C9097F42977EAD1565F77E09243A20@EXC2K05A.cselt.it> From: Derek Atkins Date: 19 Nov 2001 10:28:19 -0500 In-Reply-To: Giaretta Gerardo's message of "Mon, 19 Nov 2001 09:36:15 +0100" Message-ID: Lines: 43 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Giaretta Gerardo writes: > > Hi all, > I have a question about using ipsec in tunnel mode together with dynamic > routing: I read draft-touch-ipsec-vpn-01.txt but > I'm not sure that I understood it clearly. > > Consider this example: (it's really similar to the example made in the > draft) > > > B > / \ > 3 / \ 4 > / \ > X --...--> A D --...--> Y > \ / > 1 \ / 1 > \ / > C > You should not use IPsec on a hop-by-hop basis. Assuming A and D are your Security Gateways, all packets should be encrypted between A and D, regardless of the path they take. In other words, a packet arrives at A from X for Y. A knows that it has to get to D, so it tunnels the packet to D, which can go via either B or C (which is unimportant). Then D decapsulates the packet and sends it on the Y. If C goes down, you re-route via B. If D goes down, you are out of luck. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Nov 19 08:18:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJGIX805534; Mon, 19 Nov 2001 08:18:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09277 Mon, 19 Nov 2001 10:26:23 -0500 (EST) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.9619.576979.166009@ryijy.hel.fi.ssh.com> Date: Mon, 19 Nov 2001 17:30:27 +0200 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ike-modp-groups-03.txt X-Mailer: VM 6.89 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 8 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just submitted new version of the modp groups draft. The new version includes 6144 bit group, and some new text about the exponent size that should be used in the Diffie-Hellman with new groups. I also moved the ecpp-certificates to new location I changed to use new program called Primo to generate them. I am still trying to generate the ecpp certificate for the 8192 bit group, and with this new software it might even be possible (it was able to generate certificate for the 6144 bit group in 40 hours). I think the current version of the draft is ready to be in the last call, and if we can get the certificate of the 8192 bit group soon, then we can just remove the comment that the generation is in progress. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Nov 19 08:34:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJGYE806533; Mon, 19 Nov 2001 08:34:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09356 Mon, 19 Nov 2001 10:46:41 -0500 (EST) Date: Mon, 19 Nov 2001 16:54:01 +0100 From: Giaretta Gerardo Subject: RE: ipsec in tunnel mode and dynamic routing To: Derek Atkins Cc: ipsec@lists.tislabs.com Message-id: <9A761F39C9097F42977EAD1565F77E09243A22@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-type: text/plain; charset="iso-8859-1" Thread-Topic: ipsec in tunnel mode and dynamic routing Thread-Index: AcFxDrval+QYM8uWQyS45hEekLRpkQAAMasA content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA09353 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >You should not use IPsec on a hop-by-hop basis. Assuming A and D are >your Security Gateways, all packets should be encrypted between A and >D, regardless of the path they take. >In other words, a packet arrives at A from X for Y. A knows that >it has to get to D, so it tunnels the packet to D, which can go >via either B or C (which is unimportant). Then D decapsulates >the packet and sends it on the Y. >If C goes down, you re-route via B. ok this is right and I understand it, but the hop-by-hop basis example is made in the draft. Only, I want to understand the problems that arise when you use both ipsec and dynamic routing. In the draft it's explained only if you assume a hop by hop situation. Is this the only situation in whch problems arise? Gerardo From owner-ipsec@lists.tislabs.com Mon Nov 19 08:46:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJGk6808354; Mon, 19 Nov 2001 08:46:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA09429 Mon, 19 Nov 2001 10:54:46 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.11388.281025.686412@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 07:59:56 -0800 (PST) To: ipsec@lists.tislabs.com Subject: SOI: preshared In-Reply-To: <200111191328.IAA26753@ietf.org> References: <200111191328.IAA26753@ietf.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There's an interesting question posed by Cheryl's requirements draft about the scope of son-of-ike. As Cheryl points out, IKE is popularly thought of as a PKI authentication protocol even if the reality is something else. I think we're at an interesting cross roads here because a SOI doesn't have to be a kitchen sink protocol anymore since we've gained experience, as well as having some other arrows in our quiver (cf KINK). JFK positions itself as a PKI authentication *only* protocol. KINK is quite naturally useful for pre-shared keys, but requires an active third party authentication box (KDC). So here's the questions: 1) Should we deem peer-peer preshared keying bogus? 2) If not, should SOI inherently be a dual (triple...) authentication mechanism protocol? 3) If so, how do we bound the authentication mechanisms to keep IKE manageable? 4) If not, what fills the hole of peer-peer pre-shared keys? A different protocol? Extend KINK (many possible ways to do this)? Mike From owner-ipsec@lists.tislabs.com Mon Nov 19 08:54:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJGse809407; Mon, 19 Nov 2001 08:54:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09512 Mon, 19 Nov 2001 11:09:17 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.12478.158520.373309@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 08:18:06 -0800 (PST) To: ipsec@lists.tislabs.com Subject: SOI: identity protection and DOS In-Reply-To: <200111191328.IAA26753@ietf.org> References: <200111191328.IAA26753@ietf.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The requirements that Cheryl put out didn't take a position on identity protection and DOS. That was probably a smart maneuver, but still I think there needs to be a consensus view of those requirements in order to judge protocols. My view is: 1) SOI MUST be capable determining return routability in a fashion that does not require state to be saved on the responder. A SOI peer MUST NOT invoke the return routability test unless it feels like it's under attack, or configured by policy. 2) SOI SHOULD provide a means to protect identities. SOI MUST make protection optional if it reduces the overall number of messages to establish a SA. A SOI peer MUST NOT protect identities by default. I expect that the last statement is controversial so let me explain: IMO, identity protection is overblown. If by simple traffic analysis I see a static IP address for a server which I can reverse map, and even a dynamic address which I can reverse map to a particular POP, a determined attacker is probably going to have a pretty good idea that you're visiting naughtybits.com. If you have a static address, you're even more exposed (and with v6, this should be the norm). If you want identity protection, you should really be using an application layer anonymizer, and not counting on IKE, or any other L3 mechanism to cover your tracks. Mike From owner-ipsec@lists.tislabs.com Mon Nov 19 09:26:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJHQL811100; Mon, 19 Nov 2001 09:26:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09565 Mon, 19 Nov 2001 11:24:12 -0500 (EST) To: Giaretta Gerardo Cc: ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing References: <9A761F39C9097F42977EAD1565F77E09243A22@EXC2K05A.cselt.it> From: Derek Atkins Date: 19 Nov 2001 11:33:28 -0500 In-Reply-To: Giaretta Gerardo's message of "Mon, 19 Nov 2001 16:54:01 +0100" Message-ID: Lines: 46 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The hop-by-hop example only works if you route _before_ you encrypt... In order words, you route on top of IPsec tunnels. You can do this if you consider your IPsec tunnels as routable interfaces. For example, in your picture: B / \ X - A D - Y \ / C .. if A has tunnels to B and C, it can use any routing protocol to choose which tunnel (B or C) it will use. When a packet comes in from X, it gets routed out a tunnel, and before it gets sent out it gets encrypted. The problem, of course, is detecting when a tunnel endpoint goes down. This is a problem with any kind of virtual tunnel, not just IPsec. With link-layer neighbors you can use the lower-layer to detect a downed link; it's more difficult with a virtual tunnel. However, assuming you can detect a downed tunnel, the routing protocol would happily use the other tunnel and encrypt to C instead of B. Note that encryption has to occur _after_ routing, otherwise you may encrypt to the wrong destination. -derek Giaretta Gerardo writes: > ok this is right and I understand it, but the hop-by-hop basis example > is made in the draft.=20 > Only, I want to understand the problems that arise when you use both > ipsec and dynamic routing. > In the draft it's explained only if you assume a hop by hop situation. > Is this the only situation > in whch problems arise? > > Gerardo -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Nov 19 09:26:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJHQh811127; Mon, 19 Nov 2001 09:26:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09602 Mon, 19 Nov 2001 11:30:04 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.13336.344077.163793@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 08:32:24 -0800 (PST) To: ipsec@lists.tislabs.com Subject: SOI: round tripiness In-Reply-To: <200111191328.IAA26753@ietf.org> References: <200111191328.IAA26753@ietf.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I didn't see any mention in the draft about IKE's round trip obesity. I think there's a number of us who think that IKE's requirement of 8 or more messages to establish the first SA is grotesque. While it's probably not a huge deal for VPN's, peers wanting to establish on the fly transport connections (including the OE stuff), the message count burden is probably even more significant than the CPU burden, which is saying something. JFK proposes that we smash everything together and nuke the Main/Quick mode distinction. This seems sensible on the surface but there's seems to be some amount of fear that not having the ability to amortize expensive public operations will degrade performance for rekeying, deletes, notifies, etc. I'll point out that KINK sidesteps this problem by virtue of using Kerberos tickets which capture the state of initial authentication for a shortish period of time. This allows use of much cheaper symmetric key operations for subsequent protocol operations while still eliminating Main Mode. Perhaps this sort of mechanism (even if not Kerberos directly) could be used for SOI. Mike From owner-ipsec@lists.tislabs.com Mon Nov 19 10:02:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJI2X812151; Mon, 19 Nov 2001 10:02:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09691 Mon, 19 Nov 2001 11:56:59 -0500 (EST) Date: Mon, 19 Nov 2001 18:04:37 +0100 From: Giaretta Gerardo Subject: RE: ipsec in tunnel mode and dynamic routing To: Derek Atkins Cc: ipsec@lists.tislabs.com Message-id: <9A761F39C9097F42977EAD1565F77E09243A23@EXC2K05A.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-type: text/plain; charset="iso-8859-1" Thread-Topic: ipsec in tunnel mode and dynamic routing Thread-Index: AcFxF9C3uY8Ydh2cTV2M9lNzC2cL5AAA63OQ content-class: urn:content-classes:message Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id LAA09688 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ok, I can understand that the hop-by-hop example works only if I route before I encrypt, but in ipsec documentation (i mean in ipsec RFCs), i think it's not clear if the routing comes before the encryption or viceversa. Is it implementation dependent? Gerardo -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: lunedì 19 novembre 2001 17.33 To: Giaretta Gerardo Cc: ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing The hop-by-hop example only works if you route _before_ you encrypt... In order words, you route on top of IPsec tunnels. You can do this if you consider your IPsec tunnels as routable interfaces. For example, in your picture: B / \ X - A D - Y \ / C .. if A has tunnels to B and C, it can use any routing protocol to choose which tunnel (B or C) it will use. When a packet comes in from X, it gets routed out a tunnel, and before it gets sent out it gets encrypted. The problem, of course, is detecting when a tunnel endpoint goes down. This is a problem with any kind of virtual tunnel, not just IPsec. With link-layer neighbors you can use the lower-layer to detect a downed link; it's more difficult with a virtual tunnel. However, assuming you can detect a downed tunnel, the routing protocol would happily use the other tunnel and encrypt to C instead of B. Note that encryption has to occur _after_ routing, otherwise you may encrypt to the wrong destination. -derek Giaretta Gerardo writes: > ok this is right and I understand it, but the hop-by-hop basis example > is made in the draft.=20 > Only, I want to understand the problems that arise when you use both > ipsec and dynamic routing. > In the draft it's explained only if you assume a hop by hop situation. > Is this the only situation > in whch problems arise? > > Gerardo -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Nov 19 10:56:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJIus815937; Mon, 19 Nov 2001 10:56:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09858 Mon, 19 Nov 2001 12:55:53 -0500 (EST) Message-ID: <3BF945E7.D5576D91@redcreek.com> Date: Mon, 19 Nov 2001 09:48:23 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Giaretta Gerardo CC: ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing References: <9A761F39C9097F42977EAD1565F77E09243A20@EXC2K05A.cselt.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Giaretta Gerardo wrote: > > > Hi all, > I have a question about using ipsec in tunnel mode together with dynamic > routing: I read draft-touch-ipsec-vpn-01.txt but > I'm not sure that I understood it clearly. > One large point to keep in mind about that draft is that its intended purpose is to create overlay networks. The interested audience for this is comparatively small. It goes beyond the aims and purposed of creating secure VPN networks. I mention this because I am guessing that you are more interested in the VPN networks application of IPsec rather than creating the rapidly deployable, temporary, overlay networks. If, so, you should put down that draft and try to reframe your routing/IPsec questions in the context of a VPN application. On, the other hand, I could be totally wrong and you may have asked exactly what you meant. In that case, keep in mind that Joe Touch's draft aslo recommends making routing decisions before encapsulation to avoid just the example problem you bring up. In this sence, the draft recommends a variance from the standard IPsec architecture behaviour. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Mon Nov 19 11:04:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJJ4L816789; Mon, 19 Nov 2001 11:04:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09919 Mon, 19 Nov 2001 13:15:22 -0500 (EST) Message-ID: <3BF94F3B.15F775A@redcreek.com> Date: Mon, 19 Nov 2001 10:28:11 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: juha.ollila@nokia.com CC: ipsec@lists.tislabs.com Subject: Re: OSPF (IPv6) and IPsec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk juha.ollila@nokia.com wrote: > > Hello! > > Is it possible to secure a multicast OSPF (IPv6) traffic? I think that > multicast traffic can be tunneled between the security gateways (a one to > one connection), but it isn't an end to end solution. IPsec specifications > mention Group Key Management Protocol (GKMP). Is it usable? MSEC and SMuG > are standardizing protocols for securing multicast traffic, but work is > still in progress. > > /Juha Howdy, You are right that multicast traffic can be tunneled between security gateways on a 1-to-1 basis. This ability is sufficient to model an OSPF point to point link with an IPsec tunnel. But it is insufficient to model an OSPF broadcast LAN of more than two neighbors. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Mon Nov 19 11:07:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJJ7N817151; Mon, 19 Nov 2001 11:07:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09901 Mon, 19 Nov 2001 13:11:56 -0500 (EST) Date: Mon, 19 Nov 2001 13:20:44 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: SOI: preshared In-Reply-To: <15353.11388.281025.686412@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 19 Nov 2001, Michael Thomas wrote: > 1) Should we deem peer-peer preshared keying bogus? I think the crucial requirement here is for some *simple* method of authentication, which can work effectively without outside assistance or elaborate supporting infrastructure, as a fallback measure for use in simple or constrained situations and in troubleshooting. As a historical analogy, consider hosts.txt (aka /etc/hosts) vs. DNS. The simple mechanism doesn't have to scale, and it doesn't have to be particularly convenient to administer, but it should be there. There is no strong reason why the simple mechanism can't be public-key signatures rather than shared secrets. Public keys are immensely superior to shared secrets in most ways, and as we've demonstrated with FreeS/WAN, they don't have to be much more complicated to use. (There's a widespread myth that you can't do public keys without certificates; not so.) Anything involving a PKI definitely does not qualify. > 2) If not, should SOI inherently be a dual (triple...) > authentication mechanism protocol? > 3) If so, how do we bound the authentication > mechanisms to keep IKE manageable? There needs to be an easy-to-administer highly-scalable mechanism for large-scale use, and a dead-simple zero-infrastructure mechanism for experimenting, constrained situations, and troubleshooting. If those mechanisms can't be the same at the keying-protocol level -- we think they can, by the way -- then that's two. There is no requirement for more. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 19 11:31:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJJV1818349; Mon, 19 Nov 2001 11:31:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10009 Mon, 19 Nov 2001 13:33:14 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.21128.347487.347567@pkoning.dev.equallogic.com> Date: Mon, 19 Nov 2001 13:42:16 -0500 (EST) From: Paul Koning To: mat@cisco.com Cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: <200111191328.IAA26753@ietf.org> <15353.12478.158520.373309@thomasm-u1.cisco.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Thomas writes: Michael> ...2) SOI SHOULD provide a means to protect identities. SOI Michael> MUST make protection optional if it reduces the overall Michael> number of messages to establish a SA. A SOI peer MUST NOT Michael> protect identities by default. Michael> I expect that the last statement is controversial so let me Michael> explain: IMO, identity protection is overblown. If by simple Michael> traffic analysis I see a static IP address for a server Michael> which I can reverse map, and even a dynamic address which I Michael> can reverse map to a particular POP, a determined attacker Michael> is probably going to have a pretty good idea ... That may be a valid analysis. (I'm not going to take a position on that here.) However, it does not justify the text you proposed. What it would justify is: 2) SOI SHOULD provide a means to protect identities. SOI MUST make protection optional if it reduces the overall number of messages to establish a SA. A SOI peer MAY protect identities by default. That would fit the notion that identity protection is not all that useful. The text you proposed would be appropriate if identity protection is actually a bad idea. For example, if it can only be done at significant expense in time (messages, computation) or memory. Is that the case? You did not say so. If identity protection does not come at a significant cost, there is no technical reason to prohibit it being the default for some implementations. paul From owner-ipsec@lists.tislabs.com Mon Nov 19 12:04:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJK4D819780; Mon, 19 Nov 2001 12:04:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10112 Mon, 19 Nov 2001 14:03:17 -0500 (EST) Message-ID: <3BF9599C.1060300@isi.edu> Date: Mon, 19 Nov 2001 11:12:28 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011107 X-Accept-Language: en, de MIME-Version: 1.0 To: Ricky Charlet CC: Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <9A761F39C9097F42977EAD1565F77E09243A20@EXC2K05A.cselt.it> <3BF945E7.D5576D91@redcreek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, replying to a number of issues brought up in this thread: Giaretta Gerardo wrote: > I have a question about using ipsec in tunnel mode together with > dynamic routing: I read draft-touch-ipsec-vpn-01.txt but I'm not > sure that I understood it clearly. We are currently preparing an update to this expired draft for the next IETF; it should be ready sometime this week. The basic idea of our draft is to allow IPsec transport mode together with IPIP tunnels as an alternative to IPsec tunnel mode. In that case, routing is based on virtual (tunnel) interfaces, and IPsec is applied after routing (unlike IPsec tunnel mode, which encrypts and then routes in one step). Derek Atkins wrote: > You should not use IPsec on a hop-by-hop basis. Assuming A and D are > your Security Gateways, all packets should be encrypted between A > and D, regardless of the path they take. If your goal is to create a simple VPN to secure traffic between X and Y, that is sufficient. If you are trying to create a multi-hop, secure, virtual topology connecting X and Y, this is too limited. Derek Atkins wrote: > The problem, of course, is detecting when a tunnel endpoint goes > down. This is a problem with any kind of virtual tunnel, not just > IPsec. With link-layer neighbors you can use the lower-layer to > detect a downed link; it's more difficult with a virtual tunnel. Not so. Any routing daemon (we tested gated and mrtd) will detect tunnel link failure like it detects failures of physical links. This is mostly a configuration issue. Giaretta Gerardo wrote: > ok, I can understand that the hop-by-hop example works only if I route > before I encrypt, but in ipsec documentation (i mean in ipsec RFCs), i > think it's not clear if the routing comes before, the encryption or > viceversa. Is it implementation dependent? As far as I know, the RFCs do not address this. We follow the developments of the major free IPsec implementations, and it looks like most started out based on packet filters, and IPsec tunnel mode encapsulation was handled by the IPsec stack, not existing IPIP tunnels in the system. On outbound, packet filter processing usually occurs before routing, and so we ended up with the IPsec tunnel mode behavior we see today. (Which is fine for many cases where a simple VPN is what you want.) Ricky Charlet wrote: > One large point to keep in mind about that draft is that its intended > purpose is to create overlay networks. The interested audience for > this is comparatively small. It goes beyond the aims and purposed of > creating secure VPN networks. Not necessarily. Using IPIP tunnels + ipsec transport mode is a full replacement for IPsec tunnel mode, i.e. you're not loosing anything by always using the former instead of the latter. Thus, you can use our approach to "only" create secure VPNs, with don't need dynamic routing. Ricky Charlet wrote: > On, the other hand, I could be totally wrong and you may have asked > exactly what you meant. In that case, keep in mind that Joe Touch's > draft aslo recommends making routing decisions before encapsulation > to avoid just the example problem you bring up. In this sence, the > draft recommends a variance from the standard IPsec architecture > behaviour. Exactly. The draft argues for allowing IPIP + IPsec transport mode as an *alternative* for IPsec tunnel mode. We aren't trying to replace it. And the driving issue behind it was exactly to allow dynamic routing over IPsec-secured, multi-hop, virtual topologies. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California From owner-ipsec@lists.tislabs.com Mon Nov 19 12:16:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJKGl820306; Mon, 19 Nov 2001 12:16:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10166 Mon, 19 Nov 2001 14:29:46 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Lars Eggert Cc: Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Nov 2001 14:38:57 -0500 Message-Id: <20011119193857.6C4687B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3BF9599C.1060300@isi.edu>, Lars Eggert writes: >Hi, > >replying to a number of issues brought up in this thread: > >Giaretta Gerardo wrote: > > I have a question about using ipsec in tunnel mode together with > > dynamic routing: I read draft-touch-ipsec-vpn-01.txt but I'm not > > sure that I understood it clearly. > >We are currently preparing an update to this expired draft for the >next IETF; it should be ready sometime this week. > >The basic idea of our draft is to allow IPsec transport mode together >with IPIP tunnels as an alternative to IPsec tunnel mode. In that case, >routing is based on virtual (tunnel) interfaces, and IPsec is applied >after routing (unlike IPsec tunnel mode, which encrypts and then routes >in one step). > While I'm not certain I understand what problem you're trying to solve that isn't already solved by tunnel mode, there are some weaknesses in this scheme as you've outlined it here. First, unless you have port-specific routing, you can't implement the full glory of IPsec SPDs (I'm perfectly willing to listen if you want to say that that's a feature, not a bug). Second, I'm not sure that you can easily check incoming packets against your policy table, given this model. And that's important. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Mon Nov 19 12:21:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJKLU820447; Mon, 19 Nov 2001 12:21:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10180 Mon, 19 Nov 2001 14:31:51 -0500 (EST) Message-Id: <5.1.0.14.0.20011119202340.031d9d30@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 Nov 2001 20:32:27 +0100 To: ipsec@lists.tislabs.com From: Joern Sierwald Subject: Re: SOI: identity protection and DOS In-Reply-To: <15353.21128.347487.347567@pkoning.dev.equallogic.com> References: <200111191328.IAA26753@ietf.org> <15353.12478.158520.373309@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id OAA10138 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:42 19.11.2001 -0500, you wrote: > >>>>> "Michael" == Michael Thomas writes: > > Michael> ...2) SOI SHOULD provide a means to protect identities. SOI > Michael> MUST make protection optional if it reduces the overall > Michael> number of messages to establish a SA. A SOI peer MUST NOT > Michael> protect identities by default. > > Michael> I expect that the last statement is controversial so let me > Michael> explain: IMO, identity protection is overblown. If by simple > Michael> traffic analysis I see a static IP address for a server > Michael> which I can reverse map, and even a dynamic address which I > Michael> can reverse map to a particular POP, a determined attacker > Michael> is probably going to have a pretty good idea ... > >That may be a valid analysis. (I'm not going to take a position on >that here.) > >However, it does not justify the text you proposed. What it would >justify is: > >2) SOI SHOULD provide a means to protect > identities. SOI MUST make protection optional > if it reduces the overall number of messages > to establish a SA. A SOI peer MAY protect > identities by default. > >That would fit the notion that identity protection is not all that >useful. > >The text you proposed would be appropriate if identity protection is >actually a bad idea. For example, if it can only be done at >significant expense in time (messages, computation) or memory. Is >that the case? You did not say so. > >If identity protection does not come at a significant cost, there is >no technical reason to prohibit it being the default for some >implementations. > > paul VPN are mostly used in two ways: (1) Gateway to Gateway encryption, to link LANs, or (2) Laptop/home user to Gateway, to let remote users into the company LAN. For (2), the laptop may be lost, so a safe authentication method is needed. You can use one-time-password or code-generating tokens, but the natural solution for IKE is an RSA smartcard. Now, these are usually fit with keys and certificates before the VPN vendor or sales guy can state his opinion. As a result, the DN of the cert can contain all kind of stuff. Like email address. Birthday. Home address. social security number. I know of one country (Finland) where you can get your personal ID card with an RSA chip in it (at the local police station), and yes, you can use that for a VPN. Having _that_ DN in cleartext over the net is NOT a good idea. Very much in favour of identity protection, Jörn Sierwald F-Secure Corp From owner-ipsec@lists.tislabs.com Mon Nov 19 12:22:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJKMt820482; Mon, 19 Nov 2001 12:22:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10210 Mon, 19 Nov 2001 14:37:41 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.24948.198728.631259@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 11:45:56 -0800 (PST) To: Henry Spencer Cc: IP Security List Subject: Re: SOI: preshared In-Reply-To: References: <15353.11388.281025.686412@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The consequence of using naked public keys in lieu of symmetric keys is that you incur the cost of both a DH and a RSA operation. You could conceivably get rid of the DH if you don't care about identity, but for preshared keys it seems questionable why you'd want to do _either_. Mike Henry Spencer writes: > On Mon, 19 Nov 2001, Michael Thomas wrote: > > 1) Should we deem peer-peer preshared keying bogus? > > I think the crucial requirement here is for some *simple* method of > authentication, which can work effectively without outside assistance or > elaborate supporting infrastructure, as a fallback measure for use in > simple or constrained situations and in troubleshooting. As a historical > analogy, consider hosts.txt (aka /etc/hosts) vs. DNS. > > The simple mechanism doesn't have to scale, and it doesn't have to be > particularly convenient to administer, but it should be there. > > There is no strong reason why the simple mechanism can't be public-key > signatures rather than shared secrets. Public keys are immensely superior > to shared secrets in most ways, and as we've demonstrated with FreeS/WAN, > they don't have to be much more complicated to use. (There's a widespread > myth that you can't do public keys without certificates; not so.) > > Anything involving a PKI definitely does not qualify. > > > 2) If not, should SOI inherently be a dual (triple...) > > authentication mechanism protocol? > > 3) If so, how do we bound the authentication > > mechanisms to keep IKE manageable? > > There needs to be an easy-to-administer highly-scalable mechanism for > large-scale use, and a dead-simple zero-infrastructure mechanism for > experimenting, constrained situations, and troubleshooting. If those > mechanisms can't be the same at the keying-protocol level -- we think they > can, by the way -- then that's two. There is no requirement for more. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Nov 19 12:24:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJKOP820531; Mon, 19 Nov 2001 12:24:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10216 Mon, 19 Nov 2001 14:37:56 -0500 (EST) To: "Steven M. Bellovin" Cc: Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> From: Derek Atkins Date: 19 Nov 2001 14:47:10 -0500 In-Reply-To: "Steven M. Bellovin"'s message of "Mon, 19 Nov 2001 14:38:57 -0500" Message-ID: Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If all you want is to use IPsec for packet encryption and don't care about access control, this should suffice. However you wont get source-address verification of packets. -derek "Steven M. Bellovin" writes: > While I'm not certain I understand what problem you're trying to solve > that isn't already solved by tunnel mode, there are some weaknesses in > this scheme as you've outlined it here. First, unless you have > port-specific routing, you can't implement the full glory of IPsec SPDs > (I'm perfectly willing to listen if you want to say that that's a > feature, not a bug). Second, I'm not sure that you can easily check > incoming packets against your policy table, given this model. And > that's important. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Nov 19 12:28:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJKSb820651; Mon, 19 Nov 2001 12:28:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10225 Mon, 19 Nov 2001 14:40:29 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Derek Atkins Cc: Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 Nov 2001 14:49:41 -0500 Message-Id: <20011119194941.403247C00@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Derek Atkins writes: >If all you want is to use IPsec for packet encryption and don't care >about access control, this should suffice. However you wont get >source-address verification of packets. > It's not source address verification I'm concerned about, it's connection hijacking and DOSing. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Mon Nov 19 12:37:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJKbr820951; Mon, 19 Nov 2001 12:37:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10254 Mon, 19 Nov 2001 14:46:07 -0500 (EST) Message-Id: <200111191955.OAA16361@bcn.East.Sun.COM> Date: Mon, 19 Nov 2001 14:55:26 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: IKEv2 (son-of-ike) draft To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: NoPI9eIPL6XZXDlNjxnf9w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk And to answer some of the recent email on the list...this protocol does maintain the phase 1/phase 2 notion, but sets up both phase 1 and phase 2 in a single 2-round-trip exchange. After the initial exchange, additional SAs can be set up, or the SA can be rekeyed, with a single round trip. And it does identity hiding of both ends. Most of the work was in rewriting the three documents into a single self-contained document, and cleaning up the "networking" type issues and overly complex encodings such as the SA payload. Radia ------------- Begin Forwarded Message ------------- To: ipsec@lists.tislabs.com From: dharkins@tibernian.com Subject: IKEv2 (son-of-ike) draft MIME-Version: 1.0 Content-ID: <2377.1006067452.1@SailPix.com> This draft was submitted but hasn't shown up yet in the repository (the I-D editor is, no doubt, swamped) so in the interest of giving people more time to look at it prior to Salt Lake here's a link: http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt Please send comments to the list. Dan. ------------- End Forwarded Message ------------- From owner-ipsec@lists.tislabs.com Mon Nov 19 12:38:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJKcZ820977; Mon, 19 Nov 2001 12:38:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10274 Mon, 19 Nov 2001 14:50:08 -0500 (EST) To: "Steven M. Bellovin" Cc: Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119194941.403247C00@berkshire.research.att.com> From: Derek Atkins Date: 19 Nov 2001 14:59:27 -0500 In-Reply-To: "Steven M. Bellovin"'s message of "Mon, 19 Nov 2001 14:49:41 -0500" Message-ID: Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" writes: > It's not source address verification I'm concerned about, it's > connection hijacking and DOSing. If you're going to route on top of IPsec (i.e. use IPsec tunnels as links to be routed across) then you don't get any additional protection anyways, because you truly are not limiting the packets traversing your network. Aren't dynamic routing and access-control checks mutually exclusive in the "core"? How would a core router know whether there is a real path for a packet through a peer? This seems to boil down to secure routing paths, which would seem out of scope for IPsec, no? > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Nov 19 13:14:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLEK823023; Mon, 19 Nov 2001 13:14:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10569 Mon, 19 Nov 2001 15:28:59 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE0118844D@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Giaretta Gerardo'" , Derek Atkins Cc: ipsec@lists.tislabs.com, "'Ricky Charlet'" Subject: RE: ipsec in tunnel mode and dynamic routing Date: Mon, 19 Nov 2001 20:34:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA10559 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some VPN operations may choose to run dynamic routing protocol through the tunnel. The routing keep-alive will be able to detect that an IPsec goes down and then adjust the route accordingly. In your example, assume A-B tunnel is the preferred path and A-C tunnel is the backup path. When A-B tunnel is down, traffic can go through A-c tunnel. All this discussion bring another interesting question: How IPsec tunnel interacts with routing? Unless IPsec tunnel is implemented as a virtual interface, it is hard to run routing through tunnel directly. I know many vendors choose not to implement IPsec tunnel as a separate virtual interface. -----Original Message----- From: Giaretta Gerardo [mailto:Gerardo.Giaretta@TILAB.COM] Sent: Monday, November 19, 2001 12:05 PM To: Derek Atkins Cc: ipsec@lists.tislabs.com Subject: RE: ipsec in tunnel mode and dynamic routing ok, I can understand that the hop-by-hop example works only if I route before I encrypt, but in ipsec documentation (i mean in ipsec RFCs), i think it's not clear if the routing comes before the encryption or viceversa. Is it implementation dependent? Gerardo -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: lunedì 19 novembre 2001 17.33 To: Giaretta Gerardo Cc: ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing The hop-by-hop example only works if you route _before_ you encrypt... In order words, you route on top of IPsec tunnels. You can do this if you consider your IPsec tunnels as routable interfaces. For example, in your picture: B / \ X - A D - Y \ / C .. if A has tunnels to B and C, it can use any routing protocol to choose which tunnel (B or C) it will use. When a packet comes in from X, it gets routed out a tunnel, and before it gets sent out it gets encrypted. The problem, of course, is detecting when a tunnel endpoint goes down. This is a problem with any kind of virtual tunnel, not just IPsec. With link-layer neighbors you can use the lower-layer to detect a downed link; it's more difficult with a virtual tunnel. However, assuming you can detect a downed tunnel, the routing protocol would happily use the other tunnel and encrypt to C instead of B. Note that encryption has to occur _after_ routing, otherwise you may encrypt to the wrong destination. -derek Giaretta Gerardo writes: > ok this is right and I understand it, but the hop-by-hop basis example > is made in the draft.=20 Only, I want to understand the problems that > arise when you use both ipsec and dynamic routing. > In the draft it's explained only if you assume a hop by hop situation. > Is this the only situation > in whch problems arise? > > Gerardo -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Nov 19 13:14:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLEc823077; Mon, 19 Nov 2001 13:14:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10466 Mon, 19 Nov 2001 15:16:16 -0500 (EST) Date: Mon, 19 Nov 2001 15:25:04 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: SOI: preshared In-Reply-To: <15353.24948.198728.631259@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 19 Nov 2001, Michael Thomas wrote: > The consequence of using naked public keys in lieu > of symmetric keys is that you incur the cost of > both a DH and a RSA operation... Correct. That's the same overhead as experienced with certificates, etc., so if it is acceptable for large-scale high-volume use, it should be okay for a fallback mode intended for more limited applications. > You could > conceivably get rid of the DH if you don't care > about identity, but for preshared keys it seems > questionable why you'd want to do _either_. Today's preshared keys are for authentication, not encryption, so the DH step is not optional -- they often are things like English phrases, which may be okay for authentication but definitely does not provide encryption strong enough to adequately protect session-key exchanges. A proposal for an ultra-low-overhead IKE authentication mode, using strong preshared keys to eliminate the DH step as well, is a separate issue from whether we should retain the existing preshared-key mode (which does not fit that description). Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 19 13:15:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLF6823123; Mon, 19 Nov 2001 13:15:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10573 Mon, 19 Nov 2001 15:29:03 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15353.27940.213620.608331@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 12:35:48 -0800 (PST) To: Joern Sierwald Cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <5.1.0.14.0.20011119202340.031d9d30@dfintra.f-secure.com> References: <200111191328.IAA26753@ietf.org> <15353.12478.158520.373309@thomasm-u1.cisco.com> <5.1.0.14.0.20011119202340.031d9d30@dfintra.f-secure.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA10563 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Since certificates are essentially public information, anybody who puts private information on one deserves what they get. After all, what if an unscrupulous site demands that cert and then publishes its contents to spammers-r-us.com? Mike Joern Sierwald writes: > At 13:42 19.11.2001 -0500, you wrote: > > >>>>> "Michael" == Michael Thomas writes: > > > > Michael> ...2) SOI SHOULD provide a means to protect identities. SOI > > Michael> MUST make protection optional if it reduces the overall > > Michael> number of messages to establish a SA. A SOI peer MUST NOT > > Michael> protect identities by default. > > > > Michael> I expect that the last statement is controversial so let me > > Michael> explain: IMO, identity protection is overblown. If by simple > > Michael> traffic analysis I see a static IP address for a server > > Michael> which I can reverse map, and even a dynamic address which I > > Michael> can reverse map to a particular POP, a determined attacker > > Michael> is probably going to have a pretty good idea ... > > > >That may be a valid analysis. (I'm not going to take a position on > >that here.) > > > >However, it does not justify the text you proposed. What it would > >justify is: > > > >2) SOI SHOULD provide a means to protect > > identities. SOI MUST make protection optional > > if it reduces the overall number of messages > > to establish a SA. A SOI peer MAY protect > > identities by default. > > > >That would fit the notion that identity protection is not all that > >useful. > > > >The text you proposed would be appropriate if identity protection is > >actually a bad idea. For example, if it can only be done at > >significant expense in time (messages, computation) or memory. Is > >that the case? You did not say so. > > > >If identity protection does not come at a significant cost, there is > >no technical reason to prohibit it being the default for some > >implementations. > > > > paul > > VPN are mostly used in two ways: (1) Gateway to Gateway encryption, > to link LANs, or (2) Laptop/home user to Gateway, to let remote users > into the company LAN. > > For (2), the laptop may be lost, so a safe authentication method is needed. > You can use one-time-password or code-generating tokens, but the > natural solution for IKE is an RSA smartcard. > > Now, these are usually fit with keys and certificates before the > VPN vendor or sales guy can state his opinion. As a result, the > DN of the cert can contain all kind of stuff. Like email address. > Birthday. Home address. social security number. > I know of one country (Finland) where you can get your > personal ID card with an RSA chip in it (at the local police station), > and yes, you can use that for a VPN. > > Having _that_ DN in cleartext over the net is NOT a good idea. > > Very much in favour of identity protection, > > Jörn Sierwald > F-Secure Corp > From owner-ipsec@lists.tislabs.com Mon Nov 19 13:20:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLKC823510; Mon, 19 Nov 2001 13:20:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10594 Mon, 19 Nov 2001 15:36:08 -0500 (EST) To: Henry Spencer Cc: ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: From: Derek Atkins Date: 19 Nov 2001 15:44:41 -0500 In-Reply-To: Henry Spencer's message of "Mon, 19 Nov 2001 15:29:53 -0500 (EST)" Message-ID: Lines: 40 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk But that's not "in the core". That is at the edge. To return to the picture: B / \ X - A D - Y \ / C The 'core' would be B and C; the edges would be A and D. A and D can still be multihomed, and you get an N*M number of tunnels between the M addrs of A and the N addrs of D. But traversals through B and C don't work that way. For example, packets could traverse from C to B via A... How do you "access control" that? And if you don't then you're no longer doing open dynamic routing.. -derek Henry Spencer writes: > On 19 Nov 2001, Derek Atkins wrote: > > ...Aren't dynamic routing and access-control > > checks mutually exclusive in the "core"? > > Not necessarily. Dynamic routing doesn't have to be an all-or-nothing > process; it's quite conceivable to have dynamic routing operating within > access-control restrictions. The simple example is having separate IPsec > connections to two different gateways into the same corporate network, to > protect your traffic against gateway outages. People really want to be > able to do redundant, dynamically-selected paths for IPsec traffic. > > Henry Spencer > henry@spsystems.net > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Mon Nov 19 13:23:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJLNr823903; Mon, 19 Nov 2001 13:23:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10507 Mon, 19 Nov 2001 15:21:42 -0500 (EST) Date: Mon, 19 Nov 2001 15:29:53 -0500 (EST) From: Henry Spencer To: Derek Atkins cc: ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 19 Nov 2001, Derek Atkins wrote: > ...Aren't dynamic routing and access-control > checks mutually exclusive in the "core"? Not necessarily. Dynamic routing doesn't have to be an all-or-nothing process; it's quite conceivable to have dynamic routing operating within access-control restrictions. The simple example is having separate IPsec connections to two different gateways into the same corporate network, to protect your traffic against gateway outages. People really want to be able to do redundant, dynamically-selected paths for IPsec traffic. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 19 14:38:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMc8827989; Mon, 19 Nov 2001 14:38:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10794 Mon, 19 Nov 2001 16:49:54 -0500 (EST) Message-ID: <3BF98181.F945D746@redcreek.com> Date: Mon, 19 Nov 2001 14:02:41 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lars Eggert CC: ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <9A761F39C9097F42977EAD1565F77E09243A20@EXC2K05A.cselt.it> <3BF945E7.D5576D91@redcreek.com> <3BF9599C.1060300@isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, comment below... > > Ricky Charlet wrote: > > One large point to keep in mind about that draft is that its intended > > purpose is to create overlay networks. The interested audience for > > this is comparatively small. It goes beyond the aims and purposed of > > creating secure VPN networks. > > Not necessarily. Using IPIP tunnels + ipsec transport mode is a full > replacement for IPsec tunnel mode, i.e. you're not loosing anything > by always using the former instead of the latter. Thus, you can use > our approach to "only" create secure VPNs, with don't need dynamic > routing. > First off, I want to say that I respect the IPsec based overlay network stuff that you and Joe have done. I am not commenting negatively on that work. But I have never before considered it as a replacement for our current IPsec tunnel mode. I was not aware that this was part of your vision for IPIP encap + IPsecTransport. And I think you may be overreaching in that aim. Even if the IPIPencap+IPsecTransport preserved all the security properties of IPsec Tunnels (and I would need to be convinced of that), It still introduces a large bit of management complexity. IPsec gateways would be responsible for encapsulating to and securing with a peer who was selected by a dynamic routing protocol rather than administratively configured. It seems on the face of it, that a VPN network which can have its peers altered by routing protocols is more open to DOS in particular and less trustable in general. It also requires administrators to configure security policy on all IPsec gateways which MIGHT be selected as peers - and that seems a burdensome task and difficult thing to keep current. If you don't mind, I've grown quite comfortable with tunnel mode and would like to keep it for my VPNs if there is no pressing reason to change. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Mon Nov 19 14:39:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMde828150; Mon, 19 Nov 2001 14:39:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10733 Mon, 19 Nov 2001 16:23:05 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15353.24948.198728.631259@thomasm-u1.cisco.com> References: <15353.11388.281025.686412@thomasm-u1.cisco.com> <15353.24948.198728.631259@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 13:29:16 -0800 To: IP Security List From: Paul Hoffman / VPNC Subject: Re: SOI: preshared Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:45 AM -0800 11/19/01, Michael Thomas wrote: >The consequence of using naked public keys in lieu >of symmetric keys is that you incur the cost of >both a DH and a RSA operation. You could >conceivably get rid of the DH if you don't care >about identity, but for preshared keys it seems >questionable why you'd want to do _either_. It doesn't have to be a bare public key. A self-signed cert has other signed attributes in it, such as the key validity date and an identity. The recipient simply needs to pull the public key out of the cert to check that key against its set of trusted public keys. (One doesn't need to trust this as a root cert: it is easy to make a policy of "if I get a self-signed cert as an identifier, I won't do any chaining, even if the cert says chaining is OK"). Using self-signed certs is the method that JFK currently uses to allow simple trust between two parties without needing a PKI. There is no shared-secret mode. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Nov 19 14:42:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJMgP828462; Mon, 19 Nov 2001 14:42:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA10795 Mon, 19 Nov 2001 16:49:55 -0500 (EST) Message-ID: <3BF98092.2050609@isi.edu> Date: Mon, 19 Nov 2001 13:58:42 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steven M. Bellovin wrote: > In message <3BF9599C.1060300@isi.edu>, Lars Eggert writes: > >>The basic idea of our draft is to allow IPsec transport mode together >>with IPIP tunnels as an alternative to IPsec tunnel mode. In that case, >>routing is based on virtual (tunnel) interfaces, and IPsec is applied >>after routing (unlike IPsec tunnel mode, which encrypts and then routes >>in one step). > > While I'm not certain I understand what problem you're trying to solve > that isn't already solved by tunnel mode, there are some weaknesses in > this scheme as you've outlined it here. First, unless you have > port-specific routing, you can't implement the full glory of IPsec SPDs > (I'm perfectly willing to listen if you want to say that that's a > feature, not a bug). Second, I'm not sure that you can easily check > incoming packets against your policy table, given this model. And > that's important. Steve - Our ID has been out for quite a while, and was presented in Adelaide in Spring 2000 (it even expired, but a copy is available on my website at http://www.isi.edu/touch/pubs/draft-touch-ipsec-vpn-01.txt) The ID describes in detail: - the problem we're trying to solve and why it is not solved by tunnel mode - how incoming packets are checked, and why checking them is already required (turns out you can use our mode for outbound and tunnel mode for inbound just fine, BTW) Can you rephrase your concerns in the context of the content of the draft?? Thanks, Joe From owner-ipsec@lists.tislabs.com Mon Nov 19 15:01:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJN12829460; Mon, 19 Nov 2001 15:01:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10827 Mon, 19 Nov 2001 17:05:10 -0500 (EST) Message-ID: <3BF98426.60604@isi.edu> Date: Mon, 19 Nov 2001 14:13:58 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Ricky Charlet CC: Lars Eggert , ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <9A761F39C9097F42977EAD1565F77E09243A20@EXC2K05A.cselt.it> <3BF945E7.D5576D91@redcreek.com> <3BF9599C.1060300@isi.edu> <3BF98181.F945D746@redcreek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ricky Charlet wrote: > Howdy, > > comment below... > > >>Ricky Charlet wrote: >> > One large point to keep in mind about that draft is that its intended >> > purpose is to create overlay networks. The interested audience for >> > this is comparatively small. It goes beyond the aims and purposed of >> > creating secure VPN networks. >> >>Not necessarily. Using IPIP tunnels + ipsec transport mode is a full >>replacement for IPsec tunnel mode, i.e. you're not loosing anything >>by always using the former instead of the latter. Thus, you can use >>our approach to "only" create secure VPNs, with don't need dynamic >>routing. >> >> > > First off, I want to say that I respect the IPsec based overlay network > stuff that you and Joe have done. I am not commenting negatively on that > work. But I have never before considered it as a replacement for our > current IPsec tunnel mode. I was not aware that this was part of your > vision for IPIP encap + IPsecTransport. > > And I think you may be overreaching in that aim. Even if the > IPIPencap+IPsecTransport preserved all the security properties of IPsec > Tunnels (and I would need to be convinced of that), Please phrase future discussions in the context of the draft's discussin of these issues. > It still introduces > a large bit of management complexity. IPsec gateways would be > responsible for encapsulating to and securing with a peer who was > selected by a dynamic routing protocol rather than administratively > configured. It seems on the face of it, that a VPN network which can > have its peers altered by routing protocols is more open to DOS in > particular and less trustable in general. It also requires > administrators to configure security policy on all IPsec gateways which > MIGHT be selected as peers - and that seems a burdensome task and > difficult thing to keep current. We're not advocating hop-by-hop IPsec per se. We need HBH IPsec for overlay network deployment, esp. where the endpoints are not necessarily IPsec-capable. Decoupling tunneling from IPsec has advantages any time there are multiple keyed paths with dynamic selection of paths based on routing decisions, which could be E2E as well. > If you don't mind, I've grown quite comfortable with tunnel mode and > would like to keep it for my VPNs if there is no pressing reason to > change. The fundamental issue is that you (generally, not personally) and everyone else (multicast, mobile IP, etc.) have their own tunnel system, and they're all integrated. We're proposing a modular approach, and have already discussed (in the ID) both its advantages and security. Tunnel mode, IMO, is a complication of IPsec, not a simplification. The post-processing checks of iteratively forwarded packets (packets that continue to be processed by the forwarding after decryption) are already required by RFC2401 (i.e., tagging the packet and checking those tags). RFC2401 tunnel mode determines the encryption key AND the outer unnel header by the (pre-IPsec) IP packet header. The first step may be IPsec, but the second is forwarding. Having IPsec replicate forwarding requires sychronous management of the key database with the forwarding tables. This too is described in detail in our ID. Joe From owner-ipsec@lists.tislabs.com Mon Nov 19 15:07:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJN7m829586; Mon, 19 Nov 2001 15:07:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10863 Mon, 19 Nov 2001 17:19:33 -0500 (EST) Date: Mon, 19 Nov 2001 17:28:10 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15353.12478.158520.373309@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 19 Nov 2001, Michael Thomas wrote: > ...IMO, identity protection is > overblown. If by simple traffic analysis I see a > static IP address for a server which I can reverse > map, and even a dynamic address which I can > reverse map to a particular POP, a determined > attacker is probably going to have a pretty good > idea that you're visiting naughtybits.com... As others have noted already, an identity can be more than just an IP address, and protection for parts of it may be desirable. I would add that, other things being equal, the fullest possible protection of everything should be the default, not an option. That way, users with truly sensitive material aren't prominently advertised as such by the fact that they're the only ones using protection. (Of course, that "other things being equal" covers a multitude of sins. Whether identity protection justifies an extra round trip is a harder question than whether it justifies a few more CPU cycles.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 19 15:17:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJNH2829840; Mon, 19 Nov 2001 15:17:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10871 Mon, 19 Nov 2001 17:21:26 -0500 (EST) Message-ID: <3BF987FB.7070908@isi.edu> Date: Mon, 19 Nov 2001 14:30:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steven M. Bellovin wrote: > While I'm not certain I understand what problem you're trying to solve > that isn't already solved by tunnel mode, there are some weaknesses in > this scheme as you've outlined it here. First, unless you have > port-specific routing, you can't implement the full glory of IPsec SPDs > (I'm perfectly willing to listen if you want to say that that's a > feature, not a bug). FWIW - this is yet another place where I'd prefer to let firewall rules do their job, and IPsec to its. So yes, since I believe this can already be done with existing mechanisms, I don't care whether it defeats IPsec's ability to integrate it. (at least at first look that's how it appears) The "full glory" (IMO) here lies in modularization rather than a stovepipe. Joe From owner-ipsec@lists.tislabs.com Mon Nov 19 15:26:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJNQi800142; Mon, 19 Nov 2001 15:26:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10896 Mon, 19 Nov 2001 17:32:03 -0500 (EST) Message-ID: <3BF98A8C.1080308@isi.edu> Date: Mon, 19 Nov 2001 14:41:16 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011107 X-Accept-Language: en, de MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steven M. Bellovin wrote: > While I'm not certain I understand what problem you're trying to solve > that isn't already solved by tunnel mode, there are some weaknesses in > this scheme as you've outlined it here. First, unless you have > port-specific routing, you can't implement the full glory of IPsec SPDs Port-specific routing (or any other flavor of content-based routing) should be orthogonal to IPsec. In our scheme, a routing algorithm is simply an interchangeable module that decides where packets should go, and IPsec is applied when they go out. You can do content-based routing without IPsec with firewall rules (for example) - why shouldn't that be the right way to go with IPsec? Duplicating one (here: port-based) routing policy inside IPsec means that as soon as someone comes up with another routing idea, IPsec needs to be extended. IPsec re-implements many exising mechanisms (routing, firewalling, tunneling) that could all be handled outside IPsec - with the added benefit that if either of these components changes, IPsec needs not. (See IPsec-in-UDP, etc.) > Second, I'm not sure that you can easily check > incoming packets against your policy table, given this model. And > that's important. This is discussed in the ID. Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California From owner-ipsec@lists.tislabs.com Mon Nov 19 15:30:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJNUL800296; Mon, 19 Nov 2001 15:30:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10922 Mon, 19 Nov 2001 17:39:48 -0500 (EST) Message-ID: <3BF98C4A.80208@isi.edu> Date: Mon, 19 Nov 2001 14:48:42 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Joe Touch CC: "Steven M. Bellovin" , Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF98092.2050609@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Joe Touch wrote: > > Steve - > > Our ID has been out for quite a while, and was presented in Adelaide in > Spring 2000 (it even expired, but a copy is available on my website at > http://www.isi.edu/touch/pubs/draft-touch-ipsec-vpn-01.txt) FWIW, this information was provided for the recollection of those who attended. I appreciate that not everyone recalls all talks, and apologize if it appeared otherwise. However, since we're discussing a technique that was proposed in an ID, and the draft did discussion most of these issues (reasons why tunnel mode is insufficient, why we want hop-by-hop, how it is secure), I would like to direct the discussion of our proposed solution to occur in the context of the draft itself. While that version of the draft has expired (we're resubmitting an update tomorrow), the draft does discuss most of these issues in particular (and that version remains available on my website as posted earlier). Joe From owner-ipsec@lists.tislabs.com Mon Nov 19 15:39:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJNdN800487; Mon, 19 Nov 2001 15:39:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10978 Mon, 19 Nov 2001 17:48:14 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.36126.558016.555579@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 14:52:14 -0800 (PST) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15353.12478.158520.373309@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem with identity protection is that it is inherently unequal; it involves a round trip to collect the DH values as you point out. Also: I think I disagree with your "fullest" assessment since simple traffic analysis may shatter many false illusions about protected identities. Note that I'm not saying we should make it a non-requirement, only that we put it in the proper perspective. Mike Henry Spencer writes: > On Mon, 19 Nov 2001, Michael Thomas wrote: > > ...IMO, identity protection is > > overblown. If by simple traffic analysis I see a > > static IP address for a server which I can reverse > > map, and even a dynamic address which I can > > reverse map to a particular POP, a determined > > attacker is probably going to have a pretty good > > idea that you're visiting naughtybits.com... > > As others have noted already, an identity can be more than just an IP > address, and protection for parts of it may be desirable. > > I would add that, other things being equal, the fullest possible > protection of everything should be the default, not an option. That way, > users with truly sensitive material aren't prominently advertised as such > by the fact that they're the only ones using protection. > > (Of course, that "other things being equal" covers a multitude of sins. > Whether identity protection justifies an extra round trip is a harder > question than whether it justifies a few more CPU cycles.) > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Mon Nov 19 15:48:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJNmM800698; Mon, 19 Nov 2001 15:48:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA10996 Mon, 19 Nov 2001 17:57:25 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15353.36923.343768.950818@thomasm-u1.cisco.com> Date: Mon, 19 Nov 2001 15:05:31 -0800 (PST) To: Paul Hoffman / VPNC Cc: IP Security List Subject: Re: SOI: preshared In-Reply-To: References: <15353.11388.281025.686412@thomasm-u1.cisco.com> <15353.24948.198728.631259@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sure. Same considerations apply though. Mike Paul Hoffman / VPNC writes: > At 11:45 AM -0800 11/19/01, Michael Thomas wrote: > >The consequence of using naked public keys in lieu > >of symmetric keys is that you incur the cost of > >both a DH and a RSA operation. You could > >conceivably get rid of the DH if you don't care > >about identity, but for preshared keys it seems > >questionable why you'd want to do _either_. > > It doesn't have to be a bare public key. A self-signed cert has other > signed attributes in it, such as the key validity date and an > identity. The recipient simply needs to pull the public key out of > the cert to check that key against its set of trusted public keys. > (One doesn't need to trust this as a root cert: it is easy to make a > policy of "if I get a self-signed cert as an identifier, I won't do > any chaining, even if the cert says chaining is OK"). > > Using self-signed certs is the method that JFK currently uses to > allow simple trust between two parties without needing a PKI. There > is no shared-secret mode. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Nov 19 16:49:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK0nv802116; Mon, 19 Nov 2001 16:49:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11063 Mon, 19 Nov 2001 18:58:11 -0500 (EST) Date: Mon, 19 Nov 2001 19:06:51 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15353.36126.558016.555579@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 19 Nov 2001, Michael Thomas wrote: > ...I think I disagree with your "fullest" assessment > since simple traffic analysis may shatter many > false illusions about protected identities. I think you've missed my point slightly. If all key negotiation uses identity protection, then it is impossible to tell whether the results of such traffic analysis are valid: there is no way to determine whether non-trivial identity information was exchanged. But if protection is used only when there is something specific to protect, then the traffic analyst *knows* whether his results are applicable or not. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 19 17:00:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK10l802409; Mon, 19 Nov 2001 17:00:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11095 Mon, 19 Nov 2001 19:10:42 -0500 (EST) Date: Mon, 19 Nov 2001 19:19:21 -0500 (EST) From: Henry Spencer To: Joe Touch cc: ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing In-Reply-To: <3BF987FB.7070908@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 19 Nov 2001, Joe Touch wrote: > FWIW - this is yet another place where I'd prefer to let firewall rules > do their job, and IPsec to its. I think you're missing an important point: the "sec" in "IPsec" stands for "security", and that encompasses more than just encryption and authentication. In particular, packet access controls are *inherently* part of IP security; they are not a separate issue. IPsec's SPD *is* a firewall, and it is a necessary part of IPsec. > The "full glory" (IMO) here lies in modularization rather than a stovepipe. Modularization is all very well for *mechanisms*, but there has to be unified *policy* control of the mechanisms if real security is to result. There is nothing that says you can't implement the SPD using existing firewall machinery, but it has to be done somehow. Leaving the firewall in ignorance of what's going on with IPsec -- either by separating the two completely, or by losing information when IPsec throws a packet over the fence to the firewall -- does not work. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 19 17:17:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK1He802811; Mon, 19 Nov 2001 17:17:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA11133 Mon, 19 Nov 2001 19:30:48 -0500 (EST) Message-ID: <3BF9A648.9020508@isi.edu> Date: Mon, 19 Nov 2001 16:39:36 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011107 X-Accept-Language: en, de MIME-Version: 1.0 To: Henry Spencer CC: Joe Touch , ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > Modularization is all very well for *mechanisms*, but there has to be > unified *policy* control of the mechanisms if real security is to result. > There is nothing that says you can't implement the SPD using existing > firewall machinery, but it has to be done somehow. Leaving the firewall > in ignorance of what's going on with IPsec -- either by separating the two > completely, or by losing information when IPsec throws a packet over the > fence to the firewall -- does not work. Exactly! Retaining enough context during IPsec processing for later stages is required to make this work, and the ID discusses this. That said, most IPsec implementations choose the "do everything internally" approach, and duplicate just enough of existing mechanisms to make IPsec work, but not enough to make the need for existing mechanisms go away. Thus, you end up with a system with 5 different tunneling mechanisms and 3 different places that try to make routing decisions, and nothing integrates. So yes, we agree that security *policies* must cover much of network processing, but the *implementation* shouldn't need to re-implement every networking mechanisms inside IPsec (or SCTP for that matter...) Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California From owner-ipsec@lists.tislabs.com Mon Nov 19 20:59:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK4xe808473; Mon, 19 Nov 2001 20:59:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11425 Mon, 19 Nov 2001 23:00:57 -0500 (EST) Message-Id: <200111200202.fAK22ji07298@marajade.sandelman.ottawa.on.ca> To: Derek Atkins cc: ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing In-reply-to: Your message of "19 Nov 2001 14:59:27 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 19 Nov 2001 21:02:44 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Derek" == Derek Atkins writes: Derek> "Steven M. Bellovin" writes: >> It's not source address verification I'm concerned about, it's >> connection hijacking and DOSing. Derek> If you're going to route on top of IPsec (i.e. use IPsec tunnels as Derek> links to be routed across) then you don't get any additional Derek> protection anyways, because you truly are not limiting the packets Derek> traversing your network. Aren't dynamic routing and access-control Derek> checks mutually exclusive in the "core"? How would a core router know Derek> whether there is a real path for a packet through a peer? This seems Derek> to boil down to secure routing paths, which would seem out of scope Derek> for IPsec, no? Well, it isn't out of scope. RFC2401 essentially defines a standard firewall mechanism. Included in this is a form of ingress filtering. If these are core routers with no default routes, it may well be that they can not identify a single origin for packets with a given source address. That doesn't limit them to doing ingress filtering, it just makes it a lot weaker (you have to accept from any of several origins) The major challenge for this effort in my opinion is: 1) getting appropriate link status information. 2) getting IKE to negotiate these tunnels which have totally screwy (from IKE's point of view) selectors. One defers to the (policy enhanced) routing table. [you pretty much need a seperate routing table for packets with proto=50/51] ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO/m5woqHRg3pndX9AQF8kgP+PgIZB/TA9uPFsIqXgIXyUtQcrWhyP8TF HbrneTnbmu1LhBtZxt3Ow5kisI6DayFrTuQdmxqHJkPdQH8nqRAkEcjSp9pUU1/i T8KqXuOR/2nEXggBbdel4ibvgOD+9F9C61pspYvDQPtZgXWO8w4yV0XMjPyJmkU5 YPFX6aLNd/U= =7LID -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Nov 19 21:06:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK56Y808679; Mon, 19 Nov 2001 21:06:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11430 Mon, 19 Nov 2001 23:01:12 -0500 (EST) Message-Id: <200111200231.fAK2V0B07454@marajade.sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing In-reply-to: Your message of "19 Nov 2001 15:44:41 EST." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 19 Nov 2001 21:30:59 -0500 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >But that's not "in the core". That is at the edge. To return to the >picture: okay, can I add to it? Q / K B~~ \ ~ \ ~ X---A--Z D---Y ~ / ~ C~~ / P ~ - tunnels - -/\ - non-tunnel links {or course, A,B,C,D have to have some real links to get the ESP packets over! I'll show one of these, Z. For many of the xbone uses, my understanding is that in most cases, the types of packets that one wants to transit the tunnels are not supported by the intermediate links. Assume that Z can for this case.} >M addrs of A and the N addrs of D. But traversals through B and C >don't work that way. For example, packets could traverse from C to B >via A... How do you "access control" that? And if you don't then >you're no longer doing open dynamic routing.. Is the issue one of packets from Q and to P traversing through A, or ones from C to B? Why can't A know (since it is doing BGP with C and B through the tunnel, and with Z directly) that packets from P may come from C (via the tunnel), from Z (on a link) or perhaps even (if BGP decides this), via C-D-B or C-Z-B. A packet addressed from P may *NOT* come from K's link, however. I agree that this is not possible with the current 2401 defined set of selectors. If A/B/C/D wants to do this, I think they need to use a modified SPD. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBO/nAYoqHRg3pndX9AQEPfAP/U9SyLT3oCyuXZ4FmrnKdqpq3R5OwW7B+ yBUUcxcjkrjPl9zwWp8Is3KsATL4DMY0lUjRIISxgsuRHSsfDUy32BlpbV8FYbDu Iu+SBrFPL96BX0ddQYUu3OmoDQuA9It1jNQIsldTn/ZicF0QHgZEVjDLyrYiaoTN CavXnQ9NO88= =ZHLK -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Nov 19 22:20:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK6KI810310; Mon, 19 Nov 2001 22:20:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11546 Tue, 20 Nov 2001 00:25:51 -0500 (EST) Message-ID: <3BF9EB8B.D96E361@F-Secure.com> Date: Tue, 20 Nov 2001 07:35:07 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: <200111191328.IAA26753@ietf.org> <15353.12478.158520.373309@thomasm-u1.cisco.com> <5.1.0.14.0.20011119202340.031d9d30@dfintra.f-secure.com> <15353.27940.213620.608331@thomasm-u1.cisco.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 20 Nov 2001 05:35:07.0233 (UTC) FILETIME=[1CE34510:01C17185] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This WG cannot dictate what information is put to certificates, and the politicians being what they are, one should assume the worst. Note that a nation-wide certificate system has a big network-effect (economically speaking). If a nation gives each citizen an RSA chip, this *will* be used by corporations to identify customers. Why? It's the cheapest method for them. That is somewhat irrelevant to identity protection as seen by SOI, but is a good thing to bear in mind. Such a chip will also be an excellent method for intelligence communities to track suspects. Technically, I think the requirement should be that both of the identities MUST be protected against passive attackers. The question is if there should be any requirement as to active attackers. If such a requirement exists, my view is that the INITIATOR'S identity should be protected against active attackers. It is the initiator, the ordinary citizen, that is the target of a Three Letter Organization tracking. Ari Michael Thomas wrote: > > Since certificates are essentially public > information, anybody who puts private information > on one deserves what they get. After all, what if > an unscrupulous site demands that cert and then > publishes its contents to spammers-r-us.com? > > Mike > > Joern Sierwald writes: > > At 13:42 19.11.2001 -0500, you wrote: > > > >>>>> "Michael" == Michael Thomas writes: > > > > > > Michael> ...2) SOI SHOULD provide a means to protect identities. SOI > > > Michael> MUST make protection optional if it reduces the overall > > > Michael> number of messages to establish a SA. A SOI peer MUST NOT > > > Michael> protect identities by default. > > > > > > Michael> I expect that the last statement is controversial so let me > > > Michael> explain: IMO, identity protection is overblown. If by simple > > > Michael> traffic analysis I see a static IP address for a server > > > Michael> which I can reverse map, and even a dynamic address which I > > > Michael> can reverse map to a particular POP, a determined attacker > > > Michael> is probably going to have a pretty good idea ... > > > > > >That may be a valid analysis. (I'm not going to take a position on > > >that here.) > > > > > >However, it does not justify the text you proposed. What it would > > >justify is: > > > > > >2) SOI SHOULD provide a means to protect > > > identities. SOI MUST make protection optional > > > if it reduces the overall number of messages > > > to establish a SA. A SOI peer MAY protect > > > identities by default. > > > > > >That would fit the notion that identity protection is not all that > > >useful. > > > > > >The text you proposed would be appropriate if identity protection is > > >actually a bad idea. For example, if it can only be done at > > >significant expense in time (messages, computation) or memory. Is > > >that the case? You did not say so. > > > > > >If identity protection does not come at a significant cost, there is > > >no technical reason to prohibit it being the default for some > > >implementations. > > > > > > paul > > > > VPN are mostly used in two ways: (1) Gateway to Gateway encryption, > > to link LANs, or (2) Laptop/home user to Gateway, to let remote users > > into the company LAN. > > > > For (2), the laptop may be lost, so a safe authentication method is needed. > > You can use one-time-password or code-generating tokens, but the > > natural solution for IKE is an RSA smartcard. > > > > Now, these are usually fit with keys and certificates before the > > VPN vendor or sales guy can state his opinion. As a result, the > > DN of the cert can contain all kind of stuff. Like email address. > > Birthday. Home address. social security number. > > I know of one country (Finland) where you can get your > > personal ID card with an RSA chip in it (at the local police station), > > and yes, you can use that for a VPN. > > > > Having _that_ DN in cleartext over the net is NOT a good idea. > > > > Very much in favour of identity protection, > > > > Jörn Sierwald > > F-Secure Corp > > -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Mon Nov 19 23:15:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK7FB815168; Mon, 19 Nov 2001 23:15:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA11642 Tue, 20 Nov 2001 01:19:34 -0500 (EST) Message-ID: <3BF9F823.C07A090C@F-Secure.com> Date: Tue, 20 Nov 2001 08:28:51 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft References: <200111191955.OAA16361@bcn.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2001 06:28:52.0003 (UTC) FILETIME=[9F001F30:01C1718C] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I read through some of this draft, and mainly I'd say it looks very good. At least when compared to the current RFCs. Comments follow. - If, as I understand, there is to be a 'selection' as to what will be the next IKE, what chance has anybody against a protocol that is named draft-ietf-ipsec-ikev2-00.txt? As to the specifics of this protocol, in my view IKEv2 should have these kinds of requirements: - IKEv2 must enable all traffic to be protected as well as possible. If there is no common authentication method, a method to do just encryption should be provided. - IKEv2 must be well defined. For example, this draft doesn't state clearly how the critical bit is to be used (for each payload), notifies are unclear and should be accompanied by a state machine. I.e. if a cert payload with critical bit contains a DSS-signature, is it critical that you know "cert payload", support DSS-signatures, or what? - I have a strong dislike for the current VID method. It fails to provide several key requirements: a) Some problems are best solved by having a new payload in the first message. Like in ESPUDP IKE negotiation we could have used such a payload, but it's not possible with VIDs. (The bad thing about this is that it's not easy to change the protocol structure when official numbers are assigned.) b) A VID does not define how the protocol is to be extended, it just says that after you see this, you can twist IKE as much as you want. c) A VID does nothing to prevent conflicts between two drafts that just happen to allocate the same private use number. Here's an alternative to VIDs that we could consider: - A new payload is defined that defines exactly what private use numbers an implementation uses and what they are used for. In this way the private use numbers are viewed as variables, i.e. #define PAYLOAD_TYPE_128 "draft-my-draft-whatever-00.txt:nonce-thingie" etc., or use an OID instead - The initiator sends that in the first message, and following that payload a payload of type 128 may occur in the same message. The responder sends them in the first reply. - Responder will map only private use attributes that don't conflict with the initiator's choices. So a draft will never say "payload number 128", it will say "private payload that maps to xxxx". - IKEv2 would be easier to test if a method to authenticate using preshared secrets was provided. Like, how about hmac-sha-1 signatures? Ari Radia Perlman - Boston Center for Networking wrote: > > And to answer some of the recent email on the list...this > protocol does maintain the phase 1/phase 2 notion, but sets up > both phase 1 and phase 2 in a single 2-round-trip exchange. > After the initial exchange, additional SAs can be set up, > or the SA can be rekeyed, with a single round trip. And it > does identity hiding of both ends. > > Most of the work was in rewriting the three documents into > a single self-contained document, and cleaning up the "networking" > type issues and overly complex encodings such as > the SA payload. > > Radia > ------------- Begin Forwarded Message ------------- > > To: ipsec@lists.tislabs.com > From: dharkins@tibernian.com > Subject: IKEv2 (son-of-ike) draft > MIME-Version: 1.0 > Content-ID: <2377.1006067452.1@SailPix.com> > > This draft was submitted but hasn't shown up yet in the repository > (the I-D editor is, no doubt, swamped) so in the interest of giving > people more time to look at it prior to Salt Lake here's a link: > > http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt > > Please send comments to the list. > > Dan. > > ------------- End Forwarded Message ------------- -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Nov 20 00:23:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAK8No827574; Tue, 20 Nov 2001 00:23:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11725 Tue, 20 Nov 2001 02:27:17 -0500 (EST) Message-ID: <3BFA07D0.3060903@isi.edu> Date: Mon, 19 Nov 2001 23:35:44 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Henry Spencer CC: ipsec@lists.tislabs.com, xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: > On Mon, 19 Nov 2001, Joe Touch wrote: > >>FWIW - this is yet another place where I'd prefer to let firewall rules >>do their job, and IPsec to its. >> > > I think you're missing an important point: the "sec" in "IPsec" stands > for "security", and that encompasses more than just encryption and > authentication. In particular, packet access controls are *inherently* > part of IP security; they are not a separate issue. IPsec's SPD *is* a > firewall, and it is a necessary part of IPsec. IPsec already requires that a packet, once decrypted or authenticated, passes _with_ that information thoughout the rest of the IP processing. The packet is allowed to leave IPsec and re-enter. There is no reason to incorporate redundant functions in IPsec to make it monolithic. >>The "full glory" (IMO) here lies in modularization rather than a stovepipe. > > Modularization is all very well for *mechanisms*, Actually, it is intended for implementations as well. > but there has to be > unified *policy* control of the mechanisms if real security is to result. Which is why packets must carry the security info with them. > There is nothing that says you can't implement the SPD using existing > firewall machinery, but it has to be done somehow. Leaving the firewall > in ignorance of what's going on with IPsec -- either by separating the two > completely, or by losing information when IPsec throws a packet over the > fence to the firewall -- does not work. Ahh- disconnnect on my part with the term 'firewall' - I meant 'firewall rules', as per ipfw. The entirety of what is considered a firewall includes both ipfw and IPsec, in that case. Joe From owner-ipsec@lists.tislabs.com Tue Nov 20 02:04:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKA4H809923; Tue, 20 Nov 2001 02:04:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11891 Tue, 20 Nov 2001 03:45:33 -0500 (EST) From: "Sami Vaarala" To: "'Ari Huttunen'" , "'Radia Perlman - Boston Center for Networking'" Cc: Subject: RE: IKEv2 (son-of-ike) draft Date: Tue, 20 Nov 2001 10:53:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari, > Ari Huttunen wrote: > > As to the specifics of this protocol, in my view IKEv2 should have > these kinds of requirements: >[...] > > - IKEv2 must be well defined. For example, this draft doesn't state > clearly how the critical bit is to be used (for each payload), > notifies are unclear and should be accompanied by a state machine. > I.e. if a cert payload with critical bit contains a DSS-signature, > is it critical that you know "cert payload", support > DSS-signatures, or what? As an IKE implementor, I agree wholeheartedly. What I would like to see is a section that goes through each message, and explains how it is constructed and processed in the basic case, using pseudocode. Sometimes the easiest way to specify the outcome is to specify the process... This would be the case with IKE packet processing, in my opinion. > - I have a strong dislike for the current VID method. It fails to > provide several key requirements: >[...] Agree to some extent, although you can already hide the new payloads you need into VID payloads. There is nothing (but aesthetics) to prevent one from using, say, 16 first bytes of the VID as a vendor identifier, and the rest as vendor-specific data. > Here's an alternative to VIDs that we could consider: > - A new payload is defined that defines exactly what private > use numbers > an implementation uses and what they are used for. In this > way the private > use numbers are viewed as variables, i.e. > #define PAYLOAD_TYPE_128 > "draft-my-draft-whatever-00.txt:nonce-thingie" > etc., or use an OID instead This sounds like a lot of complexity to me. IKE payloads would not be understandable without the context of the particular IKE session (if I understood correctly) ? Another alternative is to use an explicit vendor extension payload (like Mobile IP) does. The payload would have: (1) a vendor identifier; could be the same number space as in Mobile IP, or a vendor hash (which would lead to some unfortunate bloat). (2) extension type, length, and the usual stuff. Thus each vendor could have their own extension playground (and messages with vendor extensions can be included in initial messages). > - IKEv2 would be easier to test if a method to authenticate > using preshared > secrets was provided. Like, how about hmac-sha-1 signatures? Preshared keys are nice for some things but they do add complexity.. Is there a way we could automatically create RSA keys for this purpose? Suppose you take a preshared key, and use that as an input to an RSA keypair derivation procedure that comes up with an RSA keypair. Both parties use the same procedure to arrive at the same RSA keypair, used as input to the IKEv2 authentication. This scheme can be extended to take the IP addresses into account in the derivation process. The keypair would have to be generated once (expensive), and then cached for further use to avoid overhead. I'm sure there is some good reason why this cannot be done; can someone point out what the reason is? :) -Sami --- Sami Vaarala Senior System Architect NetSeal Technologies From owner-ipsec@lists.tislabs.com Tue Nov 20 05:51:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKDpp828688; Tue, 20 Nov 2001 05:51:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA12354 Tue, 20 Nov 2001 07:52:20 -0500 (EST) Date: Tue, 20 Nov 2001 14:44:50 +0200 To: ipsec@lists.tislabs.com Subject: Re: Just Fast Keying (JFK) draft Message-ID: <20011120124450.GA18085@terrapin.research.nokia.com> Mail-Followup-To: ipsec@lists.tislabs.com References: <200111142152.fAELqAEH000531@coredump.cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200111142152.fAELqAEH000531@coredump.cs.columbia.edu> User-Agent: Mutt/1.3.23.1i From: alexey.vyskubov@nokia.com (Alexey Vyskubov) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, On Wed, Nov 14, 2001 at 11:52:10PM +0200, Angelos D. Keromytis wrote: > Without further ado, here's the link to the just-submitted I-D: > > http://www.cs.columbia.edu/~angelos/Papers/draft-keromytis-jfk-00.txt Is it available still? Access Forbidden The requested URL cannot be accessed with your privileges: /~angelos/Papers/draft-keromytis-jfk-00.txt -- Alexey From owner-ipsec@lists.tislabs.com Tue Nov 20 07:18:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKFII803210; Tue, 20 Nov 2001 07:18:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA12550 Tue, 20 Nov 2001 09:17:13 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: alexey.vyskubov@nokia.com (Alexey Vyskubov) Cc: ipsec@lists.tislabs.com Subject: Re: Just Fast Keying (JFK) draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Nov 2001 09:26:01 -0500 Message-Id: <20011120142601.911087B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <20011120124450.GA18085@terrapin.research.nokia.com>, Alexey Vyskubo v writes: >Hello, > >On Wed, Nov 14, 2001 at 11:52:10PM +0200, Angelos D. Keromytis wrote: >> Without further ado, here's the link to the just-submitted I-D: >> >> http://www.cs.columbia.edu/~angelos/Papers/draft-keromytis-jfk-00.txt > >Is it available still? I'll let Angelos figure out what happened to his copy; however, the official version of the draft is now available from the IETF, but using a different name -- it's an official IPsec WG draft. Anyway, you can retrieve it at http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-00.txt --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Tue Nov 20 08:06:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKG6j808352; Tue, 20 Nov 2001 08:06:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12704 Tue, 20 Nov 2001 10:14:36 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15354.30023.695195.891258@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 07:22:47 -0800 (PST) To: Ari Huttunen Cc: Michael Thomas , Joern Sierwald , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <3BF9EB8B.D96E361@F-Secure.com> References: <200111191328.IAA26753@ietf.org> <15353.12478.158520.373309@thomasm-u1.cisco.com> <5.1.0.14.0.20011119202340.031d9d30@dfintra.f-secure.com> <15353.27940.213620.608331@thomasm-u1.cisco.com> <3BF9EB8B.D96E361@F-Secure.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id KAA12701 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The working group shouldn't be held hostage to the least common denominator of what some bone headed politician might do. If we did that, this wg would never have been able to produce half of the specs since they're munitions. Anybody who puts private information into a public document such as a X.509 cert is foolish and doesn't deserve consideration because it starts from a false premise. We can't design to be false premise proof. Mike Ari Huttunen writes: > This WG cannot dictate what information is put to certificates, and > the politicians being what they are, one should assume the worst. > Note that a nation-wide certificate system has a big network-effect > (economically speaking). If a nation gives each citizen an RSA chip, > this *will* be used by corporations to identify customers. Why? It's > the cheapest method for them. > > That is somewhat irrelevant to identity protection as seen by SOI, but > is a good thing to bear in mind. Such a chip will also be an excellent > method for intelligence communities to track suspects. > > Technically, I think the requirement should be that both of the identities > MUST be protected against passive attackers. The question is if there should > be any requirement as to active attackers. If such a requirement exists, > my view is that the INITIATOR'S identity should be protected against > active attackers. It is the initiator, the ordinary citizen, that is > the target of a Three Letter Organization tracking. > > Ari > > Michael Thomas wrote: > > > > Since certificates are essentially public > > information, anybody who puts private information > > on one deserves what they get. After all, what if > > an unscrupulous site demands that cert and then > > publishes its contents to spammers-r-us.com? > > > > Mike > > > > Joern Sierwald writes: > > > At 13:42 19.11.2001 -0500, you wrote: > > > > >>>>> "Michael" == Michael Thomas writes: > > > > > > > > Michael> ...2) SOI SHOULD provide a means to protect identities. SOI > > > > Michael> MUST make protection optional if it reduces the overall > > > > Michael> number of messages to establish a SA. A SOI peer MUST NOT > > > > Michael> protect identities by default. > > > > > > > > Michael> I expect that the last statement is controversial so let me > > > > Michael> explain: IMO, identity protection is overblown. If by simple > > > > Michael> traffic analysis I see a static IP address for a server > > > > Michael> which I can reverse map, and even a dynamic address which I > > > > Michael> can reverse map to a particular POP, a determined attacker > > > > Michael> is probably going to have a pretty good idea ... > > > > > > > >That may be a valid analysis. (I'm not going to take a position on > > > >that here.) > > > > > > > >However, it does not justify the text you proposed. What it would > > > >justify is: > > > > > > > >2) SOI SHOULD provide a means to protect > > > > identities. SOI MUST make protection optional > > > > if it reduces the overall number of messages > > > > to establish a SA. A SOI peer MAY protect > > > > identities by default. > > > > > > > >That would fit the notion that identity protection is not all that > > > >useful. > > > > > > > >The text you proposed would be appropriate if identity protection is > > > >actually a bad idea. For example, if it can only be done at > > > >significant expense in time (messages, computation) or memory. Is > > > >that the case? You did not say so. > > > > > > > >If identity protection does not come at a significant cost, there is > > > >no technical reason to prohibit it being the default for some > > > >implementations. > > > > > > > > paul > > > > > > VPN are mostly used in two ways: (1) Gateway to Gateway encryption, > > > to link LANs, or (2) Laptop/home user to Gateway, to let remote users > > > into the company LAN. > > > > > > For (2), the laptop may be lost, so a safe authentication method is needed. > > > You can use one-time-password or code-generating tokens, but the > > > natural solution for IKE is an RSA smartcard. > > > > > > Now, these are usually fit with keys and certificates before the > > > VPN vendor or sales guy can state his opinion. As a result, the > > > DN of the cert can contain all kind of stuff. Like email address. > > > Birthday. Home address. social security number. > > > I know of one country (Finland) where you can get your > > > personal ID card with an RSA chip in it (at the local police station), > > > and yes, you can use that for a VPN. > > > > > > Having _that_ DN in cleartext over the net is NOT a good idea. > > > > > > Very much in favour of identity protection, > > > > > > Jörn Sierwald > > > F-Secure Corp > > > > > -- > "They that can give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." - Benjamin Franklin > > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Nov 20 08:33:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKGX1810480; Tue, 20 Nov 2001 08:33:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12793 Tue, 20 Nov 2001 10:44:28 -0500 (EST) Date: Tue, 20 Nov 2001 10:53:00 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15354.30023.695195.891258@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Michael Thomas wrote: > ...Anybody who puts private > information into a public document such as a X.509 > cert is foolish and doesn't deserve consideration > because it starts from a false premise... Speaking of false premises: X.509 certs are not necessarily public documents. They have to be revealed to *some* other parties, e.g. the servers you want to connect to, but that doesn't necessarily mean you are (or should be) willing to reveal them to everyone. Analogy: it is necessary to reveal your credit-card number to merchants you wish to buy from, but you still want it protected against snoopers. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 20 08:48:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKGmp811053; Tue, 20 Nov 2001 08:48:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12847 Tue, 20 Nov 2001 11:02:02 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.32876.87395.582187@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 08:10:20 -0800 (PST) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15354.30023.695195.891258@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk How do I know whether I trust the other party before I divulge my identity? Somebody has to go first. And the world isn't just clients and servers. In the particular example given, if my national identity smart card gave away all sorts of private information to any merchant who asked, why should I have any belief that that information will remain private? Private information should be kept private. Expecting that authenticatable but untrustworthy opponents will keep your private information private is silly. Mike Henry Spencer writes: > On Tue, 20 Nov 2001, Michael Thomas wrote: > > ...Anybody who puts private > > information into a public document such as a X.509 > > cert is foolish and doesn't deserve consideration > > because it starts from a false premise... > > Speaking of false premises: X.509 certs are not necessarily public > documents. They have to be revealed to *some* other parties, e.g. the > servers you want to connect to, but that doesn't necessarily mean you are > (or should be) willing to reveal them to everyone. > > Analogy: it is necessary to reveal your credit-card number to merchants > you wish to buy from, but you still want it protected against snoopers. > > Henry Spencer > henry@spsystems.net > From owner-ipsec@lists.tislabs.com Tue Nov 20 10:10:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKIAg815947; Tue, 20 Nov 2001 10:10:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13039 Tue, 20 Nov 2001 12:05:49 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.36707.559776.303368@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 09:14:11 -0800 (PST) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15353.36126.558016.555579@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Mon, 19 Nov 2001, Michael Thomas wrote: > > ...I think I disagree with your "fullest" assessment > > since simple traffic analysis may shatter many > > false illusions about protected identities. > > I think you've missed my point slightly. If all key negotiation uses > identity protection, then it is impossible to tell whether the results of > such traffic analysis are valid: there is no way to determine whether > non-trivial identity information was exchanged. But if protection is used > only when there is something specific to protect, then the traffic analyst > *knows* whether his results are applicable or not. This presupposes that the traffic analyst needs incontrovertible evidence. If my employer, say, noticed that my laptop had a proclivity to connect to netnudie.museum, I doubt that it would matter a whole lot were I to tell them that they can't _prove_ it was me who clicking on the url. Mike From owner-ipsec@lists.tislabs.com Tue Nov 20 10:25:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKIPh816276; Tue, 20 Nov 2001 10:25:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13188 Tue, 20 Nov 2001 12:41:02 -0500 (EST) To: Michael Thomas Cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: <15354.30023.695195.891258@thomasm-u1.cisco.com> <15354.32876.87395.582187@thomasm-u1.cisco.com> <15354.38399.325950.303332@thomasm-u1.cisco.com> From: Derek Atkins Date: 20 Nov 2001 12:50:19 -0500 In-Reply-To: Michael Thomas's message of "Tue, 20 Nov 2001 09:42:23 -0800 (PST)" Message-ID: Lines: 46 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > I guess that don't draw a huge distinction of where > the privacy leak happened, especially in the example > given where there should be no expectation of privacy > since it's given to untrusted but authenticatable parties. I think there is a HUGE HUGE difference between giving information to the person I think I want to talk to, and letting anyone else hear it. Whether I trust you is a completely different argument and is irrelevant. The point is that I may not know what YOU will do with the data I give you, but at least I know only YOU have it. If it's sent unprotected, then anyone can not only see it, but can perform traffic analysis on who I'm contacting and when. > I'm not arguing about choice. I'm arguing about > average behavior. On average, people don't take > the same precautions gaurding their home as > they do nuclear arsenals. Nor should they; the > risk if compromised is small and the expense > is prohibitive. That is, we should make the > average case reflect the actual risk/expense > instead of erring on the paranoid. What added expense? One round-trip and a DH? Sorry, that doesn't sound very expensive to me. Moreover, it isn't even an extra round-trip; it's only one-half a round trip: DH_a ---------> <----------- DH_b + {ID_b}K_ab {ID_a}K_ab ---> Compare this to a protocol w/o ID protection: ID_a ---------> <----------- ID_b -derek > Mike -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 20 10:31:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKIVc816402; Tue, 20 Nov 2001 10:31:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13169 Tue, 20 Nov 2001 12:38:28 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Henry Spencer" , "Michael Thomas" Cc: References: Subject: Re: SOI: identity protection and DOS Date: Tue, 20 Nov 2001 12:47:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Nov 2001 17:47:13.0410 (UTC) FILETIME=[62EDF620:01C171EB] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IPSec is id-protection first (DH-key exchange) then authentication. As long as can device a mechanism that the DDOS attacker has to spend larger or equal amount of resource than the been attacked, it will be home free. I don't see how the DH-key exchange can achieve this goal. Also, the cookies before DH-key exchange only validate the attacker's address. It does not make attacker consume greater or eaqual amount of resource than been attacked. Regards, --- David ----- Original Message ----- From: "Henry Spencer" To: "Michael Thomas" Cc: Sent: Monday, November 19, 2001 5:28 PM Subject: Re: SOI: identity protection and DOS > On Mon, 19 Nov 2001, Michael Thomas wrote: > > ...IMO, identity protection is > > overblown. If by simple traffic analysis I see a > > static IP address for a server which I can reverse > > map, and even a dynamic address which I can > > reverse map to a particular POP, a determined > > attacker is probably going to have a pretty good > > idea that you're visiting naughtybits.com... > > As others have noted already, an identity can be more than just an IP > address, and protection for parts of it may be desirable. > > I would add that, other things being equal, the fullest possible > protection of everything should be the default, not an option. That way, > users with truly sensitive material aren't prominently advertised as such > by the fact that they're the only ones using protection. > > (Of course, that "other things being equal" covers a multitude of sins. > Whether identity protection justifies an extra round trip is a harder > question than whether it justifies a few more CPU cycles.) > > Henry Spencer > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Tue Nov 20 11:01:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJ1s817018; Tue, 20 Nov 2001 11:01:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13231 Tue, 20 Nov 2001 12:58:05 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.39836.799859.976205@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 10:06:20 -0800 (PST) To: Derek Atkins Cc: Michael Thomas , Henry Spencer , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15354.30023.695195.891258@thomasm-u1.cisco.com> <15354.32876.87395.582187@thomasm-u1.cisco.com> <15354.38399.325950.303332@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins writes: > I think there is a HUGE HUGE difference between giving information to > the person I think I want to talk to, and letting anyone else hear it. > Whether I trust you is a completely different argument and is > irrelevant. The point is that I may not know what YOU will do with > the data I give you, but at least I know only YOU have it. If it's > sent unprotected, then anyone can not only see it, but can perform > traffic analysis on who I'm contacting and when. I'm 99% certain we've entered a rathole here because we got here by way of saying that public key certs might contain private information on them. I still find that a highly dubious proposition, regardless of whether you think that transactional identity hiding is a good idea. > What added expense? One round-trip and a DH? Sorry, that > doesn't sound very expensive to me. Moreover, it isn't even > an extra round-trip; it's only one-half a round trip: It also brings in the expense of doing DH's and the associated baggage of what to do to prevent spoofing attacks. *If* the protocol is required to provide preshared key support, that seems rather overweight. Note again, that I prefaced my original comment in terms of "if" it causes additional overhead it should be optional. This is clearly the case with preshared keys, less so with certs. Mike From owner-ipsec@lists.tislabs.com Tue Nov 20 11:04:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJ4X817191; Tue, 20 Nov 2001 11:04:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13292 Tue, 20 Nov 2001 13:05:19 -0500 (EST) Date: Tue, 20 Nov 2001 13:13:39 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15354.36707.559776.303368@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Michael Thomas wrote: > > ...if protection is used > > only when there is something specific to protect, then the traffic analyst > > *knows* whether his results are applicable or not. > > This presupposes that the traffic analyst needs > incontrovertible evidence. If my employer, say, > noticed that my laptop had a proclivity to > connect to netnudie.museum... Consider a slightly different case: he notices that your laptop has a proclivity to connect to the webservers-r-us.com IPsec gateway. There are a lot of servers behind that gateway... If all negotiations automatically use identity protection, then he can't tell whether you're talking to hot-babes.com or open-source-software.org. However, if your connections to open-source-software.org don't use identity protection, but you also make some other connections which do... then it's a pretty safe bet that those protected connections are going to hot-babes.com or maybe even kiddie-porn.com. Identity protection is much more effective if it's used for everything, so that the mere use of identity protection isn't itself a red flag to a traffic analyst. Yes, there are cases where identity protection doesn't buy much. But there are others where it does. And advertising the difference is dumb. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 20 11:07:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJ77817338; Tue, 20 Nov 2001 11:07:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13315 Tue, 20 Nov 2001 13:10:15 -0500 (EST) Date: Tue, 20 Nov 2001 13:18:50 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15354.32876.87395.582187@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Michael Thomas wrote: > ...In the particular example given, if my > national identity smart card gave away all sorts > of private information to any merchant who asked, > why should I have any belief that that information > will remain private? Do you expect that your credit-card numbers will remain private, even though you give them to any merchant you deal with? Sure you do! You may not bet your life on it, but you do bet your credit rating on it. Remember, also, that a particular certificate isn't necessarily used to authenticate you to *anyone who asks*. It may be used only for quite restricted purposes, e.g. to get you through a corporate firewall. The expectation of privacy is quite legitimately rather higher in that case. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 20 11:17:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJHq817908; Tue, 20 Nov 2001 11:17:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13370 Tue, 20 Nov 2001 13:22:20 -0500 (EST) Date: Tue, 20 Nov 2001 13:30:30 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15354.38399.325950.303332@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Michael Thomas wrote: > ...On average, people don't take > the same precautions gaurding their home as > they do nuclear arsenals. Nor should they; the > risk if compromised is small and the expense > is prohibitive. That is, we should make the > average case reflect the actual risk/expense > instead of erring on the paranoid. I partly agree. Which, of course, means I disagree. There needs to be some consideration of cost-effectiveness. But if we must err, we most definitely should err on the paranoid side. In particular, if the added cost to protect *everything* well is small, then we should not fool around with giving some things protection and leaving others exposed. If we try to be selective, there is always the possibility that we will make mistakes; moreover, we advertise that there's stuff that needs protecting here. As witness the IKEv2 proposal, the suggested dichotomy is false. You can do full identity protection and it can still be cheaper than today's IKE without it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 20 11:18:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJIg817970; Tue, 20 Nov 2001 11:18:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13414 Tue, 20 Nov 2001 13:36:29 -0500 (EST) Message-Id: <200111201845.NAA21833@bcn.East.Sun.COM> Date: Tue, 20 Nov 2001 13:45:49 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: SOI: identity protection and DOS To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PUqXyIC4n+0ct7fH0Z+5dQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek said: >>I happen to agree with Radia's point that you should try to protect >>the initiator's identity before the responder's identity (which >>implies the responder should authenticate to the initiator first). Actually, Dan and Charlie changed my mind about that. The problem with the responder revealing identity information first is that ANYONE can initiate an IPsec connection to an IP address and find out who is there without ever divulging their identity. If it's the initiator that reveals identity first then the only threat is from an active attacker impersonating the responder's IP address and lying in wait. (the initiator's ID is hidden from an eavesdropper and revealed only to whatever is sitting at the IP address the initiator connected to). If it's the responder that reveals identity first, then (assuming it's not a strict client/server model where the nodes that need identity protection never respond to IPsec connect initiates and only initiate them) it is trivial to find out who is at an IP address. Radia From owner-ipsec@lists.tislabs.com Tue Nov 20 11:22:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJMj818199; Tue, 20 Nov 2001 11:22:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13381 Tue, 20 Nov 2001 13:24:44 -0500 (EST) Date: Tue, 20 Nov 2001 13:32:46 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15354.39836.799859.976205@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Michael Thomas wrote: > I'm 99% certain we've entered a rathole here because > we got here by way of saying that public key certs > might contain private information on them. I still > find that a highly dubious proposition... I think you're assuming that public-key certs are automatically public information, which is not necessarily true. People can and do keep "public" keys quite confidential, using them very selectively. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 20 11:23:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKJNZ818246; Tue, 20 Nov 2001 11:23:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13445 Tue, 20 Nov 2001 13:41:36 -0500 (EST) Date: Tue, 20 Nov 2001 20:50:23 +0200 (Israel Standard Time) From: Arne Ansper To: Michael Thomas cc: Derek Atkins , Henry Spencer , Subject: Re: SOI: identity protection and DOS In-Reply-To: <15354.39836.799859.976205@thomasm-u1.cisco.com> Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > we got here by way of saying that public key certs > might contain private information on them. I still > find that a highly dubious proposition, regardless > of whether you think that transactional identity > hiding is a good idea. in the phrase "public key cert" the word public is attached to the word "key", not to the "cert". and the public key itself can be kept secret too. arne From owner-ipsec@lists.tislabs.com Tue Nov 20 12:16:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKKFt821656; Tue, 20 Nov 2001 12:16:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13571 Tue, 20 Nov 2001 14:09:33 -0500 (EST) Message-ID: <3BFAACC0.ACA84B7E@storm.ca> Date: Tue, 20 Nov 2001 14:19:28 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk david chen wrote: > > The IPSec is id-protection first (DH-key exchange) then authentication. > As long as can device a mechanism that the DDOS attacker has > to spend larger or equal amount of resource than the been attacked, > it will be home free. Not really. That'a a reasonable goal, and may be enough to stop an attacker with limited resources, but you're hardly "home free". For one thing, many IPsec gateways are fairly limited devices -- older machines recycled as FreeS/WAN or *BSD gateways, low-cost dedicated devices, routers that may be older or bottom-of-line models, ... -- and methinks we do want those devices to be secure and reliable if possible. Also, an EvilDoer is not constrained to use only his own resources. He can fairly easily find a few dozen badly administered machines around the net, subvert them, and use their resources to attack you. At that point, he both has more resources than you and isn't paying for them, so if you want to stop him via resource constraints, then the attack has to be really expensive. What if he writes a virus and gets thousands of infected machines to attack you? From owner-ipsec@lists.tislabs.com Tue Nov 20 12:27:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKKRG822046; Tue, 20 Nov 2001 12:27:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA13658 Tue, 20 Nov 2001 14:31:08 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.45414.23171.182987@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 11:39:18 -0800 (PST) To: Radia Perlman - Boston Center for Networking Cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <200111201845.NAA21833@bcn.East.Sun.COM> References: <200111201845.NAA21833@bcn.East.Sun.COM> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking writes: > Derek said: > >>I happen to agree with Radia's point that you should try to protect > >>the initiator's identity before the responder's identity (which > >>implies the responder should authenticate to the initiator first). > > Actually, Dan and Charlie changed my mind about that. The problem with > the responder revealing identity information first is that ANYONE can > initiate an IPsec connection to an IP address and find out who is there > without ever divulging their identity. Ah. In other words, it should imitate real life conversations where the responder gets to say "who's there?" rather than the initiator. > If it's the initiator that reveals identity first then the only threat is > from an active attacker impersonating the responder's IP address and lying > in wait. (the initiator's ID is hidden from an eavesdropper and revealed > only to whatever is sitting at the IP address the initiator connected to). > If it's the responder that reveals identity first, then (assuming > it's not a strict client/server model where the nodes that need identity > protection never respond to IPsec connect initiates and only initiate > them) it is trivial to find out who is at an IP address. Which means that you're forced into a full round trip first to protect the initiator's identity. This is precisely why I think that identity protection should be an optional tradeoff of SA establishment speed vs. privacy, especially since the privacy protection in a large number of cases is subject to simple traffic analysis guessing. Mike From owner-ipsec@lists.tislabs.com Tue Nov 20 12:30:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKKUr822179; Tue, 20 Nov 2001 12:30:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13114 Tue, 20 Nov 2001 12:22:47 -0500 (EST) To: Michael Thomas Cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: <15354.30023.695195.891258@thomasm-u1.cisco.com> <15354.32876.87395.582187@thomasm-u1.cisco.com> From: Derek Atkins Date: 20 Nov 2001 12:32:06 -0500 In-Reply-To: Michael Thomas's message of "Tue, 20 Nov 2001 08:10:20 -0800 (PST)" Message-ID: Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mike, Michael Thomas writes: > How do I know whether I trust the other party > before I divulge my identity? Somebody has to go you may or may not trust the other entity, however do you trust all of the snoopers listening along between you and the peer? I happen to agree with Radia's point that you should try to protect the initiator's identity before the responder's identity (which implies the responder should authenticate to the initiator first). Yes, this implies an extra round trip, but if the initiator wants to protect their identity they should have the choice to do so. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 20 13:19:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLJV823148; Tue, 20 Nov 2001 13:19:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13863 Tue, 20 Nov 2001 15:25:13 -0500 (EST) Message-ID: <6549284BE680D511815C0002A50A67770D134D@hdsmsx102.hd.intel.com> From: "Eissa, Mohamed" To: ipsec@lists.tislabs.com Subject: RFC 2408 and pkcs-7 Date: Tue, 20 Nov 2001 12:36:05 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, In ISAKMP RFC2408 section 3.9, it mentioned using pkcs#7 in CERT payload as type . My understanding that PKCS#7 is an envelope. This envelope must be either of type "SIGNED DATA" or "SIGNED AND ENVELOPED DATA". I think the RFC didn't specify which type of PKCS#7 and what keys to be used, please correct me if I am wrong. Mohamed From owner-ipsec@lists.tislabs.com Tue Nov 20 13:22:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLMe823324; Tue, 20 Nov 2001 13:22:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13844 Tue, 20 Nov 2001 15:17:29 -0500 (EST) Date: Tue, 20 Nov 2001 12:26:16 -0800 (PST) From: Jan Vilhuber To: Ari Huttunen cc: Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft In-Reply-To: <3BF9F823.C07A090C@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Ari Huttunen wrote: > I read through some of this draft, and mainly I'd say it looks very > good. At least when compared to the current RFCs. Comments follow. > > - If, as I understand, there is to be a 'selection' as to what will > be the next IKE, what chance has anybody against a protocol that is > named draft-ietf-ipsec-ikev2-00.txt? > > As to the specifics of this protocol, in my view IKEv2 should have > these kinds of requirements: > > - IKEv2 must enable all traffic to be protected as well as possible. > If there is no common authentication method, a method to do just > encryption should be provided. > > - IKEv2 must be well defined. For example, this draft doesn't state > clearly how the critical bit is to be used (for each payload), notifies > are unclear and should be accompanied by a state machine. > I.e. if a cert payload with critical bit contains a DSS-signature, > is it critical that you know "cert payload", support DSS-signatures, or what? > > - I have a strong dislike for the current VID method. It fails to > provide several key requirements: I've also long hated the VID method. I prefer the Radius Vendor-Specific Attribute method. Why not just have that concept? That reolves at least the collision issue below, and probably all others. Make the payload contain ike attribute after a header that CLEARLY defines the vendor. > a) Some problems are best solved by having a new payload in the > first message. Like in ESPUDP IKE negotiation we could have used > such a payload, but it's not possible with VIDs. (The bad thing about > this is that it's not easy to change the protocol structure when > official numbers are assigned.) > b) A VID does not define how the protocol is to be extended, it > just says that after you see this, you can twist IKE as much > as you want. > c) A VID does nothing to prevent conflicts between two drafts that > just happen to allocate the same private use number. > > Here's an alternative to VIDs that we could consider: > - A new payload is defined that defines exactly what private use numbers > an implementation uses and what they are used for. In this way the private > use numbers are viewed as variables, i.e. > #define PAYLOAD_TYPE_128 "draft-my-draft-whatever-00.txt:nonce-thingie" > etc., or use an OID instead > - The initiator sends that in the first message, and following that payload > a payload of type 128 may occur in the same message. The responder sends > them in the first reply. > - Responder will map only private use attributes that don't conflict with > the initiator's choices. So a draft will never say "payload number 128", > it will say "private payload that maps to xxxx". > > > - IKEv2 would be easier to test if a method to authenticate using preshared > secrets was provided. Like, how about hmac-sha-1 signatures? > I believe 'testing' was the justification for pre-shared keys in the last round and now we can't get rid of it and even have group-keys. Gah! What's so hard about configuring an RSA key? jan > Ari > > > Radia Perlman - Boston Center for Networking wrote: > > > > And to answer some of the recent email on the list...this > > protocol does maintain the phase 1/phase 2 notion, but sets up > > both phase 1 and phase 2 in a single 2-round-trip exchange. > > After the initial exchange, additional SAs can be set up, > > or the SA can be rekeyed, with a single round trip. And it > > does identity hiding of both ends. > > > > Most of the work was in rewriting the three documents into > > a single self-contained document, and cleaning up the "networking" > > type issues and overly complex encodings such as > > the SA payload. > > > > Radia > > ------------- Begin Forwarded Message ------------- > > > > To: ipsec@lists.tislabs.com > > From: dharkins@tibernian.com > > Subject: IKEv2 (son-of-ike) draft > > MIME-Version: 1.0 > > Content-ID: <2377.1006067452.1@SailPix.com> > > > > This draft was submitted but hasn't shown up yet in the repository > > (the I-D editor is, no doubt, swamped) so in the interest of giving > > people more time to look at it prior to Salt Lake here's a link: > > > > http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt > > > > Please send comments to the list. > > > > Dan. > > > > ------------- End Forwarded Message ------------- > > -- > "They that can give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." - Benjamin Franklin > > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F(ully)-Secure products: Securing the Mobile Enterprise > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 20 13:50:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKLoO824726; Tue, 20 Nov 2001 13:50:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13480 Tue, 20 Nov 2001 13:49:48 -0500 (EST) Date: Tue, 20 Nov 2001 13:58:29 -0500 (EST) From: Henry Spencer To: Ari Huttunen cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft In-Reply-To: <3BF9F823.C07A090C@F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Ari Huttunen wrote: > - If, as I understand, there is to be a 'selection' as to what will > be the next IKE, what chance has anybody against a protocol that is > named draft-ietf-ipsec-ikev2-00.txt? It's like the old languages question, "what comes after C -- D or P?". (C was the language after B, but was that in the alphabet or in "BCPL"?) In this case, what's the successor to IKE -- IKEv2 or JFK? Just because the current protocol is named IKE doesn't mean the next will be IKEv2. The successor to IPv4 is not IPv5... > - IKEv2 must be well defined. Strongly concur. The worse thing about IKE is how vaguely it's defined. At first glance, IKEv2 does seem an improvement, but any remaining fuzzy spots need to be cleared up now. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Nov 20 14:03:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKM30825401; Tue, 20 Nov 2001 14:03:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13148 Tue, 20 Nov 2001 12:34:05 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.38399.325950.303332@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 09:42:23 -0800 (PST) To: Derek Atkins Cc: Michael Thomas , Henry Spencer , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15354.30023.695195.891258@thomasm-u1.cisco.com> <15354.32876.87395.582187@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins writes: > Michael Thomas writes: > > > How do I know whether I trust the other party > > before I divulge my identity? Somebody has to go > > you may or may not trust the other entity, however do you trust > all of the snoopers listening along between you and the peer? I guess that don't draw a huge distinction of where the privacy leak happened, especially in the example given where there should be no expectation of privacy since it's given to untrusted but authenticatable parties. > I happen to agree with Radia's point that you should try to protect > the initiator's identity before the responder's identity (which > implies the responder should authenticate to the initiator first). > Yes, this implies an extra round trip, but if the initiator wants to > protect their identity they should have the choice to do so. I'm not arguing about choice. I'm arguing about average behavior. On average, people don't take the same precautions gaurding their home as they do nuclear arsenals. Nor should they; the risk if compromised is small and the expense is prohibitive. That is, we should make the average case reflect the actual risk/expense instead of erring on the paranoid. Mike From owner-ipsec@lists.tislabs.com Tue Nov 20 14:50:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKMoa827674; Tue, 20 Nov 2001 14:50:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA13471 Tue, 20 Nov 2001 13:47:22 -0500 (EST) To: Michael Thomas Cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: <15354.30023.695195.891258@thomasm-u1.cisco.com> <15354.32876.87395.582187@thomasm-u1.cisco.com> <15354.38399.325950.303332@thomasm-u1.cisco.com> <15354.39836.799859.976205@thomasm-u1.cisco.com> From: Derek Atkins Date: 20 Nov 2001 13:56:42 -0500 In-Reply-To: Michael Thomas's message of "Tue, 20 Nov 2001 10:06:20 -0800 (PST)" Message-ID: Lines: 35 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > I'm 99% certain we've entered a rathole here because > we got here by way of saying that public key certs > might contain private information on them. I still > find that a highly dubious proposition, regardless > of whether you think that transactional identity > hiding is a good idea. It doesn't matter, to me, whether the certs contains public information or not -- they provide linkability which does not otherwise (necessarily) exist. If my IP address is constantly changing (yea, Cablemodems) then someone viewing my transactions has no linkability between address changes. Providing access to the PK cert gives them linkability, even if all the information is public. > > What added expense? One round-trip and a DH? Sorry, that > > doesn't sound very expensive to me. Moreover, it isn't even > > an extra round-trip; it's only one-half a round trip: > > It also brings in the expense of doing DH's Um, please re-read what I said: "One round-trip and a DH". Are you saying that there are multiple DHs? I already accounted for one and maintain that one DH is not too expensive. > Mike -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 20 15:00:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAKN0t828319; Tue, 20 Nov 2001 15:00:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA14012 Tue, 20 Nov 2001 16:50:17 -0500 (EST) Date: Tue, 20 Nov 2001 23:59:43 +0200 (IST) From: Hugo Krawczyk To: ipsec list Subject: IKE-SIGMA: draft-krawczyk-ipsec-ike-sigma-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have written an internet-draft proposing simplified secure protocols for use in IKE, and intended to submit it for IPsec WG consideration. Unfortunately, I misread the cut-off date and believed it to be 11/21 (which is the deadline for drafts with versions greater than 00). In spite of this I ask that this draft will be considered by the WG. It is not a full specification but a detailed protocol proposal that can be merged into the son-of-ike framework. It certainly has significant advantages over existing IKE modes both at the simplicity level and efficiency (in its basic form it can allow to create a working IPsec SA in just 3 messages, instead of the 9 messages it takes today, and with the same security properties). The proposal is named "The IKE-SIGMA Protocol" and its abstract is appended below. The draft is available at: http://tiger.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt Hugo ======================================================================= Abstract: We present a concrete proposal for a simplified version of the signature modes of IKE, and suggest a related mechanism for use with pre-shared keys. The proposed design, named SIGMA, achieves several seemingly conflicting goals: simplification of the protocol, enhanced functionality, and performance improvement. In particular, it provides efficient and adaptive defense against DoS attacks, privacy enhancement with both identities protected from eavesdroppers in the network, elimination of the distinction (and duplicity) between aggressive mode and main mode, and a reduced number of messages per exchange. The SIGMA protocol re-uses the specification basis existing in ISAKMP and IKE, and allows for significant re-use of existing code that already implements these protocols. The proposed protocols enjoy a proof of security via formal cryptographic analysis. From owner-ipsec@lists.tislabs.com Tue Nov 20 16:12:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAL0Ct801641; Tue, 20 Nov 2001 16:12:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA14121 Tue, 20 Nov 2001 18:03:00 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15354.58135.188899.806770@thomasm-u1.cisco.com> Date: Tue, 20 Nov 2001 15:11:19 -0800 (PST) To: Henry Spencer Cc: IP Security List Subject: Re: SOI: preshared In-Reply-To: References: <15353.24948.198728.631259@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > > You could > > conceivably get rid of the DH if you don't care > > about identity, but for preshared keys it seems > > questionable why you'd want to do _either_. > > Today's preshared keys are for authentication, not encryption, so the DH > step is not optional -- they often are things like English phrases, which > may be okay for authentication but definitely does not provide encryption > strong enough to adequately protect session-key exchanges. Well, it need not be -- especially if you buy into Cheryl's premise that IKE is a machine-machine protocol more than a user-user protocol. It's not hard to choose and remember a symmetric key which isn't subject to dictionary attacks if you're a machine, after all. But this really does beg the question of what the requirement actually is here. Do we need to have a well-supported/efficient peer to peer preshared key scheme for IKE or not. If we do, it informs this debate. If we do not, we can skip this debate altogether. Mike From owner-ipsec@lists.tislabs.com Tue Nov 20 21:11:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAL5Bi808910; Tue, 20 Nov 2001 21:11:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA14755 Tue, 20 Nov 2001 23:19:24 -0500 (EST) Date: Tue, 20 Nov 2001 23:27:57 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15354.45414.23171.182987@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 20 Nov 2001, Michael Thomas wrote: > Which means that you're forced into a full round > trip first to protect the initiator's identity... There has to be a round trip there, yes... but it doesn't necessarily have to be an *extra* round trip, since you can get other things done at the same time. > ...precisely why I think that identity > protection should be an optional tradeoff... You have not actually established your key underlying assumption, that identity protection necessarily involves substantial extra cost. The proposed IKEv2, if I've read the spec correctly, establishes both an ISAKMP SA and a set of IPsec SAs, *with* full identity protection, in 2 round trips. It is difficult to imagine improving on that. (IKE needs 2.5 round trips *without* identity protection.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 21 01:27:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAL9Rd803985; Wed, 21 Nov 2001 01:27:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA15067 Wed, 21 Nov 2001 03:32:32 -0500 (EST) Message-ID: <3BFB68CD.5F9354FC@F-Secure.com> Date: Wed, 21 Nov 2001 10:41:49 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft References: <20011120190816.13DD254C46@tailor.sailpix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2001 08:41:51.0077 (UTC) FILETIME=[5D4FF150:01C17268] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, You did answer my question, but let's follow.. Is it then implicitly understood that all payloads defined in the current draft are understood by all implementations, and therefore have implicitly the critical bit set, even though it's not? If they are all implicitly critical, why not make them explicitly critical. I would feel better if the draft stated clearly when the bit is to be set and when not. Would it be allowed to send a non-Critical private payload type preceded by a VID in the first message? If not, why not? This would solve my biggest gripe with VIDs. Ari dharkins@tibernian.com wrote: > > Ari, > > The draft clearly states that "If the critical flag is set and the > payload type is unsupported, the message MUST be rejected....If the > critical flag is not set and the payload type is unsupported, that > payload is simply skipped." In addition it states it "MUST be ignored > by the receipient if the recipient understands the payload type code." > Also, it "MUST be set to zero for payload types defined in this > document." > > Since you presumably understand the "cert payload" you MUST ignore > that field when it is in the header of a "cert payload". The sender > should not have set it but by ignoring the field there is not problem > with interoperability. > > It is "for further flexibility for forward compatibility." So if the > "foo payload" is defined somewhere by someone for some reason you can > set the critical bit for the "foo payload" to ensure that if someone > does not understand the "foo payload" they will reject the entire > message which contains the "foo payload". Or you can clear the critical > bit for the "foo payload" to ensure that the recipient will skip this > payload and finish processing the message. Whether you set it or not > with the "foo payload" depends on you and what the purpose of sending > the "foo payload" is. > > I think the draft is quite clear in this regard. > > Dan. > > On Tue, 20 Nov 2001 08:28:51 +0200 you wrote > > > > - IKEv2 must be well defined. For example, this draft doesn't state > > clearly how the critical bit is to be used (for each payload), notifies > > are unclear and should be accompanied by a state machine. > > I.e. if a cert payload with critical bit contains a DSS-signature, > > is it critical that you know "cert payload", support DSS-signatures, or wha > >t? > > -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Nov 21 02:47:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALAl6813530; Wed, 21 Nov 2001 02:47:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA15220 Wed, 21 Nov 2001 04:55:07 -0500 (EST) Message-ID: <3BFB7654.7D6BD3DA@F-Secure.com> Date: Wed, 21 Nov 2001 11:39:32 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Radia Perlman - Boston Center for Networking CC: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: <200111201845.NAA21833@bcn.East.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Nov 2001 09:39:33.0766 (UTC) FILETIME=[6D3C5A60:01C17270] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Radia Perlman - Boston Center for Networking wrote: > > Derek said: > >>I happen to agree with Radia's point that you should try to protect > >>the initiator's identity before the responder's identity (which > >>implies the responder should authenticate to the initiator first). > > Actually, Dan and Charlie changed my mind about that. The problem with > the responder revealing identity information first is that ANYONE can > initiate an IPsec connection to an IP address and find out who is there > without ever divulging their identity. > > If it's the initiator that reveals identity first then the only threat is > from an active attacker impersonating the responder's IP address and lying > in wait. (the initiator's ID is hidden from an eavesdropper and revealed > only to whatever is sitting at the IP address the initiator connected to). > If it's the responder that reveals identity first, then (assuming > it's not a strict client/server model where the nodes that need identity > protection never respond to IPsec connect initiates and only initiate > them) it is trivial to find out who is at an IP address. > > Radia I suggest that the responder create an identity-encrypting-key once, and always sends it in message 2. Then on the first connection initiator's identity is vulnerable to active attackers, but on subsequent connections it is not, provided the initiator remembers that key and barfs if it has changed. Then on message 3 the initiator encrypts its identity with that key. Compare this with the SSH protocol where the initiator remembers the responder's key. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Nov 21 03:35:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALBZU818852; Wed, 21 Nov 2001 03:35:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA15381 Wed, 21 Nov 2001 05:46:45 -0500 (EST) Message-ID: <3BFB8827.B120F14B@sit.fraunhofer.de> Date: Wed, 21 Nov 2001 11:55:35 +0100 From: Brian Hunter X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugo Krawczyk CC: ipsec list Subject: Re: IKE-SIGMA: draft-krawczyk-ipsec-ike-sigma-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am only commenting on the content of the proposal and not on whether or not this proposal should be accepted into the WG. I am not sure if these comments should be left until after the draft is accepted or not. After reading the draft, I would like to propose a modification to the suggested scheme for creating RCs in 2.3. It is noted that this is not a mandatory scheme since RCs are only used by the responder, but by suggesting it in the draft, it is likely that it will be used by at least some implementations. The purpose of the RC is to prevent DoS and is only used when the Responder believes it is under attack. The fourth note in section 2.3 states that the RC also protects against attackers who intercept the second message of the exchange. -Note 4 "The inclusion of Ni under the computation of RC achieves, at no extra cost, a strengthening of the DoS protection mechanism provided by RC: an attacker that intercepts the second message from R to I (which includes the RC cookie and the Initiator's IP address), but did not generate or intercept the first message from I to R, cannot use the intercepted cookie RC for sending a seemingly-valid message 3 since this attacker lacks the unique value Ni that needs to be included in this third message." However, this provides no protection against an attacker who can listen to messages 1 and 2 of the exchange and then send a seemingly-valid message 3. The sixth note tries to prevent a replay-attack but I believe the use of this window and tracking mechanism opens up a new potential DoS attack. -Note 6 "The parameter T included in the cookie computation is intended to prevent the attacker from replaying old values of message 3. However, for the period of time that a certain value of T is acceptable at R an attacker could replay the message 3 with this value of T. The simplest solution to this is to implement T as a counter and keep track of the values in the current window that have been already received. In this way, no replay at all is possible." Now if the attacker can read message 2 (and message 1) and send a seemingly-valid message 3 before the Initiator can, he has denied the Initiator from using this negotiation since the Responder will silently reject all further message 3s. The problem lies in the fact that the attacker is capable of changing the proposed SA and KE in the third message without the Responder being able to tell the difference. Thus, the Responder believes message 3 is from the Initiator and will send message 4 to the Initiator but the SA and KE may not be acceptable to the Initiator and it must re-start the whole negotiation. Thus, if an attacker can make a Responder believe it is under attack and starts to use RCs, then the attacker can actually cause DoS because of the RCs and extra messages. This can be avoided by adding SA and KE (and OIDii if present) from message 1 to the hashed values to obtain v. Thus v would now look like this: v = prf(K, T | IPi | Ni | SA | KE [| OIDii]) Now when the Responder verifies v sent back from the Initiator in message 3, it can verify that SA and KE in message 3 are the same as those in message 1. In this manner, a quicker attacker can only insert a valid message 3, which would actually decrease the round trip time and speed up the negotiation. Note that this modification does not increase the size of v since it can still be truncated as per the fifth note in 2.3. Nor does it create any state on the Responder. The drawback to this method is that depending on the length of SA and KE, an extra hash round(s) may be required to perform the prf. Is this a viable solution to this attack? Brian From owner-ipsec@lists.tislabs.com Wed Nov 21 04:01:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALC1L820311; Wed, 21 Nov 2001 04:01:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA15410 Wed, 21 Nov 2001 06:14:18 -0500 (EST) Message-Id: <200111211123.OAA26771@relay1.trustworks.com> From: "Valery Smyslov" Organization: TWS To: ipsec@lists.tislabs.com Date: Wed, 21 Nov 2001 14:23:33 +0300 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: IKEv2 (son-of-ike) draft CC: dharkins@tibernian.com In-reply-to: <20011118071052.0F71654C53@tailor.sailpix.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 17 Nov 01, at 23:10, dharkins@tibernian.com wrote: > This draft was submitted but hasn't shown up yet in the repository > (the I-D editor is, no doubt, swamped) so in the interest of giving > people more time to look at it prior to Salt Lake here's a link: > > http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt > > Please send comments to the list. > > Dan. I've read through the draft and have some comments and questions. 1. It seems that peers have no ability to learn what type of signature (RSA, DSS or smth else) the other party uses apart from investigating the type of public key contained in certificate. Because of certificate exchange is optional, it makes the protocol unworkable in some situations. Consider the example, when party A supports only RSA signatures, and party B supports both RSA and DSS signatures with DSS as preferable. While party B will be able to verify signature, generated by party A, the other party won't be able to do it, if party B will use its favourite (DSS). Moreover, party A has no ability to inform party B that she doesn't support DSS. Even the exchange of certificates doesn't help much - party B may have both RSA and DSS certificates from the same CA and she still will select her favourite - DSS, because she has no ability to learn that her peer doesn't support DSS at all. I can think of two ways to improve the situation. a) use notification INVALID-SIGNATURE to inform the other party that this type of signature algorithm is not supported. The problem with this solution is that with the lack of explicit knowledge of peer's public key type (if no cert exchange took place) the peer could not be able to always distinguish unsupported signature algorithm and just bad signature. b) add attribute "Signature algorithm" to transform "Authentication method", making the algorithm negotiateable. This will, however, eliminates the ability for each of the peers to use different algorithm. As for me, I like option b). 2. The draft says that responder may return a subset of TS proposed by initiator. While I like the idea in general, there is a problem: responder doesn't know what packet triggered IKE at initiator, so it can falsely narrow down TS so, that original packet at initiator won't fit into resulting SA, forcing initiator to perform one more Phase 2 (possibly with the same result). For responder to be more smart in this narrowing, some information about the packet, triggered the negotiation must be provided by initiator. Again, I can see 2 ways how this information may be provided. a) define a new payload type - say "Original packet" payload, very similar in format to Traffic Selector Substructure or to current ID payload (not to IKEv2 ID payload). Such payload must be sent by initiator along with TS payloads. They must be filled with information from the very packet, that triggered this negotiation. For responder this payloads will be an indication of IP addresses, protocol and ports that must be always be met while she will be narrowing initiator's TS. b) it is possible to avoid defining new payload type if initiator will always fill the very first TS Substructure with the information from the packet, triggered negotiation. She may provide additional TS Substructures as a proposal for SA selector, and responder will be knowing that she may narrow this proposal to any extent except that the requirements of the the very first TS Substructure must always be met after the narrowing. I have no strong opinion what solution is better. Few minor comments and questions. 3. It seems that TS payloads are required in IKEv2, eliminating the simplest case in IKEv1, when it was allowed to omit ID in Quick Mode. Is it right? 4. Reference to RFC 2522 (on page 10) is absent in References section. 5. Section 2.2, second paragraph. "... with is zero" - did you mean "... which is zero"? 6. Section 7.3.2, table Transform Type Values, "Integrity Algorithm" line. Is it a typo that IKE is mentioned in this line or is it for purpose? I cannot figure out how it is applicable to IKE and if it is, how does it interact with PseudoRandom Function values. 7. Page 30,31 - there seems to be too many bullets in description of Proposal Substructure and too few in description Transform :-) Regards, Valery Smyslov. From owner-ipsec@lists.tislabs.com Wed Nov 21 05:32:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALDWY826403; Wed, 21 Nov 2001 05:32:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15583 Wed, 21 Nov 2001 07:33:44 -0500 (EST) Message-Id: <5.1.0.14.2.20011121133755.00ae9a10@mail.gmx.net> X-Sender: 1017950@mail.gmx.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 21 Nov 2001 13:43:24 +0100 To: ipsec@lists.tislabs.com From: Andreas Predl Subject: Suse Linux 7.3 and VPN Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I try to setup a VPN connection in my LAN >Win2k (10.20.5.1) --- Linux server (eth0 10.20.250.3, > eth1 10.20.250.250, > eth2 10.20.250.251) > When i try to connect from Win2k to the Linux server the following message appears: "No answer", and i can't see anything in the Linux log files I tried to config the ipsec.conf, but i think i have failed. I need help to config my ipsec.conf file, because i think there is the mistake. 2. What means this message? ipsec0: no IPv6 routers present >Log: > >Nov 21 10:08:57 linux Pluto[4676]: shutting down >Nov 21 10:08:57 linux Pluto[4676]: forgetting secrets >Nov 21 10:08:57 linux Pluto[4676]: shutting down interface ipsec0/eth2 >fe80::24f:4eff:fe10:5aa6 >Nov 21 10:08:57 linux Pluto[4676]: shutting down interface ipsec0/eth2 >10.20.250.251 >Nov 21 10:08:59 linux ipsec_setup: ...FreeS/WAN IPsec stopped >Nov 21 10:08:59 linux ipsec_setup: Stopping FreeS/WAN >IPsec...^M^[[80C^[[10D^[[1;32mdone^[[m^O >Nov 21 10:09:02 linux ipsec_setup: KLIPS debug `none' >Nov 21 10:09:02 linux ipsec_setup: KLIPS ipsec0 on eth2 >10.20.250.251/255.255.0.0 broadcast 10.20.255.255 >Nov 21 10:09:02 linux Pluto[4921]: Starting Pluto (FreeS/WAN Version >1.91) >Nov 21 10:09:02 linux Pluto[4921]: including X.509 patch (Version >0.9.2) >Nov 21 10:09:02 linux Pluto[4921]: Changing to directory >'/etc/ipsec.d/cacerts' >Nov 21 10:09:02 linux Pluto[4921]: Warning: empty directory >Nov 21 10:09:02 linux Pluto[4921]: Changing to directory >'/etc/ipsec.d/crls' >Nov 21 10:09:02 linux Pluto[4921]: Warning: empty directory >Nov 21 10:09:02 linux Pluto[4921]: X.509 certificate file >'/etc/x509cert.der' not found >Nov 21 10:09:02 linux Pluto[4921]: OpenPGP certificate file >'/etc/pgpcert.pgp' not found >Nov 21 10:09:02 linux ipsec_setup: ...FreeS/WAN IPsec started >Nov 21 10:09:02 linux ipsec_setup: Starting FreeS/WAN IPsec >1.91...^M^[[80C^[[10D^[[1;32mdone^[[m^O >Nov 21 10:09:03 linux Pluto[4921]: added connection description >"sample1" >Nov 21 10:09:03 linux Pluto[4921]: listening for IKE messages >Nov 21 10:09:03 linux Pluto[4921]: adding interface ipsec0/eth2 >10.20.250.251 >Nov 21 10:09:03 linux Pluto[4921]: adding interface ipsec0/eth2 >fe80::24f:4eff:fe10:5aa6 >Nov 21 10:09:03 linux Pluto[4921]: loading secrets from >"/etc/ipsec.secrets" AP From owner-ipsec@lists.tislabs.com Wed Nov 21 07:41:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALFfJ802425; Wed, 21 Nov 2001 07:41:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15814 Wed, 21 Nov 2001 09:40:31 -0500 (EST) Message-ID: <004501c1729b$7e9250a0$0c00a8c0@internet> Reply-To: "Mahdavi" From: "Mahdavi" To: "ipsec" Subject: Statistical info. Date: Wed, 21 Nov 2001 18:17:37 +0330 Organization: PayamPardaz MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C172B8.CCAB1E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C172B8.CCAB1E80 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi.=20 Where can I find statistical info of internet which explain streaming = properties on the net. It is useful to estimate some features of IPSEC = system.=20 thanks before.=20 mahdavi ------=_NextPart_000_0040_01C172B8.CCAB1E80 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi.
Where can I find statistical info of = internet which=20 explain streaming properties on the net. It is useful to estimate some = features=20 of IPSEC system.
 
thanks before.
 
mahdavi
 
------=_NextPart_000_0040_01C172B8.CCAB1E80-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Wed Nov 21 07:48:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALFmf802928; Wed, 21 Nov 2001 07:48:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15881 Wed, 21 Nov 2001 09:59:32 -0500 (EST) To: Jan Vilhuber Cc: Ari Huttunen , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft References: From: Derek Atkins Date: 21 Nov 2001 10:08:52 -0500 In-Reply-To: Jan Vilhuber's message of "Tue, 20 Nov 2001 12:26:16 -0800 (PST)" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jan Vilhuber writes: > round and now we can't get rid of it and even have group-keys. Gah! What's so > hard about configuring an RSA key? Lack of a standard way of doing it... Do you use raw RSA N/e, PGP key format, X.509 format? If a certificate format (PGP/X.509/etc) what signatures are required, if any? IKE doesn't specify any of this, and quite frankly a number of implementations do it differently. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 21 09:09:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALH94809253; Wed, 21 Nov 2001 09:09:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16015 Wed, 21 Nov 2001 11:04:02 -0500 (EST) Date: Wed, 21 Nov 2001 11:12:22 -0500 (EST) From: Henry Spencer To: Derek Atkins cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 21 Nov 2001, Derek Atkins wrote: > > ...and now we can't get rid of it and even have group-keys. Gah! What's so > > hard about configuring an RSA key? > > Lack of a standard way of doing it... Do you use raw RSA N/e, PGP key > format, X.509 format? If a certificate format (PGP/X.509/etc) what > signatures are required, if any? IKE doesn't specify any of this, and > quite frankly a number of implementations do it differently. So *pick one*. Just because there are ten different ways of doing it doesn't mean you have to support all ten, or stand there frozen because you're unable to make up your mind. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 21 09:31:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALHVJ810048; Wed, 21 Nov 2001 09:31:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16093 Wed, 21 Nov 2001 11:34:55 -0500 (EST) To: Henry Spencer Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft References: From: Derek Atkins Date: 21 Nov 2001 11:43:43 -0500 In-Reply-To: Henry Spencer's message of "Wed, 21 Nov 2001 11:12:22 -0500 (EST)" Message-ID: Lines: 35 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > > Lack of a standard way of doing it... Do you use raw RSA N/e, PGP key > > format, X.509 format? If a certificate format (PGP/X.509/etc) what > > signatures are required, if any? IKE doesn't specify any of this, and > > quite frankly a number of implementations do it differently. > > So *pick one*. Just because there are ten different ways of doing it > doesn't mean you have to support all ten, or stand there frozen because > you're unable to make up your mind. Right, and implementation A picks method X, and implementation B picks method Y, and implementation C picks method Z, which makes sharing keys a huge hastle. For example, in order to get FreeS/WAN to interoperate with, say, NetBSD, I think I'm going to have to use OpenSSL to general an X.509 self-signed certificate and then extract the key into FreeS/WAN so that NetBSD (and some other implementations) can have access to an X.509 cert. This is just a pain in the butt, and should not be left to implementors. Then again, the Security Area can't seem to agree on a format, either. :( > Henry Spencer > henry@spsystems.net -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 21 09:32:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALHWE810078; Wed, 21 Nov 2001 09:32:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16127 Wed, 21 Nov 2001 11:42:39 -0500 (EST) Message-Id: <200111201925.fAKJPhIQ010916@nyarlathotep.keromytis.org> X-Mailer: exmh version 2.0.2 2/24/98 To: alexey.vyskubov@nokia.com (Alexey Vyskubov) Cc: ipsec@lists.tislabs.com Subject: Re: Just Fast Keying (JFK) draft In-reply-to: Your message of "Tue, 20 Nov 2001 14:44:50 +0200." <20011120124450.GA18085@terrapin.research.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Nov 2001 14:25:43 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There was a glitch in the web server --- should be ok now. In message <20011120124450.GA18085@terrapin.research.nokia.com>, Alexey Vyskubo v writes: >Hello, > >On Wed, Nov 14, 2001 at 11:52:10PM +0200, Angelos D. Keromytis wrote: >> Without further ado, here's the link to the just-submitted I-D: >> >> http://www.cs.columbia.edu/~angelos/Papers/draft-keromytis-jfk-00.txt > >Is it available still? > > > Access Forbidden > > The requested URL cannot be accessed with your privileges: > /~angelos/Papers/draft-keromytis-jfk-00.txt > > >-- >Alexey From owner-ipsec@lists.tislabs.com Wed Nov 21 09:32:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALHWN810094; Wed, 21 Nov 2001 09:32:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16125 Wed, 21 Nov 2001 11:42:37 -0500 (EST) To: Ari Huttunen Cc: ipsec@lists.tislabs.com From: dharkins@tibernian.com Subject: Re: IKEv2 (son-of-ike) draft In-Reply-To: Your message of "Tue, 20 Nov 2001 08:28:51 +0200." <3BF9F823.C07A090C@F-Secure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20722.1006283295.1@SailPix.com> Date: Tue, 20 Nov 2001 11:08:16 -0800 Message-Id: <20011120190816.13DD254C46@tailor.sailpix.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari, The draft clearly states that "If the critical flag is set and the payload type is unsupported, the message MUST be rejected....If the critical flag is not set and the payload type is unsupported, that payload is simply skipped." In addition it states it "MUST be ignored by the receipient if the recipient understands the payload type code." Also, it "MUST be set to zero for payload types defined in this document." Since you presumably understand the "cert payload" you MUST ignore that field when it is in the header of a "cert payload". The sender should not have set it but by ignoring the field there is not problem with interoperability. It is "for further flexibility for forward compatibility." So if the "foo payload" is defined somewhere by someone for some reason you can set the critical bit for the "foo payload" to ensure that if someone does not understand the "foo payload" they will reject the entire message which contains the "foo payload". Or you can clear the critical bit for the "foo payload" to ensure that the recipient will skip this payload and finish processing the message. Whether you set it or not with the "foo payload" depends on you and what the purpose of sending the "foo payload" is. I think the draft is quite clear in this regard. Dan. On Tue, 20 Nov 2001 08:28:51 +0200 you wrote > > - IKEv2 must be well defined. For example, this draft doesn't state > clearly how the critical bit is to be used (for each payload), notifies > are unclear and should be accompanied by a state machine. > I.e. if a cert payload with critical bit contains a DSS-signature, > is it critical that you know "cert payload", support DSS-signatures, or wha >t? > From owner-ipsec@lists.tislabs.com Wed Nov 21 09:33:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALHXZ810118; Wed, 21 Nov 2001 09:33:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16126 Wed, 21 Nov 2001 11:42:37 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "DavidChenNH" To: "Michael Thomas" , "Paul Hoffman / VPNC" Cc: "IP Security List" References: <15353.11388.281025.686412@thomasm-u1.cisco.com><15353.24948.198728.631259@thomasm-u1.cisco.com> <15353.36923.343768.950818@thomasm-u1.cisco.com> Subject: Re: SOI: preshared Date: Tue, 20 Nov 2001 12:20:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 20 Nov 2001 17:20:14.0638 (UTC) FILETIME=[9E10F4E0:01C171E7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pardon me, but, I have to say " set of trusted public keys" that is stored for the self-certified public key is "chasing its own shadow". How do you get the "set of trusted public key" initially? It will make sense in the PKI that you start with a "trusted root public key" and accept any public key cert that is signed by this root key. (and don't forget about revokation check... :-) The entire PKI infrastructure (and "chain reaction") goes alive again. Regards, --- David ----- Original Message ----- From: "Michael Thomas" To: "Paul Hoffman / VPNC" Cc: "IP Security List" Sent: Monday, November 19, 2001 6:05 PM Subject: Re: SOI: preshared > > Sure. Same considerations apply though. > > Mike > > Paul Hoffman / VPNC writes: > > At 11:45 AM -0800 11/19/01, Michael Thomas wrote: > > >The consequence of using naked public keys in lieu > > >of symmetric keys is that you incur the cost of > > >both a DH and a RSA operation. You could > > >conceivably get rid of the DH if you don't care > > >about identity, but for preshared keys it seems > > >questionable why you'd want to do _either_. > > > > It doesn't have to be a bare public key. A self-signed cert has other > > signed attributes in it, such as the key validity date and an > > identity. The recipient simply needs to pull the public key out of > > the cert to check that key against its set of trusted public keys. > > (One doesn't need to trust this as a root cert: it is easy to make a > > policy of "if I get a self-signed cert as an identifier, I won't do > > any chaining, even if the cert says chaining is OK"). > > > > Using self-signed certs is the method that JFK currently uses to > > allow simple trust between two parties without needing a PKI. There > > is no shared-secret mode. > > > > --Paul Hoffman, Director > > --VPN Consortium > From owner-ipsec@lists.tislabs.com Wed Nov 21 09:44:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALHi2810671; Wed, 21 Nov 2001 09:44:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16109 Wed, 21 Nov 2001 11:41:36 -0500 (EST) From: "sankar ramamoorthi" To: Subject: RE: IKEv2 (son-of-ike) draft Date: Wed, 21 Nov 2001 08:20:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20011118071052.0F71654C53@tailor.sailpix.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > dharkins@tibernian.com > Sent: Saturday, November 17, 2001 11:11 PM > To: ipsec@lists.tislabs.com > Subject: IKEv2 (son-of-ike) draft > > > This draft was submitted but hasn't shown up yet in the repository > (the I-D editor is, no doubt, swamped) so in the interest of giving > people more time to look at it prior to Salt Lake here's a link: > > http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt > > Please send comments to the list. > > Dan. > Hi, Some comments on IKEV2 draft. The comments are based on early version of the draft, but my quick review indicates there is not much difference between what I reviewed versus the published one. Regards, -- sankar -- General Comments ---------------- o PreShared keys are not described. If they are not supported, the rationale for not supporting them will be useful. o Is IKEV2 document supposed to combine RFC 2409, 2408 and 2407? As stated the document seems to meet the purpose of being a single point of reference. However some details are missing and requires referring back to the RFCS 2408, 2409. For example, Description on IKE exhanges are missing. hash payload description is missing (as in section of 5 of RFC 2409) o Is aggressive mode exchange supported? There seems to be no description of a mode where ID can be sent in the first packet? Does it mean the responder should always select the policy based on ip address? This may be limiting in scenarios where policy is detmined by not what the end-station can support - but who the peer is. o section 2.9 describes that the absence of TR payload means no restriction. Wildcard support is a major difference from IKEV1 and should be called out in section 1.2 o section 1.2 indicates that the hash problem in [1] has been addressed, but I could not find the detail about that inside. Also references are missing. o Description in many places seem to imply that IKEV2 does not support dangling ipsec SAs. This should be called out in section 1.2. o In IKEV2 message id is maintained as a sequence number. IKEV2 also allows multiple ipsec SA negotiations to go in parallel. These two seem contradictory, since parallel ipsec SA negotiations may require an ike endpoint to maintain information about more than 10 exchanges. One could always negotiate all the required source-dest address combinations in one ipsec SA negotiation(as IKEV2 seems to allow a rich set of TARGET Records), but an end-point is not prevented from negotiating multiple SAs in parallel. o Appendix B seems to imply the use of explicit IV as in ESP. This is a major difference. It would be useful to add more description including the payload format. Other comments inline. >IPSEC Working Group Dan Harkins >INTERNET-DRAFT Charlie Kaufman > Radia Perlman > editors >draft-ietf-ipsec-ike-00.txt November 2001 > > > The Internet Key Exchange (IKE) Protocol > > > > Status of this Memo > > This document is an Internet Draft and is in full conformance with > all provisions of Section 10 of RFC2026 [Bra96]. Internet Drafts are > working documents of the Internet Engineering Task Force (IETF), its > areas, and working groups. Note that other groups may also distribute > working documents as Internet Drafts. > > Internet Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is 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 (Australia), ds.internic.net (US East Coast), or > ftp.isi.edu (US West Coast). > > > Abstract > > This document describes version 2 of the IKE (Internet Key Exchange) > protocol. IKE performs mutual authentication and establishes an IKE > security association that can be used to efficiently establish SAs > for ESP, AH and/or IPcomp. This version greatly simplifies IKE by > replacing the 8 possible phase 1 exchanges with a single exchange > based on public signature keys. The single exchange provides > identity hiding, yet works in 2 round trips (all the identity hiding > exchanges in IKE v1 required 3 round trips). Latency of setup of an > IPsec SA is further reduced from IKEv1 by allowing setup of an SA for > ESP, AH, and/or IPcomp to be piggybacked on the initial IKE exchange. > It also improves security by allowing the Responder to be stateless > until it can be assured that the Initiator can receive at the claimed > IP source address. This version also presents the entire protocol in > a single self-contained document, in contrast to IKEv1, in which the > protocol was described in ISAKMP (RFC 2408), IKE (RFC 2409), and the > DOI (RFC 2407) documents. > > >Table of Contents > > > 1. Introduction > 1.1 The IKE Protocol > 1.2 Changes from IKEv1 > 1.3 Requirements Terminology > 2 Protocol Overview > 2.1 Use of Retransmission Timers > 2.2 Use of Sequence Numbers for Message ID > 2.3 Window Size for overlapping requests > 2.4 State Synchronization and Connection Timeouts > 2.5 Version Numbers and Forward Compatibility > 2.6 Cookies > 2.7 Cryptographic Negotiation > 2.8 Rekeying > 2.9 Traffic Restriction Negotiation > 2.10 Nonces > 3 The Phase 1 Exchange > 3.1 Authentication of the IKE-SA > 4 The CREATE-CHILD-SA (Phase 2) Exchange > 4.1 Generating Keying Material for Child-SAs > 5 Informational (Phase 2) Exchange > 6 Error Handling > 7 Header and Payload Formats > 7.1 The IKE Header > 7.2 Generic Payload Header > 7.3 Security Association Payload > 7.3.1 Proposal Substructure > 7.3.2 Transform Substructure > 7.3.3 Transform Attributes > 7.3.4 Attribute Negotiation > 7.4 Key Exchange Payload > 7.5 Identification Payload > 7.6 Certificate Payload > 7.7 Certificate Request Payload > 7.8 Signature Payload > 7.9 Nonce Payload > 7.10 Notify Payload > 7.10.1 Notify Message Types > 7.11 Delete Payload > 7.12 Vendor ID Payload > 7.13 Traffic Restriction Payload > 8 Diffie-Hellman Groups > 9 Security Considerations > 10 IANA Considerations > 10.1 Attribute Classes > 10.2 Encryption Algorithm Class > 10.3 Hash Algorithm > 10.4 Group Description and Group Type > 10.5 Life Type > 11 Acknowledgements > 12 References > Appendix A > Appendix B: Cryptographic Protection of IKE Data > Authors' Addresses > > > 1 Introduction...................................................2 > 2 Terms and Definitions..........................................3 > 3 Protocol Overview..............................................6 > 4 Header and Payload Formats.....................................9 > 5 IKE Exchanges.................................................11 > 5.1 Phase 1 Exchange............................................11 > 5.2 Anti-Replay for Post-Phase 1 Exchanges......................12 > 5.3 Phase 2 Exchange............................................12 > 5.4 Informational Exchange......................................12 > 6 Rekeying......................................................13 > 6.1 Phase 1 Rekeying............................................14 > 6.2 Phase 2 Rekeying............................................23 > 7 Mandatory Options.............................................31 > 8 IKE Internal State............................................32 > 8.1 Phase 1 State...............................................33 > 8.2 Phase 2 State...............................................34 > 9 Diffie-Hellman Groups.........................................35 > 10 Payload Explosion of Sample Exchange.........................36 > 11 Security Considerations......................................35 > 12 IANA Considerations..........................................36 > 13 Acknowledgements.............................................37 > 14 References...................................................37 > Appendix A......................................................40 > Appendix B......................................................43 > Author's Address................................................45 > >1. Introduction > > IP Security (IPsec) provides confidentiality, data integrity, and > data source authentication to IP datagrams. These services are > provided by maintaining shared state between the source and the sink > of an IP datagram. This state defines, among other things, the > specific services provided to the datagram, which cryptographic > algorithms will be used to provide the services, and the keys used as > input to the cryptographic algorithms. > > Establishing this shared state in a manual fashion does not scale > well. Therefore a protocol to establish this state dynamically is > needed. This memo describes such a protocol-- the Internet Key > Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was > defined in RFCs 2407, 2408, and 2409. This single document is > intended to replace all three of those RFCs. > > >1.1 The IKE Protocol > > IKE performs mutual authentication between two parties and > establishes an IKE security association that includes shared secret > information that can be used to efficiently establish SAs for ESP > (RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393). We call the IKE > SA an "IKE-SA", and the SAs for ESP, AH, and/or IPcomp that get set > up through that IKE-SA we call "child-SA"s. > > We call the setup of the IKE-SA "phase 1" and subsequent IKE > exchanges "phase 2" even though setup of a child-SA can be > piggybacked on the initial phase 1 exchange. The phase 1 exchange is > two request/response pairs. A phase 2 exchange is one > request/response pair, and can be used to create or delete a child- > SA, delete the IKE-SA, or give information such as error conditions. > > IKE message flow always consists of a request followed by a response. > It is the responsibility of the requester to ensure reliability. If > the response is not received within a timeout interval, the requester > retransmits the request. > > The first request/response of a phase 1 exchange, which we'll call > IKE_SA_init, negotiates security parameters for the IKE-SA, and sends > Diffie-Hellman values. We call the response IKE_SA_init_response. > > The second request/response, which we'll call IKE_auth, transmits > identities, proves knowledge of the private signature key, and > optionally sets up an SA for AH and/or ESP and/or IPcomp. We call > the response IKE_auth_response. > > If the Responder feels it is under attack, and wishes to use a > stateless cookie (see section on cookies). it can respond to an > IKE_SA_init with an IKE_SA_init_reject with a cookie value that must > be sent in order with a subsequent IKE_SA_init_request. The > Initiator then sends another IKE_SA_init, but this time including the > Responder's cookie value. > > Phase 2 exchanges each consist of a single request/response pair. The > types of exchanges are CREATE_CHILD_SA (creates a child-SA), or an > informational exchange which deletes a child-SA or the IKE-SA or > informs the other side of some error condition. All these messages > require a response, so an informational message with no payloads can > serve as a check for aliveness. > >1.2 Changes from IKEv1 > > 1) To define the entire protocol in a single document, rather than > several that cross reference one another; > > 2) To simplify IKE by making phase 1 be a single exchange (based on > public signature keys); > > 3) To decrease IKE's latency by making the initial exchange be 2 > round trips (4 messages), and allowing the ability to piggyback setup > of a Child-SA on that exchange; > > 4) To reduce the number of possible error states by making the > protocol reliable (all messages are acknowledged) and sequenced. This > allows shortening Phase 2 exchanges from 3 messages to 2; > > 5) To increase robustness by allowing the Responder, if under attack, > to require return of a cookie before the Responder commits any state > to the exchange; > > 6) To fix bugs such as the hash problem documented in []; > > 7) To avoid unnecessary exponential explosion of space in attribute > negotiation, by allowing choices when multiple algorithms of one type > (say, encryption) can work with any of a number of acceptable > algorithms of another type (say, hash); > > 8) To simplify and clarify how shared state is maintained in the > presence of network failures; > > and 11) To maintain existing syntax to the extent possible to make it > likely that implementations of IKEv1 can be enhanced to support IKEv2 > with minimum effort. > >1.3 Requirements Terminology > > Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and > "MAY" that appear in this document are to be interpreted as described > in [Bra97]. > > >2 Protocol Overview > > > IKE runs over UDP port 500. Since UDP is a datagram (unreliable) > protocol, IKE includes in its definition recovery from transmission > errors, including packet loss, packet replay, and packet forgery. IKE > is designed to function so long as at least one of a series of > retransmitted packets reaches its destination before timing out and > the channel is not so full of forged and replayed packets so as to > exhaust the network or CPU capacities of either endpoint. Even in the > absence of those minimum performance requirements, IKE is designed to > fail cleanly (as though the network were broken). > >2.1 Use of Retransmission Timers > > All messages in IKE exist in pairs: a request and a response. Either > end of a security association may initiate requests at any time, and > there can be many requests and responses "in flight" at any given > moment. But each message is labelled as either a request or a > response and for each pair one end of the security association is the > Initiator and the other is the Responder. > > For every pair of messages, the Initiator is responsible for > retransmission in the event of a timeout. The Responder will never > retransmit a response unless it receives a retransmission of the > request. In that event, the Responder MUST either ignore the > retransmitted request except insofar as it triggers a retransmission > of the response OR if the request is idempotent, the Responder may > choose to process the request again and send a semantically > equivalent reply. > > IKE is a reliable protocol, in the sense that the Initiator MUST > retransmit a request until either it receives a corresponding reply > OR it deems the IKE security association to have failed and it > discards all state associated with the IKE-SA and any Child-SAs > negotiated using that IKE-SA. > >2.2 Use of Sequence Numbers for Message ID > > Every IKE message contains a Message ID as part of its fixed header. > This Message ID is used to match up requests and responses, and to > identify retransmissions of messages. > > The Message ID is a 32 bit quantity, with is zero for the first IKE > message. Each endpoint in the IKE Security Association maintains two > "current" Message IDs: the next one to be used for a request it > initiates and the next one it expects to see from the other end. > These counters increment as requests are generated and received. > Responses always contain the same message ID as the corresponding > request. That means that after the initial setup, each integer n will > appear as the message ID in four distinct messages: The nth request > from the original IKE Initiator, the corresponding response, the nth > request from the original IKE Responder, and the corresponding > response. If the two ends make very different numbers of requests, > the Message IDs in the two directions can be very different. There is > no ambiguity in the messages, however, because each packet contains > enough information to determine which of the four messages a > particular one is. > > In the case where the IKE_SA_init is rejected (e.g. in order to > require a cookie), the second IKE_SA_init message will begin the > sequence over with Message #0. > >2.3 Window Size for overlapping requests > > In order to maximize IKE throughput, an IKE endpoint MAY issue > multiple requests before getting a response to any of them. For > simplicity, an IKE implementation MAY choose to process requests > strictly in order and/or wait for a response to one request before > issuing another. Certain rules must be followed to assure > interoperability between implementations using different strategies. > > After an IKE-SA is set up, either end can initiate one or more > requests. These requests may pass one another over the network. An > IKE endpoint MUST be prepared to accept and process a request while > it has a request outstanding in order to avoid a deadlock in this > situation. An IKE endpoint SHOULD be prepared to accept and process > multiple requests while it has a request outstanding. By processing, do you mean the end-point should be able to buffer the data. > > An IKE endpoint MUST NOT have a window size for transmitted IKE > requests of more than 10. In other words, when it needs to make a > request n, it MUST wait until it has received responses to all > requests up through request n-10. An IKE endpoint MUST keep a copy of > (or be able to regenerate exactly) each request it has sent until it > receives the corresponding response. An IKE endpoint MUST keep a copy > of (or be able to regenerate with semantic equivalence) its previous > 10 responses in case its response was lost and the Initiator requests > its retransmission by retransmitting the request. > > The simplest compliant IKE implementation will wait for a response to > each request before sending the next request, but will process > incoming requests while its request is outstanding. It MAY also > process incoming requests only in order. If a request comes in with > an unexpected sequence number, it MAY be discarded. The Initiator > will eventually resend the original lost requests and all the > requests that followed it. > > An IKE endpoint SHOULD be capable of processing incoming requests out > of order to maximize performance in the event of network failures or > packet reordering. > >2.4 State Synchronization and Connection Timeouts > > An IKE endpoint is allowed to forget all of its state associated with > an IKE-SA and the collection of corresponding child-SAs at any time. > This is the anticipated behavior in the event of an endpoint crash > and restart. It is important when an endpoint either fails or > reinitializes its state that the other endpoint detect those > conditions and not continue to waste network bandwidth by sending > packets over those SAs and having them fall into a black hole. > > Since IKE is designed to operate in spite of Denial of Service (DoS) > attacks from the network, an endpoint MUST NOT conclude that the > other endpoint has failed based on any routing information (e.g. ICMP > messages) or IKE messages that arrive without cryptographic > protection (e.g., notify messages complaining about unknown SPIs). An > endpoint MUST conclude that the other endpoint has failed only when > repeated attempts to contact it have gone unanswered for a timeout > period. An endpoint SHOULD suspect that the other endpoint has failed > based on routing information and initiate a request to see whether > the other endpoint is alive. To check whether the other side is > alive, IKE provides a null query notify message that requires an > acknowledgment. If a cryptographically protected message has been > received from the other side recently, unprotected notifications MAY > be ignored. Implementations MUST limit the rate at which they > generate responses to unprotected messages. > > Numbers of retries and lengths of timeouts are not covered in this > specification because they do not affect interoperability. It is > suggested that messages be retransmitted at least a dozen times over > a period of at least several minutes before giving up on an SA, but > different environments may require different rules. > > Note that with these rules, there is no reason to negotiate and agree > upon an SA lifetime. If IKE presumes the partner is dead, based on > repeated lack of acknowledgment to an IKE message, then the IKE SA > and all SAs set up through that IKE-SA are deleted. > > An IKE endpoint MAY delete inactive Child-SAs to recover resources > used to hold their state. If an IKE endpoint chooses to do so, it > MUST send Delete payloads to the other end notifying it of the > deletion. It MAY similarly time out the IKE-SA. Closing the IKE-SA > implicitly closes all associated Child-SAs. An IKE endpoint SHOULD > send a Delete payload indicating that it has closed the IKE-SA. > > One last instance in which an SA might be deleted is by the > Responder, in the case where no IKE-auth message arrives from the > Initiator within a timeout period. This would occur if the Initiator > has crashed after sending the IKE-SA-init, or if the IKE-SA-init is > actually a denial of service message sent from an attacker. > >2.5 Version Numbers and Forward Compatibility > > This document describes version 2.0 of IKE, meaning the major version > number is 2 and the minor version number is zero. It is likely that > some implementations will want to support both version 1.0 and > version 2.0, and in the future, other versions. > > The major version number should only be incremented if the packet > formats have changed so dramatically that an older version node would > not be able to interoperate with messages in the new version format. > The minor version number indicates new capabilities, and MUST be > ignored by a node with a smaller minor version number, but used for > informational purposes by the node with the larger minor version > number. For example, it might indicate the ability to process a newly > defined notification message. The node with the larger minor version > number would simply note that its correspondent would not be able to > understand that message and therefore would not send it. > > If you receive a message with a higher major version number, you MUST > drop the message and SHOULD send an unauthenticated notification > message containing the highest version number you support. If you > support major version n, and major version m, you MUST support all > versions between n and m. If you receive a message with a major > version that you support, you MUST respond with that version number. > In order to prevent two nodes from being tricked into corresponding > with a lower major version number than the maximum that they both > support, IKE has a flag that indicates that the node is capable of > speaking a higher major version number. > > Thus the major version number in the IKE header indicates the version > number of the message, not the highest version number that the > transmitter supports. If A is capable of speaking versions n, n+1, > and n+2, and B is capable of speaking versions n and n+1, then they > will negotiate speaking n+1, where A will set the flag indicating > ability to speak a higher version. If they mistakenly (perhaps > through an active attacker sending error messages) negotiate to > version n, then both will notice that the other side can support a > higher version number, and they MUST break the connection and > reconnect using version n+1. > > Note that v1 does not follow these rules, because there is no way in > v1 of noting that you are capable of speaking a higher version > number. So an active attacker can trick two v2-capable nodes into > speaking v1. Given the design of v1, there is no way of preventing > this, but this version number discipline will prevent such problems > in future versions. > > Also for forward compatibility, all fields marked RESERVED MUST be > set to zero by a version 2.0 implementation and their content MUST be > ignored by a version 2.0 implementation ("Be conservative in what you > send and liberal in what you receive"). In this way, future versions > of the protocol can use those fields in a way that is guaranteed to > be ignored by implementations that do not understand them. > Similarly, field types that are not defined are reserved for future > use and implementations of version 2.0 MUST skip over those fields > and ignore their contents. > > IKEv2 adds a "critical" flag to each payload header for further > flexibility for forward compatibility. If the critical flag is set > and the payload type is unsupported, the message MUST be rejected and > the response to the IKE request containing that payload MUST include > a notify payload INVALID-PAYLOAD-TYPE, indicating an unsupported > critical payload was included. If the critical flag is not set and > the payload type is unsupported, that payload is simply skipped. > >2.6 Cookies > > The term "cookies" originates with Karn and Simpson [RFC 2522] in > Photurus, an early proposal for IKE/IPsec. It has persisted because > the IETF has never rejected an offer involving cookies. In IKEv2, > the cookies serve two purposes. First, they are used as IKE-SA > identifiers in the headers of IKE messages. As with ESP and AH, in > IKEv2 the recipient of a message chooses an IKE-SA identifier that > uniquely defines that SA to that recipient. For this purpose (IKE-SA > identifiers), it might be convenient for the cookie value to be > chosen so as to be a table index for fast lookups of SAs. But this > conflicts with the second purpose of the cookies (to be explained > shortly). > > Unlike ESP and AH where only the recipient's SA identifier appears in > the message, in IKE, the sender's IKE SA identifier is also sent in > every message. In IKEv1 the IKE-SA identifier consisted of the pair > (Initiator cookie, Responder cookie), whereas in IKEv2, the SA is > uniquely defined by the recipient's SA identifier even though both > are included in the IKEv2 header. > > The second use of cookies in IKEv2 is for a limited protection from > denial of service attacks. Receipt of a request to start an SA can > consume substantial resources. A likely denial of service attack > against IKE is to overwhelm a system with large numbers of SA > requests from forged IP addresses. This can consume CPU resources > doing the crypto, and memory resources remembering the state of the > "half open" connections until they time out. A robust design would > limit the resources it is willing to devote to new connection > establishment, but even so the denial of service attack could > effectively prevent any new connections. > > This attack can be rendered more difficult by requiring that the > Responder to an SA request do minimal computation and allocate no > memory until the Initiator has proven that it can receive messages at > the address it claims to be sending from. This is done in a stateless > way by computing the cookie in a way that the Responder can recompute > the same value, but the Initiator can't guess it. A recommended > strategy is to compute the cookie as a cryptographic hash of the > Initiator's IP address, the Initiator's cookie value (its chosen IKE > security identifier), and a secret known only to the Responder. That > secret should be changed periodically to prevent the "cookie jar" > attack where an attacker accumulates lots of cookies from lots of IP > addresses over time and then replays them all at once to overwhelm > the Responder. > > In ISAKMP and IKEv1, the term cookie was used for the connection > identifier, but the protocol did not permit their use against this > particular denial of service attack. To avoid the cookie exchange > adding extra messages to the protocol in the common case where the > Responder is not under attack, IKEv2 goes back to the approach in > Oakley (RFC 2412) where the cookie challenge is optional. Upon > receipt of an IKE_SA_init, a Responder may either proceed with > setting up the SA or may tell the Initiator to send another > IKE_SA_init, this time providing a supplied cookie. > > It may be convenient for the IKE-SA identifier to be in index into a > table rather than a number that must be looked up. It is not > difficult for the Initiator to choose an IKE-SA identifier that is > convenient as a table identifier, since the Initiator does not need > to use it as an anti-clogging token, and is keeping state. IKEv2 > allows the Responder to initially choose a stateless anti-clogging > type cookie by responding to an IKE_SA_init with a cookie request, > and then upon receipt of an IKE_SA_init with a valid cookie, change > his cookie value from the computed anti-clogging token to a more > convenient value, by sending a different value for his cookie in the > IKE_SA_init_response. This will not confuse the Initiator (Alice), > because she will have chosen a unique cookie value A, so if her SA > state for the partially set up IKE-SA says that Bob's cookie for the > SA that Alice knows as "A" is B, and she receives a response from Bob > with cookies (A,C), that means that Bob wants to change his value > from B to C for the SA that Alice knows uniquely as "A". > > Another reason why Bob might want to change his cookie value is that > it is possible (though unlikely) that Bob will choose the same cookie > for multiple SAs if the hash of the Initiator cookie, Initiator IP > address, and whatever other information might be included happens to > hash to the same value. > > In IKEv2, like IKEv1, both 8-byte cookies appear in the message, but > in IKEv2 (unlike v1), the value chosen by the message recipient > always appears first in the message. This change eliminates a flaw in > IKEv1, as well as having other advantages (allowing the recipient to > look up the SA based on a small, conveniently chosen value rather > than a 16-byte pseudorandom value.) > > The flaw in IKEv1 is that it was possible (though unlikely) for two > connections to have the same set of cookies. For instance, if Alice > chose A as the Initiator cookie when initiating a connection to Bob, > she might subsequently receive a connection request from Carol, and > Carol might also have chosen A as the Initiator cookie. Whatever > value Alice responds to Carol, say B, might be selected as the > Responder cookie by Bob for the Alice-Bob SA. Then Alice would be > involved in two IKE sessions, both of which had Initiator cookie=A > and Responder cookie=B. To minimize, but not eliminate, the > probability of this happening, version 1 IKE recommended that cookies > be chosen at random. > > One additional rule in IKEv2 is that the two cookie values have to be > different. The Responder is responsible for choosing a value > different from the one chosen by the Initiator. If the Responder's > stateless cookie happens to be equal to the Initiator's cookie, that > is legal provided that the Responder change his cookie value to > something different from the Initiator's in his IKE_SA_init_response. > The reason the cookies must be different in the two directions is to > prevent reflection attacks. Another way reflection attacks could have > been avoided was to compute different integrity and encryption keys > in the two directions, but that would be another change from IKEv1. > > The cookies are one of the inputs into the function that computes the > keying material. If the Responder initially sends a stateless cookie > value in its IKE_SA_init_reject, and changes to a different value > when it sends its IKE_SA_init_response, it is the cookie value in the > IKE_SA_init_response that is the input for generating the keying > material. > >2.7 Cryptographic Negotiation > > The payload type known as "SA" indicates a proposal for a set of > choices of protocols (e.g., IKE, ESP, AH, and/or IPcomp) for the SA > as well as cryptographic algorithms associated with each protocol. In > IKEv1 it was extremely complex, and required a separate proposal for > each possible combination. If there were n algorithms of one type > (say encryption) that were acceptable and worked with any one of m > algorithms of another type (say integrity protection), then it would > take space proportional to n*m to express all of the possibilities. > > IKEv2 has simplified the format of the SA payload somewhat, but in > addition to simplifying the format, solves the exponential explosion > by allowing, within a proposal, multiple algorithms of the same type. > If more than one algorithm of the same type (say encryption) appears > in a proposal, that means that the sender of that SA proposal is > willing to accept the proposal with any of those choices, and the > recipient when it accepts the proposal selects exactly one of each of > the types of algorithms from the choices offered within that > proposal. > > An SA consists of one or more proposals. Each proposal has a number > (so that the recipient can specify which proposal has been accepted), > and contains a protocol (IKE, ESP, AH, or IPcomp), an SPI to be used > by ESP or AH or IPcomp, and set of transforms. Each transform > consists of a type (e.g., encryption, integrity protection, > authentication, Diffie-Hellman group, compression) and a transform ID > (e.g., DES, IDEA, HMAC-MD5). To negotiate an SA that does ESP, > IPcomp, and AH, the SA will contain three proposals with the same > proposal number, one proposing ESP, a 4 byte SPI to be used with ESP, > and a set of transforms; one proposing AH, a 4-byte SPI to be used > with AH, and a set of transforms; and one proposing IPcomp, a 2-byte > SPI to be used with IPcomp, and a set of transforms. If the recipient > selects that proposal number, it means the SA will do all of ESP, AH, > and IPcomp. > > In IKEv2, since the Initiator sends her Diffie-Hellman value in the > IKE_SA_init, she must guess at the Diffie-Hellman group that Bob will > select from her list. If the one she guesses is not the one Bob would > have chosen, then Bob's response informs her of the group he would > choose, and notifies her that her Diffie-Hellman value is invalid > because it does not match the chosen group. In this case Alice will > send a new IKE_SA_init, with the same original choices in the same > priority order as in her original IKE_SA_init. (This is important to > prevent an active attacker from tricking them into using a weaker > group than they would have agreed upon.) > > If none of Alice's options are acceptable, then Bob notifies her > accordingly. > >2.8 Rekeying > > Security associations negotiated in both phase 1 and phase 2 contain > secret keys which may only be used for a limited amount of time. This > determines the lifetime of the entire security association. When the > lifetime of a security association expires the security association > MUST NOT be used. If there is demand, new security associations can > be established. Reestablishment of security associations to take the > place of ones which expire is referred to as "rekeying". > > To rekey a child-SA, open a new, equivalent SA, and when the new one > is established, delete the old one. To rekey an IKE-SA, establish a > new equivalent IKE-SA, establish new, equivalent child-SAs for all > the child-SAs of the original IKE-SA, and then delete the old IKE-SA, > which will automatically cause deletion of all the old IKE-SA's child > SAs. The above implies that IKE V2 mandates no dangling ipsec SAs. This is a big change and should be called out explicitly in the differences section. > > SAs SHOULD be rekeyed proactively, i.e., the new SA should be > established before the old one expires and becomes unusable. Enough > time should elapse between the time the new SA is established and the > old one becomes unusable so that traffic can be switched over to the > new SA. > > A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes > were negotiated. In IKEv2, each end of the SA is responsible for > enforcing its own lifetime policy on the SA and rekeying the SA when > necessary. If the two ends have different lifetime policies, the end > with the shorter lifetime will end up always being the one to request > the rekeying. > > This form of rekeying will temporarily result in multiple similar SAs > between the same pairs of nodes. When there are two SAs eligible to > receive packets, a node MUST accept incoming packets through either > SA. The node that initiated the rekeying SHOULD delete the older SA > after the new one is established. > There is some ambiguity here. Would it be better to state that the node that initiated the rekeying start using the new SA right away right after rekeying even if the older SA has not expired? It may be necessary to keep the older SA till their lifetime expires to receive inbound packets on that SA. >2.9 Traffic Restriction Negotiation > > When a child-SA is established, IKE negotiates the type of traffic to > be sent across that SA. This is done in the payload type TR (Traffic > Restriction). In the child-create request message, the Initiator > offers a description of the traffic to be sent across that SA. This > consists of a set of IP ranges and ports for the source of packets, > and a set of IP ranges and ports for the destination of packets. > "Source" of packets is defined from the point of view of the > Initiator, so the Initiator of the child-SA specifies in the TRs > (traffic restriction-source) a description of sources of packets it > will forward across the SA, and in the TRd (traffic restriction- > destination) a description of destinations of packets it will forward > across the SA. > > A missing TR payload indicates no restriction. So for instance, if > TRs indicates IP address subnet 17.23.52.* and TRd is missing, it > means the initiator is proposing that traffic sources be within the > 17.23.52.* subnet, and destinations can be anything. > Wildcarding is a powerful feature. Are there any security implications? Also if sender is not sending TRd to specify that the destination can be anything, is the responder allowed to narrow down the choice by specifying a TRr record? > The Responder is allowed to narrow the choices by selecting a subset > of the traffic, for instance by eliminating some address or port > ranges from sources and/or destinations, or by narrowing any of the > offered ranges. Because RFC 2401 also allows the policy that an SA > must only have a single IP address pair, and since the Responder > can't guess which IP address pair will be needed, the Responder might > also respond with a notify payload in the response indicating traffic > description unacceptable, single pair required. Does it mean IkeV2 will be in violation of RFC2401? > > Note that the traffic restriction applies to both child-SAs (from the > Initiator to the Responder and from the Responder to the Initiator), > but the Responder does not change the order of the TR payloads, and > what the Responder refers to as TRs is still from the point of view > of the Initiator. An address within the restriction of TRs would > appear as a source address in the child-SA from the Initiator, and > would appear as a destination address in traffic on the child-SA to > the Initiator (from the Responder). > > IKEv2 is more flexible than IKEv1. IKEv2 allows sets of ranges of > both addresses and ports, and allows the Responder to choose a subset > of the requested traffic rather than simply responding "not > acceptable". Bit confusing. On one hand IKEV2 allows a rich variety of targets to be specified, but requires narrowing down only from the specified set of target without any modifications. That implies the sender has to list all possible combinations. Also, if we allow wildcarding then why not allow a opaque policy id understood to ipsec peers in the TR payload. That would provide the max. flexiblity in terms of ipsec proxy addressing. > >2.10 Nonces > > The IKE_SA_init_request and the IKE_SA_init_response each contain a > nonce. The nonce value MUST be unique (not reused in subsequent > connections with the same Diffie-Hellman values). It need not be > random or unpredictable. However, an easy method of making it unique > is to choose nonce values at random. > > The child-create request and the child-create response also each > contain a nonce. Again, the nonce value MUST be unique, but need not > be unpredictable or random. However, for child-SA's the two nonces > MUST be different, since otherwise the keys might be the same in the > two directions. > >3 The Phase 1 Exchange > > The base Phase 1 exchange is a four message exchange (two > request/response pairs). The first pair of messages, the IKE_SA_init > exchange, negotiate cryptographic algorithms, indicate trusted CA > names, exchange nonces, and do a Diffie-Hellman exchange. This pair > might be repeated if the response indicates that none of the > cryptographic proposals are acceptable, or the Diffie-Hellman group > chosen by the Initiator for sending her Diffie-Hellman value is not > the group that the Responder would have chosen, of if the Responder > is under attack and will only answer IKE_SA_init requests containing > a valid returned cookie value. > > The second pair of messages, the IKE_auth and the IKE_auth_response, > authenticate the previous messages, exchange identities and > certificates, and optionally also establish a child_SA. This pair of > messages is encrypted with a key established through the IKE_SA_init > exchange, so the identities are hidden from eavesdroppers. > > The shared secret information is computed as follows. A quantity > called SKEYSEED is calculated from the nonces exchanged during the > IKE_SA_init exchange, and the Diffie-Hellman shared secret > established during that exchange. SKEYSEED is used to calculate > three other secrets: SKEYSEED_d used for deriving new keys for the > child-SAs established with this IKE-SA; SKEYSEED_a used for > authenticating the component messages of subsequent exchanges; and > SKEYSEED_e used for encrypting (and of course decrypting) all > subsequent exchanges. SKEYSEED and its derivatives are computed as > follows: > > SKEYSEED = prf(Ni_b | Nr_b, g^ir) What is Ni_b? > SKEYSEED_d = prf(SKEYSEED, g^ir | CKY-I | CKY-R | 0) > SKEYSEED_a = prf(SKEYSEED, SKEYSEED_d | g^ir | CKY-I | CKY-R | 1) > SKEYSEED_e = prf(SKEYSEED, SKEYSEED_a | g^ir | CKY-I | CKY-R | 2) > > CKY-I and CKY-R are the Initiator's and Responder's cookie, > respectively, from the IKE header. g^ir is the shared secret from the > ephemeral Diffie-Hellman exchange. 0, 1, and 2 are represented by a > single byte containing the value 0, 1, or 2 (the values, not the > ASCII representation of the digits). prf is the "pseudo-random" > cryptographic function negotiated in the IKE-SA-init exchange. The > pseudo-random functions defined for IKE are HMAC_MD5 and HMAC_SHA, > defined in RFC XXXX. > > > In the following description, the payloads contained in the message > are indicated by names such as SA. The details of the contents of > each payload are described later. Payloads which may optionally > appear will be shown in brackets, such as [CERTREQ], would indicate > that optionally a certificate request payload can be included. The > certificate request payload indicates a CA name trusted by the > sender. If the sender trusts multiple CAs, it includes multiple > CERTREQ payloads, one for each trusted CA. > > The Phase 1 exchange is as follows: > > Initiator Responder > ----------- ----------- > HDR, SA, KE, Ni [,CERTREQ] --> > > The SA payload states the cryptographic algorithms the Initiator > supports. The KE payload sends the Initiator's Diffie-Hellman value. > Ni is the Initiator's nonce, sent in an N payload. > > <-- HDR, SA, KE, Nr [,CERTREQ] > HASH payloads are missing? > The Responder chooses among the Initiator's cryptographic algorithms > and expresses that choice in the SA payload, completes the Diffie- > Hellman exchange with the KE payload, and sends its nonce in the N > payload (with an "r" to signify the Responder's nonce). > > At this point in time each party generates SKEYSEED and its > derivatives. The following two messages, the SA_auth and > SA_auth_response, are encrypted (as indicated by the '*' following > the IKE header) and the encryption bit in the IKE header is set. > > HDR*, ID, SIG [, CERT] [, SA, TRs, TRd] > --> > > The Initiator identifies herself with the ID payload, authenticates > herself to the Responder with the SIG payload, optionally sends one > or more certificates, and optionally begins negotiation of a child-SA > using the SA payload and the Traffic Restriction payloads: TRs (which > describes sources of packets to be sent over the child-SA), and TRd > (which describes destinations of packets to be sent over the child- > SA). The protocol (ESP, AH, and/or IPcomp) and the SPI she wants to > use to identify her inbound child-SA are placed in the "protocol" and > "SPI" fields, respectively, in the SA payload. > > > <-- HDR*, ID, SIG [, CERT] > [, SA, TRs, TRd] > > The Responder identifies himself with an ID payload authenticates > himself with the SIG payload, optionally sends a certificate, and > completes negotiation of a child-SA using the SA payload. The > Responder places the SPI he wants to use to identify his inbound > child-SA in the SA payload. The TRs and TRd, respectively, describe > the sources and destinations of packets to be sent over the child-SA. > These MUST be equal to, or a subset of, the ones suggested by the > Initiator. > >3.1 Authentication of the IKE-SA > > The peers are authenticated by having each sign the concatenation of > the first two messages of the exchange. Optionally, they MAY include > a certificate or certificate chain providing evidence that the public > key they are using belongs to the name in the ID payload. The public > key signature will be computed using algorithms chosen by the signer, > most commonly an RSA-signed PKCS1-padded-SHA1-hash of the > concatenated messages or a DSS-signed SHA1-hash of the concatenated > messages. There is no requirement that the Initiator and Responder > sign with the same cryptographic algorithms. The choice of > cryptographic algorithms depends on the type of public key each has. > This type is either indicated in the certificate supplied or, if the > public keys were exchanged out of band, the key types must have been > similarly learned. The above description implies that IKEV2 has no need for negotiating Authentication of type RSA signature/DSA signature explicitly, yet in section 7.3.2 while describing the transform attributes all the IKEV1 authentication values seem to be supported. If one side negotiates RSA signature based auth, can the other side send a DSA cert. > >4 The CREATE-CHILD-SA (Phase 2) Exchange > > A phase 2 exchange is one request/response pair, and can be used to > create or delete a child-SA, delete the IKE-SA, or deliver > information such as error conditions. It is encrypted and integrity > protected using the keys negotiated during the creation of the IKE- > SA. The two directions of flow use the same keys. > > Messages are cryptographically protected using the cryptographic > algorithms and keys negotiated in the first two messages of the IKE > exchange using a syntax based on the encoding in ESP (see Appendix > B). Encryption uses a key derived from SKEYSEED_e; Integrity uses a > key derived from SKEYSEED_a. > > Either side may initiate a phase 2 exchange. A child-SA is created by > sending a CREATE_CHILD_SA request. If PFS for the child-SA is > desired, the CREAT_CHILD_SA request contains KE payloads for an > additional Diffie-Hellman exchange. The keying material for the > child_SA is a function of SKEYSEED_d established during the > establishment of the IKE-SA, the nonces exchanged during the > CREATE_CHILD_SA exchange, and the Diffie-Hellman value, if KE > payloads are included in the CREATE_CHILD_SA exchange. If the > Diffie-Hellman group for the child-SA is desired to be different from > the group for the IKE-SA, then a Diffie-Hellman group transform MUST > be included in the SA payload. If it is absent, the Diffie-Hellman > group is assumed to be the same as the one in the IKE-SA. > > > > The CREATE_CHILD_SA request contains: > > Initiator Responder > ----------- ----------- > HDR*, SA, Ni [, KEi ] > [, TRs] [, TRd] --> > > The Initiator sends SA offer(s) in the SA payload(s), a nonce in the > Ni payload, optionally a Diffie-Hellman value in the KE payload, and > the traffic restrictions in the TRs and TRd payloads. The message > past the header is encrypted and the message including the header is > integrity protected using the cryptographic algorithms negotiated in > Phase 1. > > The CREATE_CHILD_SA response contains: > > <-- HDR*, SA, Nr > [, KEr ] [, TRs] [, > TRd] > > The Responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, optionally a Diffie-Hellman value in > the KE payload, and the traffic restrictions for traffic to be sent > on that SA in the TR payloads, which may be a subset of what the > Initiator of the child-SA proposed. > >4.1 Generating Keying Material for Child-SAs > > Child-SAs are created either by being piggybacked on the phase 1 > exchange, or in a phase 2 CREATE_CHILD_SA exchange. Keying material > for them is generated as follows: > > KEYMAT = prf(SKEYSEED_d, protocol | SPId | Ns | Nd ) > > For phase 2 exchanges with PFS the keying material is defined as: > > KEYMAT = prf(SKEYSEED_d, g(p2)^ir | protocol | SPId | Ns | Nd ) > > where g(p2)^ir is the shared secret from the ephemeral Diffie-Hellman > exchange of this phase 2 exchange. > > In either case, "protocol", and "SPI", are from the SA payload that > contained the negotiated (and accepted) proposal, Ns is the body of > the Source's nonce payload (minus the generic header), and Nr is the > body of the Destination's nonce payload (minus the generic header). > > A single child-SA negotiation results in two security associations-- > one inbound and one outbound. Different Nonces and SPIs for each SA > (one chosen by the Initiator, the other by the Responder) guarantee a > different key for each direction. The SPI chosen by the destination > of the SA and the Nonces (ordered source followed by destination) are > used to derive KEYMAT for that SA. > > For situations where the amount of keying material desired is greater > than that supplied by the prf, KEYMAT is expanded by feeding the > results of the prf back into itself and concatenating results until > the required keying material has been reached. In other words, > > KEYMAT = K1 | K2 | K3 | ... > where: > K1 = prf(SKEYSEED_d, [ g(p2)^ir | ] protocol | SPId | Ns | Nd) > K2 = prf(SKEYSEED_d, K1 | [ g(p2)^ir | ] protocol | SPId | Ns | Nd) > K3 = prf(SKEYSEED_d, K2 | [ g(p2)^ir | ] protocol | SPId | Ns | Nd) > etc. > > This keying material (whether with PFS or without) MUST be used with > the negotiated SA. In the case of an ESP SA needing two keys for > encryption and authentication, the encryption key is taken from the > first bytes of KEYMAT and the authentication key is taken from the > next bytes. > >5 Informational (Phase 2) Exchange > > At various points during an IKE-SA, peers may desire to convey > control messages to each other regarding errors or notifications of > certain events. To accomplish this IKE defines a (reliable) > Informational exchange. Usually Informational exchanges happen > during phase 2 and are cryptographically protected with the IKE > exchange. > > Control messages that pertain to an IKE-SA MUST be sent under that > IKE-SA. Control messages that pertain to Child-SAs MUST be sent under > the protection of the IKE-SA which generated them. > > There are two cases in which there is no IKE-SA to protect the > information. One is in the response to an IKE_SA_init_request to > request a cookie or to refuse the SA proposal. This would be conveyed > in a Notify payload of the IKE_SA_init_response. > > The other case in which there is no IKE-SA to protect the information > is when a packet is received with an unknown SPI. (XXXwhat happens > if an ESP packet comes in with an unexpected source address, or > cryptographically invalidXXX). In that case the notification of this > condition will be sent in an informational exchange that is > cryptographically unprotected. > > Messages in an Informational Exchange contain zero or more > Notification or Delete payloads. The Recipient of an Informational > Exchange request MUST send some response (else the Sender will assume > the message was lost in the network and will retransmit it). That > response can be a message with no payloads. Actually, the request > message in an Informational Exchange can also contain no payloads. > This is the expected way an endpoint can ask the other endpoint to > verify that it is alive. > > ESP, AH, and IPcomp SAs always exist in pairs, with one SA in each > direction. When an SA is closed, both members of the pair MUST be > closed. When SAs are nested, as when data is encapsulated first with > IPcomp, then with ESP, and finally with AH between the same pair of > endpoints, all of the SAs (up to six) must be deleted together. To > delete an SA, an Informational Exchange with one or more delete > payloads is sent listing the SPIs (as known to the recipient) of the > SAs to be deleted. The recipient MUST close the designated SAs. > Normally, the reply in the Informational Exchange will contain delete > payloads for the paired SAs going in the other direction. There is > one exception. If by chance both ends of a set of SAs independently > decide to close them, each may send a delete payload and the two > requests may cross in the network. If a node receives a delete > request for SAs that it has already issued a delete request for, it > MUST delete the incoming SAs while processing the request and the > outgoing SAs while processing the response. In that case, the > responses MUST NOT include delete payloads for the deleted SAs, since > that would result in duplicate deletion and could in theory delete > the wrong SA. > > A node SHOULD regard half open connections as anomalous and audit > their existence should they persist. Note that this specification > nowhere specifies time periods, so it is up to individual endpoints > to decide how long to wait. A node MAY refuse to accept incoming data > on half open connections but MUST NOT unilaterally close them and > reuse the SPIs. If connection state becomes sufficiently messed up, a > node MAY close the IKE-SA which will implicitly close all SAs > negotiated under it. It can then rebuild the SA's it needs on a clean > base under a new IKE-SA. > > The Informational Exchange is defined as: > > Initiator Responder > ----------- ----------- > HDR*, N, ..., D, ... --> > <-- HDR*, N, ..., D, ... detail what the payloads N and D mean. > > The processing of an Informational Exchange is determined by its > component payloads. > >6 Error Handling > > There are many kinds of errors that can occur during IKE processing. > If a request is received that is badly formatted or unacceptable for > reasons of policy (e.g. no matching cryptographic algorithms), the > response MUST contain a Notify payload indicating the error. If an > error occurs outside the context of an IKE request (e.g. the node is > getting ESP messages on a non-existent SPI), the node SHOULD initiate > an Informational Exchange with a Notify payload describing the > problem. > > Errors that occur before a cryptographically protected IKE-SA is > established must be handled very carefully. There is a trade-off > between wanting to be helpful in diagnosing a problem and responding > to it and wanting to avoid being a dupe in a denial of service attack > based on forged messages. > > If a node receives a message on UDP port 500 outside the context of > an IKE-SA (and not a request to start one), it may be the result of a > recent crash. If the message is marked as a response, the node MAY > audit the suspicious event but MUST NOT respond. If the message is > marked as a request, the node MAY audit the suspicious event and MAY > send a response. If a response is sent, the response MUST be sent to > the IP address from whence it came with the IKE cookies reversed in > the header and the Message ID copied. The response MUST NOT be > cryptographically protected and MUST contain a notify payload > indicating the nature of the problem. > > A node receiving such a message MUST NOT respond and MUST NOT change > the state of any existing SAs. The message might be a forgery or > might be a response the genuine correspondent was tricked into > sending. A node SHOULD treat such a message (and also a network > message like ICMP destination unreachable) as a hint that there might > be problems with SAs to that IP address and SHOULD initiate a > liveness test for any such IKE-SA. An implementation SHOULD limit the > frequency of such tests to avoid being tricked into participating in > a denial of service attack. > > A node receiving a suspicious message from an IP address with which > it has an IKE-SA MAY send an IKE notify payload in an IKE > Informational exchange over that SA. The recipient MUST NOT change > the state of any SA's as a result but SHOULD audit the event to aid > in diagnosing malfunctions. A node MUST limit the rate at which it > will send messages in response to unprotected messages. It will also be useful to mandate the behavior for sending 'INVALID SPI' messages. I feel a node receiving an invalid spi SHOULD sent a notification (subject to rate limiting). This will help the sender do liveliness check for an ipsec SA. >7 Header and Payload Formats > >7.1 The IKE Header > > IKE messages use UDP port 500, with one IKE message per UDP datagram. > Information from the UDP header is largely ignored except that the IP > addresses from the headers are reversed and used for return packets. > Each IKE message begins with the IKE header, denoted HDR in this > memo. Following the header are one or more IKE payloads each > identified by a "Next Payload" field in the preceding payload. > Payloads are processed in the order in which they appear in an IKE > message by invoking the appropriate processing routine according to > the "Next Payload" field in the IKE header and subsequently according > to the "Next Payload" field in the IKE payload itself until a "Next > Payload" field of zero indicates that no payloads follow. > > The Recipient SPI in the header identifies an instance of an IKE > security association. It is therefore possible for a single instance > of IKE to multiplex distinct sessions with multiple peers. > > The format of the IKE header is shown in Figure X. > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Recipient ! > ! SPI (aka Cookie) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Sender ! > ! SPI (aka Cookie) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Message ID ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure X: IKE Header Format > > o Recipient SPI (aka Cookie) (8 bytes) - A value chosen by the > recipient to identify a unique IKE security association. > [NOTE: this is a deviation from ISAKMP and IKEv1, where the > cookies were always sent with the Initiator of the IKE-SA's > cookie first and the Responder's second. See section XXX.] > > o Sender SPI (aka Cookie) (8 bytes) - A value chosen by the > sender to identify a unique IKE security association. > > o Next Payload (1 byte) - Indicates the type of payload that > immediately follows the header. The format and value of each > payload is defined below. > You may want to list the payload types and their assigned values as in RFC2408. > o Major Version (4 bits) - indicates the major version of the IKE > protocol in use. Implementations based on this version of IKE > MUST set the Major Version to 2. Implementations based on > previous versions of IKE and ISAKMP MUST set the Major Version > to 1. Implementations based on this version of IKE MUST reject > (or ignore) messages containing a version number greater than > 2. > > o Minor Version (4 bits) - indicates the minor version of the > IKE protocol in use. Implementations based on this version of > IKE MUST set the Minor Version to 0. They MUST ignore the minor > version number of received messages. > > o Exchange Type (1 byte) - indicates the type of exchange being > used. This dictates the payloads sent in each message and > message orderings in the exchanges. > > Exchange Type Value > > RESERVED 0 > Informational 5 > Reserved for ISAKMP 1 - 4, 6 - 31 > Reserved for IKEv1 32 - 33 > IKE-SA-INIT 34 > IKE-AUTH 35 > CREATE-CHILD-SA 36 > Reserved for IKEv2+ 37-239 > Reserved for private use 240-255 > > o Flags (1 byte) - indicates specific options that are set for > the > message. Presence of options are indicated by the appropriate > bit > in the flags field being set. The bits are defined LSB first, > so > bit 0 would be the least significant bit of the Flags byte. > > -- E(ncryption) (bit 0 of Flags) - If set, all payloads > following the header are encrypted and integrity > protected using the algorithms negotiated during > session establishment and a key derived during the key > exchange portion of IKE. If not set, the payloads are > not protected. All payloads MUST be protected if a key > has been negotiated and any unprotected payload may > only be used to establish a new session or indicate a > problem. > > -- C(ommit) (bit 1 of Flags) - This bit is defined by > ISAKMP but not used by IKEv2. Implementations of IKEv2 > MUST clear this bit when sending and SHOULD ignore it > in incoming messages. > > -- A(uthentication Only) (bit 2 of Flags) - This bit is > defined by ISAKMP but not used by IKEv2. Implementations > of IKEv2 MUST clear this bit when sending and SHOULD > ignore it in incoming messages. > > -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in > messages sent by the Initiator of an exchange and MUST > be cleared in messages sent by the Responder. It is > used by the recipient to determine whether the message > number should be interpreted in the context of its > initiating state or its responding state. > > -- V(ersion) (bit 4 of Flags) - This bit indicates that > the transmitter is capable of speaking a higher major > version number of the protocol than the one indicated > in the major version number field. > What is the usefulness of this flag? Does it mean the transmitter always to start with IkeV1 and then move upto IkeV2? Also in IKEV1, this bit expected to be set to 0. Then how can the sender who is setting the V1 in major number, can indicate that he is capable of speaking a higher major version number? > -- R(eserved) (bits 5-7 of Flags) - These bit MUST be > cleared in messages sent and received messages with > these bits set MUST be rejected. > > o Message ID (4 bytes) - Message identifier used to control > retransmission of lost packets and matching of requests and > responses. See section 2.2. In the first message of a Phase 1 > negotiation, the value MUST be set to 0. The response to that > message MUST also have a Message ID of 0. > > o Length (4 bytes) - Length of total message (header + payloads) > in bytes. Session encryption can expand the size of an IKE > message and that is reflected in the total length of the > message. > >7.2 Generic Payload Header > > Each IKE payload defined in sections 7.3 through 7.13 begins with a > generic header, shown in Figure 3. Figures for each payload below > will include the generic payload header but for brevity a repeat of > the description of each field will be omitted. The construction and > processing of the generic payload header is identical for each > payload and will similarly be omitted. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Next Payload !C! RESERVED ! Payload Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 3: Generic Payload Header > > The Generic Payload Header fields are defined as follows: > > o Next Payload (1 byte) - Identifier for the payload type of the > next payload in the message. If the current payload is the last > in the message, then this field will be 0. This field provides > a "chaining" capability whereby additional payloads can be > added to a message by appending it to the end of the message > and setting the "Next Payload" field of the preceding payload > to indicate the new payload's type. > > o Critical (1 bit) - MUST be set to zero if the sender wants > the recipient to skip this payload if he does not > understand the payload type code. MUST be set to one if the > sender wants the recipient to reject this entire message > if he does not understand this payload type. MUST be ignored > by recipient if the recipient understands the payload type > code. MUST be set to zero for payload types defined in this > document. Note that the critical bit applies to the current > payload rather than the "next" payload whose type code > appears in the first byte. > > o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored. > > o Payload Length (2 bytes) - Length in bytes of the current > payload, including the generic payload header. > Attribute payload information missing. >7.3 Security Association Payload > > The Security Association Payload, denoted SA in this memo, is used to > negotiate attributes of a security association. Assembly of Security > Association Payloads requires great peace of mind. An SA may contain > multiple proposals. Each proposal may contain multiple protocols > (where a protocol is IKE, ESP, AH, or IPCOMP), each protocol may > contain multiple transforms, and each transform may contain multiple > attributes. When parsing an SA, an implementation MUST check that the > total Payload Length is consistent with the payload's internal > lengths and counts. Proposals, Transforms, and Attributes each have > their own variable length encodings. They are nested such that the > Payload Length of an SA includes the combined contents of the SA, > Proposal, Transform, and Attribute information. The length of a > Proposal includes the lengths of all Transforms and Attributes it > contains. The length of a Transform includes the lengths of all > Attributes it contains. > > The syntax of Security Associations, Proposals, Transforms, and > Attributes is based on ISAKMP, however the semantics are somewhat > different. The reason for the complexity and the hierarchy is to > allow for multiple possible combinations of algorithms to be encoded > in a single SA. Sometimes there is a choice of multiple algorithms, > while other times there is a combination of algorithms. For example, > an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR > (ESP w/MD5 and 3DES). > > One of the reasons the semantics of the SA payload has changed from > ISAKMP and IKEv1 is to make the encodings more compact in common > cases. > > The Proposal structure contains within it a Proposal # and a > Protocol-id. Each structure MUST have the same Proposal # as the > previous one or one greater. The first Proposal MUST have a Proposal > # of one. If two successive structures have the same Proposal number, > it means that the proposal consists of the first structure AND the > second. So a proposal of AH AND ESP would have two proposal > structures, one for AH and one for ESP and both would have Proposal > #1. A proposal of AH OR ESP would have two proposal structures, one > for AH with proposal #1 and one for ESP with proposal #2. > > Each Proposal/Protocol structure is followed by one or more transform > structures. The number of different transforms is generally > determined by the Protocol. AH generally has a single transform: an > integrity check algorithm. ESP generally has two: an encryption > algorithm AND an integrity check algorithm. IKE generally has four > transforms: a Diffie-Hellman group, an authentication algorithm, an > integrity check algorithm, and an encryption algorithm. For each > Protocol, the set of permissible transforms are assigned transform ID > numbers, which appear in the header of each transform. > > If there are multiple transforms with the same Transform #, the > proposal is an OR of those transforms. If there are multiple > Transforms with different Transform #s, the proposal is an AND of the > different groups. For example, to propose ESP with (3DES or IDEA) and > (HMAC-MD5 or HMAC-SHA), the ESP proposal would contain two Transform > #1 candidates (one for 3DES and one for IDEA) and two Transform #2 > candidates (one for HMAC-MD5 and one for HMAC-SHA). This effectively > proposes four combinations of algorithms. If the Initiator wanted to > propose only a subset of those - say (3DES and HMAC-MD5) or (IDEA and > HMAC-SHA), there is no way to encode that as multiple transforms > within a single Proposal/Protocol. Instead, the Initiator would have > to construct two different Proposals, each with two transforms. > > A given transform MAY have one or more Attributes. Attributes are > necessary when the transform can be used in more than one way, as > when an encryption algorithm has a variable key size. The transform > would specify the algorithm and the attribute would specify the key > size. Most transforms do not have attributes. > > Note that the semantics of Transforms and Attributes are quite > different than in IKEv1. In IKEv1, a single Transform carried > multiple algorithms for a protocol with one carried in the Transform > and the others carried in the Attributes. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Domain of Interpretation (1) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Situation (1) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: Security Association Payload > > > o Domain of Interpretation (4 bytes) - MUST contain the integer > value 1, indicating IPsec. Other values are reserved for > related protocols. An implementation of IKEv2 MUST supply a > value of 1, and MUST reject any SA payload containing any other > value. > > o Situation (4 bytes) - a four byte bitmask where for IKEv2 > the low order bit MUST be set ON and all other bits MUST be > set off. An implementation of IKEv2 MUST reject any SA payload > containing any value other than 1. > > *NOTE*: removed the SIT_SECRECY and SIT_INTEGRITY options. If > needed, we could put them back. > >7.3.1 Proposal Substructure > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! 0 (last) or 2 ! RESERVED ! Proposal Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Proposal # ! Protocol-Id ! SPI Size !# of Transforms! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ SPI (variable) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Transforms ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure XXX: Proposal Substructure > > o 0 (last) or 2 (more) (1 byte) - Specifies whether this is the > last Proposal Substructure in the SA. This syntax is inherited > from ISAKMP, but is unnecessary because the last Proposal > could be identified from the length of the SA. The value (2) > corresponds to a Payload Type of Proposal, and the first > four bytes of the Proposal structure are designed to look > somewhat like the header of a Payload. > > o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. > > o Proposal Length (2 bytes) - Length of this proposal, > including all transforms and attributes that follow. > > o Proposal # (1 byte) - When a proposal is made, the first > proposal in an SA MUST be #1, and subsequent proposals > MUST either be the same as the previous proposal (indicating > an AND of the two proposals) or one more than the previous > proposal (indicating an OR of the two proposals). When a > proposal is accepted, all of the proposal numbers in the > SA must be the same and must match the number on the > proposal sent that was accepted. > > o Protocol-Id (1 byte) - Specifies the protocol identifier > for the current negotiation. During phase 1 negotiation > this field MUST be zero (0). During phase 2 it will be the > protocol of the SA being established as assigned by IANA, > for example, 50 for ESP, 51 for AH, and 108 for IPComp. > > o SPI Size (1 byte) - During phase 1 negotiation this field > MUST be zero. During phase 2 negotiation it is equal to the > size, in bytes, of the SPI of the corresponding protocol > (4 for ESP and AH, 2 for IPcomp). > > o # of Transforms (1 byte) - Specifies the number of > transforms for this proposal (the total number, not the > highest transform #). > > o SPI (variable) - The sending entity's SPI. Even if the SPI > Size is not a multiple of 4 bytes, there is no padding > applied to the payload. When the SPI Size field is zero, > this field is not present in the Security Association > payload. This case occurs when negotiating the IKE-SA. > > o Proposal # (1 byte) - Identifies the immediate proposal. The > first proposal has the number of one (1) and each subsequent > proposal has a number which is one greater than the last. > > o Proposal Length (2 bytes) - Length in bytes of the proposal > including all SA Attributes. > > o SA Attributes (variable length) - This field contains SA > attributes for the immediate transform. The SA Attributes > MUST be represented using the Transform Attributes format > described below. > > o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. > >7.3.2 Transform Substructure > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! 0 (last) or 3 ! RESERVED ! Transform Length ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Transform # ! Transform-Id ! RESERVED2 ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Transform Attributes ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: Transform Substructure > > o 0 (last) or 3 (more) (1 byte) - Specifies whether this is the > last Transform Substructure in the Proposal. This syntax is > inherited from ISAKMP, but is unnecessary because the last > Proposal could be identified from the length of the SA. The > value (3) corresponds to a Payload Type of Transform, and > the first four bytes of the Transform structure are designed > to look somewhat like the header of a Payload. > > o RESERVED (1 byte) - MUST be sent as zero; MUST be ignored. > > o Transform Length - The length (in bytes) of the Transform > Substructure including Header and Attributes. > > o Transform # (1 byte) - The type of transform being specified > in this transform. Different protocols support different > transform types. For some protocols, some of the transforms > may be optional. > > Transform Number Values > > - Algorithm for: Trans# Used In > Encryption 1 (IKE and ESP) > Pseudo-random Function 2 (IKE, AH, and optional in ESP) > Authentication 3 (IKE) > Diffie-Hellman Group 4 (IKE and optional in AH and ESP) > Compression 5 (IPcomp) > > values 6-240 are reserved to IANA. Values 241-255 are for > private use among mutually consenting parties. > > For Transform #1 (Encryption), defined Transform-IDs are: > RESERVED 0 > ENCR_DES_IV64 1 > ENCR_DES 2 > ENCR_3DES 3 > ENCR_RC5 4 > ENCR_IDEA 5 > ENCR_CAST 6 > ENCR_BLOWFISH 7 > ENCR_3IDEA 8 > ENCR_DES_IV32 9 > ENCR_RC4 10 > ENCR_NULL 11 AES is missing. It already has been assigned a number - right? > > values 12-240 are reserved to IANA. Values 241-255 are for > private use among mutually consenting parties. > > For Transform #2 (Pseudo-random Function), defined Transform-IDs are: > > RESERVED 0 > PRF_HMAC_MD5 1 > PRF_HMAC_SHA 2 > PRF_DES_MAC 3 > PRF_KPDK_MD5 4 > > values 5-240 are reserved to IANA. Values 241-255 are for > private use among mutually consenting parties. > > For Transform #3 (Authentication), defined Transform-IDs are: > > RESERVED 0 > Methods in IKEv1 1 - 5 > Signed Diffie-Hellman 6 > > values 7-240 are reserved to IANA. Values 241-255 are for > private use among mutually consenting parties. > > For Transform #4 (Diffie-Hellman Group), defined Transform-IDs are: > > RESERVED 0 > Pre-defined (see section XXX) 1 - 5 > RESERVED 6 - 100 > MODP (exponentiation) 101 (w/attributes) > ECP (elliptic curve over GF[P] 102 (w/attributes) > EC2N (elliptic curve over GF[2^N]) 103 (w/attributes) > > values 6-100 and 104-240 are reserved to IANA. Values 241-255 > are for private use among mutually consenting parties. > > > For Transform #5 (Compression), defined Transform-IDs are: > > RESERVED 0 > IPCOMP_OUI 1 (w/attributes) > IPCOMP_DEFLATE 2 > IPCOMP_LZS 3 > > values 4-240 are reserved to IANA. Values 241-255 are for > private use among mutually consenting parties. > >7.3.3 Transform Attributes > > Each transform in a Security Association payload may include > attributes that modify or complete the specification of the > transform. These attributes are type/value pairs. (For example, if an > encryption algorithm has a variable length key, the key length to be > used may be specified as an attribute. Attributes can have a value > with a fixed two byte length or a variable length value. For the > latter the attribute is the form of type/length/value. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > !A! Attribute Type ! AF=0 Attribute Length ! > !F! ! AF=1 Attribute Value ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! AF=0 Attribute Value . > ! AF=1 Not Transmitted . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: Data Attributes > > o Attribute Type (2 bytes) - Unique identifier for each type of > attribute. The identifiers for IKE are defined in section X.Y. > > The most significant bit of this field is the Attribute Format > bit (AF). It indicates whether the data attributes follow the > Type/Length/Value (TLV) format or a shortened Type/Value (TV) > format. If the AF bit is zero (0), then the Data Attributes > are of the Type/Length/Value (TLV) form. If the AF bit is a > one (1), then the Data Attributes are of the Type/Value form. > > o Attribute Length (2 bytes) - Length in bytes of the Attribute > Value. When the AF bit is a one (1), the Attribute Value is > only 2 bytes and the Attribute Length field is not present. > > o Attribute Value (variable length) - Value of the Attribute > associated with the Attribute Type. If the AF bit is a > zero (0), this field has a variable length defined by the > Attribute Length field. If the AF bit is a one (1), the > Attribute Value has a length of 2 bytes. > >7.3.4 Attribute Negotiation > > During security association negotiation Initiators present offers, in > the form of protection suites, to Responders. Responders MUST select > a single complete set of parameters from the offers (or reject the > offers if none are acceptable). If there are multiple proposals, the > Responder MUST choose a single proposal and return all of the > Proposal substructures with that proposal number. For each protocol > in the accepted offer, the Responder MUST choose a single transform > of each transform type. Any attributes of a selected transform MUST > be returned unmodified. The Initiator of an exchange MUST check that > the accepted offer is consistent with one of its proposals, and if > not that response MUST be rejected. > > Negotiating Diffie-Hellman groups presents some special challenges. > Diffie-Hellman groups are specified either using a defined group > description (section 5) or by defining all attributes of a group (see > Appendix A) in an IKE policy offer. Group attributes, such as group > type or prime number MUST NOT be offered in conjunction with a > previously defined group. SA offers include proposed attributes and a > Diffie-Hellman public number (KE) in the same message. If the > Initiator offers to use one of several Diffie-Hellman groups, it > SHOULD pick the one the Responder is most likely to accept and > include a KE corresponding to that group. If the guess turns out to > be wrong, the Responder will indicate the correct group in the > response and the Initiator SHOULD start over this time guessing a > different group. The Initiator's other choice is to send the first > message without a KE field, which guarantees a rejection, but the > rejection will contain the identity of the group the Responder will > select. The above described scheme to negotiate DH groups seems complex. Can the negotiation of DH groups be furthur simplified? Is the restriction that phase1 negotiation can have only one proposal still valid? If we loosen that restriction than becomes to propose multiple DH groups as attributes of different proposals. > > Anticipating problems with this negotiation, the Responder MUST check > that the length of the KE payload corresponds to the size of the > Diffie-Hellman group the Responder selects and if not, the Responder > MUST send a Notify with an INVALID-KEY-INFORMATION or IKE-SA-INIT- > REJECT and indicate the Diffie-Hellman group selected. > > In the unlikely event that the Initiator proposes two different > Diffie-Hellman groups whose KE values are the same size, the > Responder may not be able to detect the incorrect guess and will > respond with a KE payload to complete the exchange. The Initiator, > however, MUST detect this case when examining the Responder's SA > payload and abort the connection setup. If this occurs during Phase > 1, the Initiator can simply retry with a new KE value. If it occurs > during Phase 2, the Initiator MUST delete the SA erroneously > established and establish a new one. > > Implementation Note: > > Certain negotiable attributes can have ranges or could have > multiple acceptable values. These are the Diffie-Hellman group and > the key length of a variable key length symmetric cipher. To > further interoperability and to support upgrading endpoints > independently, implementers of this protocol SHOULD accept values > which they deem to supply greater security. For instance if a peer > is configured to accept a certain MODP Diffie-Hellman group and is > offered a group which has a larger prime modulus an implementation > should accept this value. > >7.4 Key Exchange Payload > > The Key Exchange Payload, denoted KE in this memo, is used to > exchange Diffie-Hellman public numbers as part of a Diffie-Hellman > key exchange. The Key Exchange Payload consists of the IKE generic > header followed by the Diffie-Hellman public value itself. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Key Exchange Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 8: Key Exchange Payload Format > > A key exchange payload is constructed by copying one's Diffie-Hellman > public value into the "Key Exchange Data" portion of the payload. > The length of the Diffie-Hellman public value MUST be equal to the > length of the prime modulus over which the exponentiation was > performed, prepending zero bits to the value if necessary. > > A key exchange payload is processed by first checking whether the > length of the key exchange data (the "Payload Length" from the > generic header minus the size of the generic header) is equal to the > length of the prime modulus over which the exponentiation was > performed. > >7.5 Identification Payload > > The Identification Payload, denoted ID in this memo, allows peers to > identify themselves to each other. In Phase 1, the ID Payload names > the identity to be authenticated with the signature. In Phase 2, the > ID Payload is optional and if present names an identity asserted to > be responsible for this SA. An example use would be a shared computer > opening an IKE-SA to a server and asserting the name of its logged in > user for the Phase 2 SA. If missing, this defaults to the Phase 1 > identity. > > NOTE: In IKEv1, two ID payloads were used in each direction in Phase > 2 to hold Traffic Restriction information for data passing over the > SA. In IKEv2, this information is carried in Traffic Restriction (TR) > payloads (see section 7.13). > > The Identification Payload consists of the IKE generic header > followed by identification fields as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ID Type ! RESERVED | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Identification Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 9: Identification Payload Format > > o ID Type (1 byte) - Specifies the type of Identification being > used. > > o RESERVED - MUST be sent as zero; MUST be ignored. > > o Identification Data (variable length) - Value, as indicated by > the Identification Type. The length of the Identification Data > is computed from the size in the ID payload header. > > The payload type for the Identification Payload is five (5). > > The following table lists the assigned values for the Identification > Type field, followed by a description of the Identification Data > which follows: > > ID Type Value > ------- ----- > RESERVED 0 > > ID_IPV4_ADDR 1 > > A single four (4) byte IPv4 address. > > ID_FQDN 2 > > A fully-qualified domain name string. An example of a > ID_FQDN is, "lounge.org". The string MUST not contain any > terminators (e.g. NULL, CR, etc.). > > ID_USER_FQDN 3 > > A fully-qualified username string, An example of a > ID_USER_FQDN is, "lizard@lounge.org". The string MUST not > contain any terminators. > > ID_IPV6_ADDR 5 > > A single sixteen (16) byte IPv6 address. > > ID_DER_ASN1_DN 9 > > The binary DER encoding of an ASN.1 X.500 Distinguished Name > [X.501]. > > ID_DER_ASN1_GN 10 > > The binary DER encoding of an ASN.1 X.500 GeneralName > [X.509]. > > ID_KEY_ID 11 > > An opaque byte stream which may be used to pass vendor- > specific information necessary to do certain proprietary > forms of identification. > > > >7.6 Certificate Payload > > The Certificate Payload, denoted CERT in this memo, provides a means > to transport certificates or other certificate-related information > via IKE. Certificate payloads SHOULD be included in an exchange if > certificates are available to the sender. > > The Certificate Payload is defined as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Cert Encoding ! ! > +-+-+-+-+-+-+-+-+ ! > ~ Certificate Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 10: Certificate Payload Format > > o Certificate Encoding (1 byte) - This field indicates the type > of certificate or certificate-related information contained > in the Certificate Data field. > > Certificate Encoding Value > -------------------- ----- > NONE 0 > PKCS #7 wrapped X.509 certificate 1 > PGP Certificate 2 > DNS Signed Key 3 > X.509 Certificate - Signature 4 > X.509 Certificate - Key Exchange 5 > Kerberos Tokens 6 > Certificate Revocation List (CRL) 7 > Authority Revocation List (ARL) 8 > SPKI Certificate 9 > X.509 Certificate - Attribute 10 > RESERVED 11 - 255 > > o Certificate Data (variable length) - Actual encoding of > certificate data. The type of certificate is indicated > by the Certificate Encoding field. > > The payload type for the Certificate Payload is six (6). > >7.7 Certificate Request Payload > > The Certificate Request Payload, denoted CERTREQ in this memo, > provides a means to request preferred certificates via IKE and can > appear in the first, second, or third message of Phase 1. > Certificate Request payloads SHOULD be included in an exchange > whenever the peer may have multiple certificates, some of which might > be trusted while others are not. If multiple root CA's are trusted, > then multiple Certificate Request payloads SHOULD be transmitted. > > The Certificate Payload is defined as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Cert Encoding ! ! > +-+-+-+-+-+-+-+-+ ! > ~ Certification Authority ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 11: Certificate Request Payload Format > > o Certificate Encoding (1 byte) - Contains an encoding of the type > of certificate requested. Acceptable values are listed in > section 7.6. > > o Certification Authority (variable length) - Contains an encoding > of an acceptable certification authority for the type of > certificate requested. > > The payload type for the Certificate Request Payload is seven (7). > > The Certificate Request Payload is constructed by setting the "Cert > Encoding" field to be the type of certificate being desired and the > "Certification Authority" field to a proper encoding of a > certification authority for the specified certificate. For example, > for an X.509 certificate this field would contain the Distinguished > Name encoding of the Issuer Name of an X.509 certification authority > acceptable to the sender of this payload. > Can the above be made a MUST? ie: for X509 certs, certificate authority field MUST be the Distinguished name? If not what are the other valid values for this field? > The Certificate Request Payload is processed by inspecting the "Cert > Encoding" field to determine whether the processor has any > certificates of this type. If so the "Certification Authority" field > is inspected to determine if the processor has any certificates which > can be validated up to the specified certification authority. This > can be a chain of certificates. If a certificate exists which > satisfies the criteria specified in the Certificate Request Payload > it MUST be sent back to the certificate requestor; if a certificate > chain exists which goes back to the certification authority specified > in the request the entire chain MUST be sent back to the certificate > requestor. If no certificates exist then no further processing is The above sentence is a confusing. Sending certs is a MUST if they exist. What if the certs matching the criterion are not available? For example a sub-ca cert in the cert chain may not be available. Can the requestor make the assumption that the CERT.REQUEST will always be honored and get all the necessary peer certs (including sub-CAs) or SHOULD it make a best effort to get the relevant certificates > performed-- this is not an error condition of the protocol. > >7.8 Signature Payload > > The Signature Payload, denoted SIG in this memo, contains data > generated by a digital signature function and is used for > authentication purposes. > > The Signature Payload is defined as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Signature Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 13: Signature Payload Format > > o Signature Data (variable length) - Data that results from > applying the digital signature function to the ISAKMP message > and/or state. > > The payload type for the Signature Payload is nine (9). > > The Signature Payload is constructed by computing a digital signature > over some exchange specific information and placing the result in the > "Signature Data" portion of the payload. The payload length is the > size of the generic header plus the size of the "Signature Data" > portion of the payload which depends on the specific digital > signature algorithm being used. > > The Signature Payload is processed by extracting the "Signature Data" > from the payload and verifying it according to the specific digital > signature algorithm being used. If the signature is not verified a > NOTIFY Error message of INVALID-SIGNATURE MUST be sent back to the > peer and the connection closed. > >7.9 Nonce Payload > > The Nonce Payload, denoted Ni and Nr in this memo for the Initiator's > and Responder's nonce respectively, contains random data used to > guarantee liveness during an exchange and protect against replay > attacks. > > The Nonce Payload is defined as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Nonce Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: Nonce Payload Format > > o Nonce Data (variable length) - Contains the random data generated > by the transmitting entity. > > The payload type for the Nonce Payload is ten (10). > > The Nonce Payload is constructed by computing a pseudo-random value > and copying it into the "Nonce Data" field. The size of a Nonce in > this memo must be between eight (8) and two-hundred fifty-six (256) > bytes inclusive. > >7.10 Notify Payload > > The Notify Payload, denoted NOTIFY in this memo, is used to transmit > informational data, such as error conditions and state transitions to > an IKE peer. A Notify Payload may appear in a response message > (usually specifying why a request was rejected), or in an > Informational Exchange (to report an error not in an IKE request). > > The Notify Payload is defined as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Domain of Interpretation (DOI) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Protocol-ID ! SPI Size ! Notify Message Type ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Security Parameter Index (SPI) ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Notification Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 15: Notification Payload Format > > o Domain of Interpretation (4 bytes) - Identifies the DOI under > which this notification is taking place. MUST be set to 1. > Messages with any other value MUST be rejected. > > o Protocol-Id (1 byte) - Specifies the protocol about which > this notification is being sent. For phase 1 notifications, > this field MUST be zero (0). For phase 2 notifications > concerning IPsec SAs this field will contain an IPsec > protocol (either ESP, AH, or IPcomp). For notifications > for which no protocol ID is relevant, this field MUST be > sent as zero and MUST be ignored. > > o SPI Size (1 byte) - Length in bytes of the SPI as defined by > the Protocol-Id or zero if no SPI is applicable. For phase 1 > notification concerning the IKE-SA, the SPI Size MUST be zero. > > o Notify Message Type (2 bytes) - Specifies the type of > notification message. > > o SPI (variable length) - Security Parameter Index. > > o Notification Data (variable length) - Informational or error data > transmitted in addition to the Notify Message Type. Values for > this field are message specific, see below. > > The payload type for the Notification Payload is eleven (11). > >7.10.1 Notify Message Types > > Notification information can be error messages specifying why an SA > could not be established. It can also be status data that a process > managing an SA database wishes to communicate with a peer process. > For example, a secure front end or security gateway may use the > Notify message to synchronize SA communication. The table below > lists the Notification messages and their corresponding values. > Description of notification message values very useful. Description of some notification types missing. > NOTIFY MESSAGES - ERROR TYPES Value > ----------------------------- ----- > INVALID-PAYLOAD-TYPE 1 > > Only sent if the payload has the "critical" bit set. > Notification Data contains the one byte payload type. > > DOI-NOT-SUPPORTED 2 > > Notification Data contains the invalid DOI. > > INVALID-COOKIE 4 > > Indicates an IKE message was received with an unrecognized > destination cookie. This usually indicates that the > recipient has rebooted and forgotten the existence of an > IKE-SA. > > INVALID-MAJOR-VERSION 5 > > Indicates the recipient cannot handle the version of IKE > specified in the header. The closest version number that the > recipient can support will be in the reply header. > > INVALID-EXCHANGE-TYPE 7 > > Notification Data contains the one byte Exchange Type. > What about 'INVALID-MINOR-VERSION'? Is it not applicable for IKEV2? > INVALID-FLAGS 8 > > Notification Data contains one byte with the unacceptable > flag bits set. > > INVALID-MESSAGE-ID 9 > > Sent when either an IKE MESSAGE-ID more that ten greater ^^^^ typo > than the highest acknowledged MESSAGE-ID. This Notify MUST > NOT be sent in a response; the invalid request MUST NOT be > acknowledged. Instead, inform the other side by initiating > an Informational exchange with Notification data containing > the four byte invalid MESSAGE-ID. > > INVALID-PROTOCOL-ID 10 > > Notification Data contains the one byte invalid protocol ID. > > INVALID-SPI 11 > > MAY be sent in an IKE Informational Exchange when a node > receives an ESP or AH packet with an invalid SPI. address > as the source address in the invalid packet. This usually > indicates a node has rebooted and forgotten an SA. This > Informational Message is sent outside the context of an > IKE-SA, and therefore should only be used by the recipient > as a "hint" that something might be wrong (because it could > easily be forged). > > INVALID-TRANSFORM-ID 12 > > Notification Data contains the one byte invalid transform > ID. > > ATTRIBUTES-NOT-SUPPORTED 13 > > The "Notification Data" for this type are the attribute or > attributes that are not supported. > > NO-PROPOSAL-CHOSEN 14 > > BAD-PROPOSAL-SYNTAX 15 > > PAYLOAD-MALFORMED 16 > > INVALID-KEY-INFORMATION 17 > > The KE field is the wrong length. This can occur where there > is no error if the Initiator guesses incorrectly which > Diffie-Hellman group the Responder will accept. > Notification data contains the Transform Substructure > describing the chosen Diffie-Hellman group. > > INVALID-ID-INFORMATION 18 > > INVALID-CERT-ENCODING 19 > > The "Notification Data" for this type are the "Cert > Encoding" field from a Certificate Payload or Certificate > Request Payload. > > INVALID-CERTIFICATE 20 > > The "Notification Data" for this type are the "Certificate > Data" field from a Certificate Payload. When is this notification payload expected to be sent? It is not described in rfc2408 as well. Should it be treated in the same manner as INVALID-CERT-ENCODING? > > CERT-TYPE-UNSUPPORTED 21 > > This is identical to the INVALID-CERT-ENCODING error. > > INVALID-CERT-AUTHORITY 22 > > The "Notification Data" for this type are the "Cert > Encoding" field from a Certificate Payload or Certificate > Request Payload. > > AUTHENTICATION-FAILED 24 > > INVALID-SIGNATURE 25 > > ADDRESS-NOTIFICATION 26 > > Don't understand. > > UNSUPPORTED-EXCHANGE-TYPE 29 > > The "Notification Data" for this type are the Exchange Type > field from the IKE header. > > UNEQUAL-PAYLOAD-LENGTHS 30 > > The "Notification Data" for this type are the entire message > in which the unequal lengths were observed. Receipt of this > notify MAY be logged for debugging purposes. What is the use of the above message? When is it expected to be used? I have never seen it getting used. > > UNSUPPORTED-NOTIFY-TYPE 31 > > The "Notification Data" for this type is the two byte Notify > Type that was not supported. > > IKE-SA-INIT-REJECT 32 > > This notification is sent in an IKE-SA-RESPONSE to request > that the Initiator retry the request with the supplied > cookie (and optionally the supplied Diffie-Hellman group. > This is not really an error, but is processed like one in > that it indicates that the connection request was rejected. > The Notification Data, if present, contains the Transform > Substructure describing the chosen Diffie-Hellman group. > > INVALID-KE-PAYLOAD 33 > > This error indicates that the KE payload does not match the > chosen Diffie-Hellman group. It can occur legitimately in > either Phase 1 or Phase 2 if the Initiator supports multiple > Diffie-Hellman groups and incorrectly anticipates which one > the Responder will choose. > > SINGLE-PAIR-REQUIRED 34 > > This error indicates that a Phase 2 SA request is > unacceptable because the Responder requires a separate SA > for each source / destination address pair. The Initiator is > expected to respond by requesting an SA for only the > specific traffic he is trying to forward. > > RESERVED - Errors 34 - 8191 > > Private Use - Errors 8192 - 16383 > > > > NOTIFY MESSAGES - STATUS TYPES Value > ------------------------------ ----- > > RESERVED 16384 - 24577 > > INITIAL-CONTACT 24578 > > This notification indicates that this IKE-SA is the only > IKE-SA currently active between the authenticated > identities. It MAY be sent when an IKE-SA is established > after a crash, and the recipient MAY use this information to > delete any other IKE-SA's it has to the same authenticated > identity without waiting for a timeout. This notification > MUST NOT be sent by an entity that may be replicated (e.g. a > roaming user's credentials where the user is allowed to > connect to the corporate firewall from two remote systems at > the same time). > > RESERVED 24578 - 40959 > > Private Use - STATUS 40960 - 65535 > > >7.11 Delete Payload > > The Delete Payload, denoted DEL in this memo, contains a protocol- > specific security association identifier that the sender has removed > from its security association database and is, therefore, no longer > valid. Figure 16 shows the format of the Delete Payload. It is > possible to send multiple SPIs in a Delete payload, however, each SPI > MUST be for the same protocol. Mixing of Protocol Identifiers MUST > NOT be performed with the Delete payload. It is permitted, however, > to include multiple Delete payloads in a single Informational > Exchange where each Delete payload lists SPIs for a different > protocol. > > Deletion of the IKE-SA is indicated by a Protocol-Id of 0 (IKE) but > no SPIs. Deletion which is concerned with a Child-SA, such as ESP or > AH, will contain the Protocol-Id of that protocol (e.g. ESP, AH) and > the SPI is the receiving entity's SPI(s). > > NOTE: What's the deal with IPcomp SAs. This mechanism is probably not > appropriate for deleting them!! > > The Delete Payload is defined as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Domain of Interpretation (DOI) ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Protocol-Id ! SPI Size ! # of SPIs ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Security Parameter Index(es) (SPI) ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 16: Delete Payload Format > > o Domain of Interpretation (4 bytes) - MUST be sent as one (1); > MUST be treated as an error if any other value is received. > > o Protocol-Id (1 byte) - Must be zero for an IKE-SA, [] for > ESP, [] for AH, and [] for IPcomp. > > o SPI Size (1 byte) - Length in bytes of the SPI as defined by > the Protocol-Id. Zero for IKE (SPI is in message header), > four for AH and ESP, two for IPcomp. > > o # of SPIs (2 bytes) - The number of SPIs contained in the Delete > payload. The size of each SPI is defined by the SPI Size field. > > o Security Parameter Index(es) (variable length) - Identifies the > specific security association(s) to delete. > The length of this field is > determined by the SPI Size and # of SPIs fields. > > The payload type for the Delete Payload is twelve (12). > >7.12 Vendor ID Payload > > The Vendor ID Payload contains a vendor defined constant. The > constant is used by vendors to identify and recognize remote > instances of their implementations. This mechanism allows a vendor > to experiment with new features while maintaining backwards > compatibility. > > The Vendor ID payload is not an announcement from the sender that it > will send private payload types but rather an announcement of the > sort of private payloads it is willing to accept. The implementation > sending the Vendor ID MUST not make any assumptions about private > payloads that it may send unless a Vendor ID of like stature is > received as well. Multiple Vendor ID payloads MAY be sent. An > implementation is NOT REQUIRED to send any Vendor ID payload at all. > > A Vendor ID payload may be sent as part of any message. Reception of > a familiar Vendor ID payload allows an implementation to make use of > Private USE numbers described throughout this memo-- private > payloads, private exchanges, private notifications, etc. Unfamiliar > Vendor ID's MUST be ignored. > > Writers of Internet-Drafts who wish to extend this protocol MUST > define a Vendor ID payload to announce the ability to implement the > extension in the Internet-Draft. It is expected that Internet-Drafts > which gain acceptance and are standardized will be given "magic > numbers" out of the Future Use range by IANA and the requirement to > use a Vendor ID will go away. > > The Vendor ID Payload fields are defined as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Vendor ID (VID) ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 17: Vendor ID Payload Format > > o Vendor ID (variable length) - It is the responsibility of > the person choosing the Vendor ID to assure its uniqueness > in spite of the absence of any central registry for IDs. > Good practice is to include a company name, a person name > or some such. If you want to show off, you might include > the latitude and longitude and time where you were when > you chose the ID and some random input. A message digest > of a long unique string is preferable to the long unique > string itself. > > The payload type for the Vendor ID Payload is thirteen (13). > > >7.13 Traffic Restriction Payload > > The Traffic Restriction Payload, denoted TR in this memo, allows > peers to identify packet flows for processing by IPsec security > services. The Traffic Restriction Payload consists of the IKE generic > header followed by restriction information fields as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Payload Header ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! Rest. Type !D! RESERVED ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ! ! > ~ Traffic Restriction Data ~ > ! ! > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 9: Traffic Restriction Payload Format > > o Restriction Type (1 byte) - Specifies the type of Restriction > being asserted. > > o Direction Bit - If 0, this restriction applies to traffic > originating at the Initiator of the SA; if 1, this restriction > applies to traffic originating at the Responder. > > o RESERVED - This field MUST be sent as zero and MUST be ignored. > > o Restriction Data (variable length) - Value, as indicated by > the Traffic Restriction Type. > > The length of the Traffic Restriction Data is computed from the > payload length. The Traffic Restriction Data may contain more than > one of its specified type (e.g. Multiple IPv4 Addresses, Multiple > IPv6 Address subnets, etc). An implementation MUST be capable of > generating and accepting SA request with four TR payloads: An address > type and a protocol type for each of Initiator and Responder. An > implementation SHOULD be capable of accepting all of the Traffic > Restriction Types defined below. An implementation MUST return a > Notify of type SINGLE-PAIR-REQUIRED on receipt of a request for an SA > with a set of restrictions that it can't handle. > The payload type for the Identification Payload is five (5). Can one of the data in the specified id types be zero? If so it will be useful to the semantic can be specified(to avoid confusion). Otherwise mandate against the use of zero values. > > The following table lists the assigned values for the Traffic > Restriction Type field and the corresponding Restriction Data. > > TR Type Value > ------- ----- > RESERVED 0 > > TR_IPV4_ADDR 1 > > Four (4) byte IPv4 addresses > > TR_IPV4_ADDR_SUBNET 4 > > Subnets of IPv4 addresses, each represented by a pair of > four (4) byte values. The first value is an IPv4 address. > The second is an IPv4 network mask. Note that ones (1s) in > the network mask indicate that the corresponding bit in the > address is fixed, while zeros (0s) indicate a "wildcard" > bit. > > TR_IPV6_ADDR 5 > > Sixteen (16) byte IPv6 addresses > > TR_IPV6_ADDR_SUBNET 6 > > Subnets of IPv6 addresses, each represented by a pair > sixteen (16) byte values. The first value is an IPv6 > address. The second is an IPv6 network mask. Note that > ones (1s) in the network mask indicate that the > corresponding bit in the address is fixed, while zeros (0s) > indicate a "wildcard" bit. > > TR_IPV4_ADDR_RANGE 7 > > Ranges of IPv4 addresses, each represented by two four (4) > byte values. The first value is the beginning IPv4 address > (inclusive) and the second value is the ending IPv4 address > (inclusive). All addresses falling between the two > specified addresses are considered to be within the list. > > TR_IPV6_ADDR_RANGE 8 > > > TR_PROTOCOL_ID 12 > > A one byte IP protocol ID (usually TCP () or UDP ()) > followed by zero or more pairs of two byte port IDs. > Traffic is only permitted on the specified protocol using a > port in one of the ranges bounded by a pair of port IDs (if > no pairs of port IDs are supplied, all ports are allowed). > Can one of the pair of two byte port IDs be zero? If so what does it mean? > >8 Diffie-Hellman Groups > > There are 5 groups different Diffie-Hellman groups defined for use in > IKE. These groups were generated by Richard Schroeppel at the > University of Arizona. Properties of these primes are described in > [Orm96]. > > The strength supplied by group one may not be sufficient for the > mandatory-to-implement encryption algorithm and is here for historic > reasons. > >8.1 First Group > > IKE implementations MAY support a MODP group with the following prime > and generator. This group is assigned id 1 (one). > > The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } > Its hexadecimal value is > > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 > 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B > 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 > A63A3620 FFFFFFFF FFFFFFFF > > The generator is: 2. > >8.2 Second Group > > IKE implementations MUST support a MODP group with the following > prime and generator. This group is assigned id 2 (two). > > The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. > Its hexadecimal value is > > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 > 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B > 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 > A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 > 49286651 ECE65381 FFFFFFFF FFFFFFFF > > The generator is 2 (decimal) > >8.3 Third Group > > IKE implementations SHOULD support a EC2N group with the following > characteristics. This group is assigned id 3 (three). The curve is > based on the Galois Field GF[2^155]. The field size is 155. The > irreducible polynomial for the field is: > u^155 + u^62 + 1. > The equation for the elliptic curve is: > y^2 + xy = x^3 + ax^2 + b. > > Field Size: 155 > Group Prime/Irreducible Polynomial: > 0x0800000000000000000000004000000000000001 > Group Generator One: 0x7b > Group Curve A: 0x0 > Group Curve B: 0x07338f > Group Order: 0x0800000000000000000057db5698537193aef944 > > The data in the KE payload when using this group is the value x from > the solution (x,y), the point on the curve chosen by taking the > randomly chosen secret Ka and computing Ka*P, where * is the > repetition of the group addition and double operations, P is the > curve point with x coordinate equal to generator 1 and the y > coordinate determined from the defining equation. The equation of > curve is implicitly known by the Group Type and the A and B > coefficients. There are two possible values for the y coordinate; > either one can be used successfully (the two parties need not agree > on the selection). > >8.4 Fourth Group > > IKE implementations SHOULD support a EC2N group with the following > characteristics. This group is assigned id 4 (four). The curve is > based on the Galois Field GF[2^185]. The field size is 185. The > irreducible polynomial for the field is: > u^185 + u^69 + 1. > The equation for the elliptic curve is: > y^2 + xy = x^3 + ax^2 + b. > > Field Size: 185 > Group Prime/Irreducible Polynomial: > 0x020000000000000000000000000000200000000000000001 > Group Generator One: 0x18 > Group Curve A: 0x0 > Group Curve B: 0x1ee9 > Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc > > The data in the KE payload when using this group will be identical to > that as when using Oakley Group 3 (three). > >8.5 Fifth Group > > IKE implementations SHOULD support a MODP group with the following > prime and generator. This group is assigned id 5 (five). > > The prime is 2^1536 - 2^1472 - 1 + 2^64 * {[2^1406 pi] + 741804}. > Its hexadecimal value is > > FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 > 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B > 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 > A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 > 49286651 ECE45B3D C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 > FD24CF5F 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D > 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF > > The generator is 2. > > >9 Security Considerations > > Repeated re-keying using Phase 2 without PFS can consume the entropy > of the Diffie-Hellman shared secret. Implementers should take note of > this fact and set a limit on Phase 2 Exchanges between > exponentiations. This memo does not prescribe such a limit. > > The strength of a key derived from a Diffie-Hellman exchange using > any of the groups defined here depends on the inherent strength of > the group, the size of the exponent used, and the entropy provided by > the random number generator used. Due to these inputs it is difficult > to determine the strength of a key for any of the defined groups. The > default Diffie-Hellman group (number two) when used with a strong > random number generator and an exponent no less than 160 bits is > sufficient to use for 3DES. Groups three through five provide > greater security. Group one is for historic purposes only and does > not provide sufficient strength to the required cipher (although it > is sufficient for use with DES, which is also for historic use only). > Implementations should make note of these conservative estimates when > establishing policy and negotiating security parameters. > > Note that these limitations are on the Diffie-Hellman groups > themselves. There is nothing in IKE which prohibits using stronger > groups nor is there anything which will dilute the strength obtained > from stronger groups. In fact, the extensible framework of IKE > encourages the definition of more groups; use of elliptical curve > groups will greatly increase strength using much smaller numbers. > > It is assumed that the Diffie-Hellman exponents in this exchange are > erased from memory after use. In particular, these exponents must not > be derived from long-lived secrets like the seed to a pseudo-random > generator. > >10 IANA Considerations > > This document contains many "magic numbers" to be maintained by the > IANA. This section explains the criteria to be used by the IANA to > assign additional numbers in each of these lists. > >10.1 Attribute Classes > > Attributes negotiated in this protocol are identified by their class. > Requests for assignment of new classes must be accompanied by a > standards-track RFC which describes the use of this attribute. > >10.2 Encryption Algorithm Class > > Values of the Encryption Algorithm Class define an encryption > algorithm to use when called for in this document. Requests for > assignment of new encryption algorithm values must be accompanied by > a reference to a standards-track or Informational RFC or a reference > to published cryptographic literature which describes this algorithm. > >10.3 Hash Algorithm > > Values of the Hash Algorithm Class define a hash algorithm to use > when called for in this document. Requests for assignment of new hash > algorithm values must be accompanied by a reference to a standards- > track or Informational RFC or a reference to published cryptographic > literature which describes this algorithm. Due to the key derivation > and key expansion uses of HMAC forms of hash algorithms in IKE, > requests for assignment of new hash algorithm values must take into > account the cryptographic properties-- e.g it's resistance to > collision-- of the hash algorithm itself. > >10.4 Group Description and Group Type > > Values of the Group Description Class identify a group to use in a > Diffie-Hellman exchange. Values of the Group Type Class define the > type of group. Requests for assignment of new groups must be > accompanied by a reference to a standards-track or Informational RFC > which describes this group. Requests for assignment of new group > types must be accompanied by a reference to a standards-track or > Informational RFC or by a reference to published cryptographic or > mathematical literature which describes the new type. > >10.5 Life Type > > Values of the Life Type Class define a type of lifetime to which the > ISAKMP Security Association applies. Requests for assignment of new > life types must be accompanied by a detailed description of the units > of this type and its expiry. In section 2.4 it was described that in IKEV2 there is no need to negotiate lifetimes. Does it mean Lifetypes and lifetimes are not meaningful in IKEV2? If so it should be called out explicitly. > > > ... lines deleted ... > > > >Appendix A > > Attribute Assigned Numbers > > Attributes negotiated during phase one use the following definitions. > Phase two attributes are defined in the applicable DOI specification > (for example, IPsec attributes are defined in the IPsec DOI), with > the exception of a group description when Quick Mode includes an > ephemeral Diffie-Hellman exchange. Attribute types can be either > Basic (B) or Variable-length (V). Encoding of these attributes is > defined in [MSST98] as Type/Value (Basic) and Type/Length/Value > (Variable). > > Attributes described as basic MUST NOT be encoded as variable. > Variable length attributes MUST NOT be encoded as basic even if > their value can fit into two bytes. NOTE: This is a change from > IKEv1, where increased flexibility may have simplified the composer > of messages but certainly complicated the parser. > > Attribute Classes > > class value type > -------------------------------------------------------------- > Encryption Algorithm 1 B > Hash Algorithm 2 B > Authentication Method 3 B > Group Description 4 B > Group Type 5 B > Group Prime/Irreducible Polynomial 6 V > Group Generator One 7 V > Group Generator Two 8 V > Group Curve A 9 V > Group Curve B 10 V > Life Type 11 B > Life Duration 12 V > Key Length 14 B > Field Size 15 B > Group Order 16 V > Block Size 17 B > > values 13, and 18-16383 are reserved to IANA. Values 16384-32767 are > for private use among mutually consenting parties. > Description of some of the Attribute classes are missing. > - Key Length > > When using an Encryption Algorithm that has a variable length key, > this attribute specifies the key length in bits. (MUST use network > byte order). This attribute MUST NOT be used when the specified > Encryption Algorithm uses a fixed length key. > > - Field Size > > The field size, in bits, of a Diffie-Hellman group. > > - Group Order > > The group order of an elliptical curve group. Note the length of > this attribute depends on the field size. > > - Block Size > > The number of bits per block of a cipher with a variable block > length. > > Additional Exchanges Defined-- XCHG values > > Phase 2 32 > Informational 33 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Appendix B: Cryptographic Protection of IKE Data > > With the exception of the IKE-SA-INIT-REQUEST, IKE-SA-INIT-RESPONSE, > and Informational Exchange error notifications when no IKE-SA exists, > all IKE messages are encrypted and integrity protected. The > algorithms for encryption and integrity protection are negotiated > during IKE-SA setup, and the keys are computed as specified in > section XXX. > > The encryption and integrity protection algorithms are the same as > those available to the ESP protocol, through their application is > slightly different. Whereas in ESP the header that is integrity > protected but not encrypted is a total of 8 bytes (SPI+Sequence #), > in IKE it is the 28 byte IKE Header (see section 6.1). IKE header is 20 bytes. Are u including the IV also? Then for ESP should it not be 16 bytes (SPI+Seq # +IV) > > All other aspects of cryptographic processing (including IV > insertion, padding, and key derivation) are as specified in [ESP] and > its supporting algorithm documents. The Next Header byte in the > encrypted ESP payload MUST be set to zero. Does it mean explicit IV to be used as in ESP? > > NOTE: This is a change from IKEv1, which along with its companion > specifications defined its own algorithms for padding, encryption, > and integrity protection and its own codes for cryptographic > algorithms. Since most IKE implementations will also include ESP > implementations, this alternative was thought to simplify both the > specification and the implementation, as well as limit the number of > techniques in need of analysis for soundness. > > In some circumstances SKEYSEED_e may not be long enough to supply all > the necessary keying material an algorithm requires. In this case the > key is derived from feeding the results of the prf into itself, > concatenating the results and taking the highest necessary bits. > > Consider a fictitious cipher AKULA which requires 320 bits of key and > the prf used to generate SKEYSEED_e only generates 120 bits of > material. The key for AKULA would be the first 320 bits of Ka where: > > Ka = K1 | K2 | K3 > > and > > K1 = prf(SKEYSEED_e, 0) > K2 = prf(SKEYSEED_e, K1) > K3 = prf(SKEYSEED_e, K2) > > where 0 is represented by a single byte. Each result of the prf > provides 120 bits of material for a total of 360 bits. AKULA would > use the first 320 bits of that 360 bit string. > > Support for algorithms other than 3DES-CBC is purely optional. Some > optional algorithms may be subject to intellectual property claims. > >Authors' Addresses > >Dan Harkins > > >Charlie Kaufman ckaufman@iris.com IBM > > >Radia Perlman radia.perlman@sun.com Sun Microsystems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of > dharkins@tibernian.com > Sent: Saturday, November 17, 2001 11:11 PM > To: ipsec@lists.tislabs.com > Subject: IKEv2 (son-of-ike) draft > > > This draft was submitted but hasn't shown up yet in the repository > (the I-D editor is, no doubt, swamped) so in the interest of giving > people more time to look at it prior to Salt Lake here's a link: > > http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt > > Please send comments to the list. > > Dan. > > From owner-ipsec@lists.tislabs.com Wed Nov 21 09:51:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALHpW810837; Wed, 21 Nov 2001 09:51:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA16175 Wed, 21 Nov 2001 11:59:00 -0500 (EST) Date: Wed, 21 Nov 2001 12:07:21 -0500 (EST) From: Henry Spencer To: Derek Atkins cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 21 Nov 2001, Derek Atkins wrote: > > So *pick one*. Just because there are ten different ways of doing it > > doesn't mean you have to support all ten, or stand there frozen because > > you're unable to make up your mind. > > Right, and implementation A picks method X, and implementation B picks > method Y, and implementation C picks method Z, which makes sharing > keys a huge hastle. Uh, no, you miss the point -- this discussion is about a new standard, remember. A new standard can pick one and say "do it *THAT* way, and no other". Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 21 09:53:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALHr1810879; Wed, 21 Nov 2001 09:53:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16210 Wed, 21 Nov 2001 12:04:31 -0500 (EST) To: Henry Spencer Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft References: From: Derek Atkins Date: 21 Nov 2001 12:13:24 -0500 In-Reply-To: Henry Spencer's message of "Wed, 21 Nov 2001 12:07:21 -0500 (EST)" Message-ID: Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > Uh, no, you miss the point -- this discussion is about a new standard, > remember. A new standard can pick one and say "do it *THAT* way, and > no other". Ahh, I did misunderstand. I thought you meant "pick one" for an implementor, not for the spec. Yes, the spec should pick one (or two) and say "implement these". I would say X.509 and PGP :) > Henry Spencer > henry@spsystems.net -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 21 14:07:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALM79823992; Wed, 21 Nov 2001 14:07:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16841 Wed, 21 Nov 2001 16:09:27 -0500 (EST) Date: Wed, 21 Nov 2001 13:18:17 -0800 (PST) From: Jan Vilhuber To: Henry Spencer cc: Derek Atkins , ipsec@lists.tislabs.com Subject: Re: IKEv2 (son-of-ike) draft In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I don't suppose we could get this WG to pick one as a MUST... jan On Wed, 21 Nov 2001, Henry Spencer wrote: > On 21 Nov 2001, Derek Atkins wrote: > > > ...and now we can't get rid of it and even have group-keys. Gah! What's so > > > hard about configuring an RSA key? > > > > Lack of a standard way of doing it... Do you use raw RSA N/e, PGP key > > format, X.509 format? If a certificate format (PGP/X.509/etc) what > > signatures are required, if any? IKE doesn't specify any of this, and > > quite frankly a number of implementations do it differently. > > So *pick one*. Just because there are ten different ways of doing it > doesn't mean you have to support all ten, or stand there frozen because > you're unable to make up your mind. > > Henry Spencer > henry@spsystems.net > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Wed Nov 21 14:13:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALMDE824670; Wed, 21 Nov 2001 14:13:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA16849 Wed, 21 Nov 2001 16:12:07 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15356.6437.208148.92112@thomasm-u1.cisco.com> Date: Wed, 21 Nov 2001 13:14:13 -0800 (PST) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15354.32876.87395.582187@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Tue, 20 Nov 2001, Michael Thomas wrote: > > ...In the particular example given, if my > > national identity smart card gave away all sorts > > of private information to any merchant who asked, > > why should I have any belief that that information > > will remain private? > > Do you expect that your credit-card numbers will remain private, even > though you give them to any merchant you deal with? Sure you do! You > may not bet your life on it, but you do bet your credit rating on it. Actually, I don't. Credit cards are completely insecure and the only reason that I use them is that the credit card company is willing to take the hit for fraud, not me. > Remember, also, that a particular certificate isn't necessarily used to > authenticate you to *anyone who asks*. It may be used only for quite > restricted purposes, e.g. to get you through a corporate firewall. The > expectation of privacy is quite legitimately rather higher in that case. In the particular example given, this distinction didn't amount to much. Other situations might differ, obviously, but considering that you can't tell a priori who's demanding your credentials (cf Radia's post), it seems pretty risky to give out private data to an unauthenticated party. Mike From owner-ipsec@lists.tislabs.com Wed Nov 21 15:32:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fALNWN800186; Wed, 21 Nov 2001 15:32:23 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16978 Wed, 21 Nov 2001 17:37:03 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15356.11908.141636.804339@thomasm-u1.cisco.com> Date: Wed, 21 Nov 2001 14:45:24 -0800 (PST) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15354.45414.23171.182987@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > You have not actually established your key underlying assumption, that > identity protection necessarily involves substantial extra cost. > > The proposed IKEv2, if I've read the spec correctly, establishes both > an ISAKMP SA and a set of IPsec SAs, *with* full identity protection, > in 2 round trips. It is difficult to imagine improving on that. > > (IKE needs 2.5 round trips *without* identity protection.) Fine, then IKEv2 meets my proposed requirement. That doesn't negate the requirement, or the reason to have it. We are still talking about requirements, right? Mike From owner-ipsec@lists.tislabs.com Wed Nov 21 18:58:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM2wd810314; Wed, 21 Nov 2001 18:58:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA17335 Wed, 21 Nov 2001 20:58:35 -0500 (EST) Date: Wed, 21 Nov 2001 23:04:16 -0500 From: Richard Guy Briggs To: Michael Thomas Cc: Henry Spencer , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS Message-ID: <20011121230416.U8422@grendel.conscoop.ottawa.on.ca> References: <15354.32876.87395.582187@thomasm-u1.cisco.com> <15356.6437.208148.92112@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15356.6437.208148.92112@thomasm-u1.cisco.com>; from mat@cisco.com on Wed, Nov 21, 2001 at 01:14:13PM -0800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Nov 21, 2001 at 01:14:13PM -0800, Michael Thomas wrote: > Henry Spencer writes: > > On Tue, 20 Nov 2001, Michael Thomas wrote: > > > ...In the particular example given, if my > > > national identity smart card gave away all sorts > > > of private information to any merchant who asked, > > > why should I have any belief that that information > > > will remain private? > > > > Do you expect that your credit-card numbers will remain private, even > > though you give them to any merchant you deal with? Sure you do! You > > may not bet your life on it, but you do bet your credit rating on it. > > Actually, I don't. Credit cards are completely insecure and > the only reason that I use them is that the credit card > company is willing to take the hit for fraud, not me. Since you are quite comfortable with credit card companies taking the hit for fraud, then I expect to see your credit card number published on your personal web page. ;-) > Mike slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada -- \@ @ No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- _______GTVS6#790__(*)_______(*)(*)_______ From owner-ipsec@lists.tislabs.com Wed Nov 21 19:46:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM3kf811401; Wed, 21 Nov 2001 19:46:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17476 Wed, 21 Nov 2001 22:01:12 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Sandy Harris" , References: <3BFAACC0.ACA84B7E@storm.ca> Subject: Re: SOI: identity protection and DOS Date: Wed, 21 Nov 2001 22:10:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 22 Nov 2001 03:10:04.0825 (UTC) FILETIME=[2EACB090:01C17303] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sandy, I should be more elaberate that "the attaker has to spend more resource than the been attacked". The DDOS is a good example for attacker to leverage weak secured computing resources to attack the been attacked. However, if this happens, the attacker still require the skill/resource to have extra effort (than those does not) and leave more trace behind. The been attacked must be valuable and with large resource in command. If the attacker have to spend more or equal resource, it will leave a much larger trace behind. --- David ----- Original Message ----- From: "Sandy Harris" To: Sent: Tuesday, November 20, 2001 2:19 PM Subject: Re: SOI: identity protection and DOS > david chen wrote: > > > > The IPSec is id-protection first (DH-key exchange) then authentication. > > As long as can device a mechanism that the DDOS attacker has > > to spend larger or equal amount of resource than the been attacked, > > it will be home free. > > Not really. That'a a reasonable goal, and may be enough to stop an attacker > with limited resources, but you're hardly "home free". > > For one thing, many IPsec gateways are fairly limited devices -- older > machines recycled as FreeS/WAN or *BSD gateways, low-cost dedicated devices, > routers that may be older or bottom-of-line models, ... -- and methinks we > do want those devices to be secure and reliable if possible. > > Also, an EvilDoer is not constrained to use only his own resources. He > can fairly easily find a few dozen badly administered machines around > the net, subvert them, and use their resources to attack you. At that > point, he both has more resources than you and isn't paying for them, > so if you want to stop him via resource constraints, then the attack > has to be really expensive. > > What if he writes a virus and gets thousands of infected machines to > attack you? > From owner-ipsec@lists.tislabs.com Wed Nov 21 20:46:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM4kP812908; Wed, 21 Nov 2001 20:46:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA17593 Wed, 21 Nov 2001 22:57:56 -0500 (EST) Date: Wed, 21 Nov 2001 23:06:34 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15356.11908.141636.804339@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 21 Nov 2001, Michael Thomas wrote: > > The proposed IKEv2, if I've read the spec correctly, establishes both > > an ISAKMP SA and a set of IPsec SAs, *with* full identity protection, > > in 2 round trips. It is difficult to imagine improving on that... > > Fine, then IKEv2 meets my proposed requirement. That > doesn't negate the requirement, or the reason to have it. > We are still talking about requirements, right? We are, but you've given a rather confused impression of what your proposed requirement actually *is*. You start out saying "identity protection should not be mandatory if it is expensive", which is at least defensible. But then you switch to "since identity protection is known to be expensive, it must not be mandatory", which is simply unfounded. You need to stick to stating requirements, and avoid jumping to conclusions about how they should be met. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 21 21:20:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM5KW813623; Wed, 21 Nov 2001 21:20:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17706 Wed, 21 Nov 2001 23:41:37 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15356.33782.228191.928128@thomasm-u1.cisco.com> Date: Wed, 21 Nov 2001 20:49:58 -0800 (PST) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15356.11908.141636.804339@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Wed, 21 Nov 2001, Michael Thomas wrote: > > > The proposed IKEv2, if I've read the spec correctly, establishes both > > > an ISAKMP SA and a set of IPsec SAs, *with* full identity protection, > > > in 2 round trips. It is difficult to imagine improving on that... > > > > Fine, then IKEv2 meets my proposed requirement. That > > doesn't negate the requirement, or the reason to have it. > > We are still talking about requirements, right? > > We are, but you've given a rather confused impression of what your > proposed requirement actually *is*. You start out saying "identity > protection should not be mandatory if it is expensive", which is at least > defensible. But then you switch to "since identity protection is known to > be expensive, it must not be mandatory", which is simply unfounded. You > need to stick to stating requirements, and avoid jumping to conclusions > about how they should be met. I meant what was started out with. Where that led to was a chorus of "it's not expensive" with a bunch of confusion along the way which I'm still not sure about of whether it is or isn't. Also: we still haven't mentioned the other part of my initial post which was about DoS protection which I lump in the same category: make it optional for when the exceptional conditions arise. Mike From owner-ipsec@lists.tislabs.com Wed Nov 21 21:25:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM5Pv813760; Wed, 21 Nov 2001 21:25:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA17748 Wed, 21 Nov 2001 23:49:08 -0500 (EST) Date: Wed, 21 Nov 2001 23:57:47 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15356.6437.208148.92112@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 21 Nov 2001, Michael Thomas wrote: > ...considering that you can't tell a priori > who's demanding your credentials (cf Radia's > post), it seems pretty risky to give out > private data to an unauthenticated party. Yes. But you may wish to accept that risk, for the sake of authentication using inconveniently-organized credentials. If both ends are using such credentials, *somebody* has to take that risk by speaking first. Using such credentials may be a poor choice, but as earlier noted, it's already being done, so the issue cannot be ignored. The point is, willingness to take that risk does *not* imply willingness to take the much greater risk of exposing that data to passive snoopers. An impersonation or man-in-the-middle attack is distinctly harder to do than mere packet monitoring, so it is not ridiculous to desire protection against the latter while not worrying too much about the former. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 21 21:46:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM5ks814239; Wed, 21 Nov 2001 21:46:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17816 Thu, 22 Nov 2001 00:07:31 -0500 (EST) Date: Thu, 22 Nov 2001 00:16:13 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15356.33782.228191.928128@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 21 Nov 2001, Michael Thomas wrote: > > ...You start out saying "identity > > protection should not be mandatory if it is expensive", which is at least > > defensible. But then you switch to "since identity protection is known to > > be expensive, it must not be mandatory", which is simply unfounded... > > I meant what was started out with. Correct. Which is what I describe above: it claims to be a requirement, but it's half requirement and half incorrect conclusions drawn from the requirement. You need to fix it. All the statements (not just the first one) about how it ought to be optional need to be qualified with "unless it's cheap". Making stuff optional is *not* a good thing, in general. Better to have only one way to do things -- it simplifies analysis, implementation, and testing. Alternatives should be present only if they are truly necessary. IPsec in general, and IKE in particular, currently has a near-fatal case of optionitis. Requirements should state the results to be achieved, rather than trying to dictate how they are achieved. "The protocol shall not include a mandatory extra round trip solely for identity protection" is a requirement. "Identity protection should be optional because it is too expensive" is an attempt to dictate *how* that mandatory round trip is to be avoided; IKEv2 demonstrates that there are better ways, which should not be precluded by jumping to conclusions at requirements time. > ...we still haven't mentioned the other part of my > initial post which was about DoS protection which > I lump in the same category: make it optional for > when the exceptional conditions arise. Unless it's cheap, in which case it should be not merely permitted and encouraged, but mandatory. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 21 22:24:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM6OF815125; Wed, 21 Nov 2001 22:24:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA17905 Thu, 22 Nov 2001 00:44:47 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15356.37573.715105.741435@thomasm-u1.cisco.com> Date: Wed, 21 Nov 2001 21:53:09 -0800 (PST) To: Henry Spencer Cc: Michael Thomas , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: References: <15356.33782.228191.928128@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > On Wed, 21 Nov 2001, Michael Thomas wrote: > > > ...You start out saying "identity > > > protection should not be mandatory if it is expensive", which is at least > > > defensible. But then you switch to "since identity protection is known to > > > be expensive, it must not be mandatory", which is simply unfounded... > > > > I meant what was started out with. > > Correct. Which is what I describe above: it claims to be a requirement, > but it's half requirement and half incorrect conclusions drawn from the > requirement. There are an infinite number of ways the protocol could be constructed. Without requirements -- such as how to value engineering tradeoffs -- there is no way to judge them in a way that anybody will agree on. My claim is that identity protection is for the most part marginal given traffic analysis and the "who's there" problem. As such, the average case shouldn't suffer because of it. I've yet to see anything discussed here to sway my original opinion. Whether IKEv2, JFK, or something else entirely meets that requirement, is beside the point; assuming you support one of them, you should be happy since it serves to weed out ones that _don't_ meet that requirement. > You need to fix it. All the statements (not just the first > one) about how it ought to be optional need to be qualified with "unless > it's cheap". > > Making stuff optional is *not* a good thing, in general. Making 9 message SA establishment protocols is *not* a good thing either. Recall how we got there. Committees, lack of requirements, and complete inattention paid to average cases in the name of "Improved Security", and "Generality" much of which was completely illusory. Mike From owner-ipsec@lists.tislabs.com Wed Nov 21 22:58:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAM6wP815764; Wed, 21 Nov 2001 22:58:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA17997 Thu, 22 Nov 2001 01:13:40 -0500 (EST) Date: Thu, 22 Nov 2001 01:22:20 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <15356.37573.715105.741435@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 21 Nov 2001, Michael Thomas wrote: > ...My claim is that identity protection is > for the most part marginal given traffic > analysis and the "who's there" problem. That is indeed your claim; please note that not everyone agrees, and that attempts to embed this claim into requirements will be contentious. You will be more likely to convince people if you avoid that. > As such, the average case shouldn't suffer > because of it. That is a plausible requirement. Your specific proposed requirement said rather more than that, and those unnecessary extras make it much more contentious. Making identity protection optional is not the only conceivable way to prevent the average case from suffering. If your wish is that the average case should not suffer, many more people will agree with you if your requirement says *exactly that* and no more. > Whether IKEv2, JFK, or something else entirely > meets that requirement, is beside the point... Not quite. The existence of a proposal which appears to meet the underlying "should not suffer" requirement, but does *not* meet the more detailed requirement you actually proposed, should tell you that your proposal was somehow flawed. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Nov 22 03:21:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAMBL6822257; Thu, 22 Nov 2001 03:21:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18493 Thu, 22 Nov 2001 05:12:09 -0500 (EST) Message-ID: <754B35B617609246927CBCE9DC746BAD0E0207@mailserver.omnisec.ch> From: "Lagler, Markus" To: "'ipsec@lists.tislabs.com'" Subject: Notification Types Date: Thu, 22 Nov 2001 11:20:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi To me the assignement of notification types as defined in RFC 2407 and RFC 2408 seems to be quite confusing if not even inconsistent. RFC 2408 (ISAKMP) defines the values 8192 to 16383 as private values and 24576 to 32767 as DOI-specific codes. The RFC 2407 (DOI) itself states that the two ranges (8192 to 16383 and 24576 to 35767) are DOI-specific. Furthermore the ranges 16001 to 16383 and 32001 to 32767 are assigned to be used by cooperating systems (private values). But as mentioned above in RFC 2407 only the range 24576 to 32767 is reserved for DOI-specific code. But to me this does not make much sense, because if it were the case there were only DOI-specific status types and no error types. I would suggest a change of RFC 2407so that two ranges, one for error and one for status types, would be assigned for DOI-specifc use. The DOIs itself could then assigne private values in each of the two ranges (which RFC 2408 actually allready does). The definitions in RFC 2407as I would suggest them: - Defined Error Codes 1 to 30 - Reserved Error Codes 31 to 8191 - DOI-specific Error Codes 8192 to 16383 - Defined Status Codes 16384 - Reserved Status Codes 16385 to 24575 - DOI-specific Status Codes 24576 to 32767 Regards Markus From owner-ipsec@lists.tislabs.com Thu Nov 22 15:30:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAMNUw809277; Thu, 22 Nov 2001 15:30:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19430 Thu, 22 Nov 2001 17:24:56 -0500 (EST) Date: Fri, 23 Nov 2001 00:34:31 +0200 (IST) From: Hugo Krawczyk To: ipsec list cc: sheila.frankel@nist.gov, skelly@SonicWALL.com Subject: Re: I-D ACTION:draft-ietf-ipsec-ciph-sha-256-00.txt In-Reply-To: <200111191329.IAA26802@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I noticed the following text under the security considerations of this draft: The security provided by HMAC-SHA-256-96 is based upon the strength of HMAC and, to a lesser degree, the strength of SHA-256. At the time of this writing there are no practical cryptographic attacks against HMAC-SHA-256-96. This is incorrect. The security of HMAC-SHA-256-96 is FULLY dependent on the security of SHA-256-96 (and not the other way around). That's exactly the advantage of a well-analyzed algorithm (or mode) as HMAC: its security is GUARANTEED as long as the underlying hash function is secure (in the sense established in the HMAC paper, Crypto'96) Besides, given current (open literature!) state of cryptanalysis for SHA-1, using SHA-256 in the context of a MAC function (as in ESP) is overkill. In uses of HMAC as a prf for key derivation it may make some sense (for strong long-lived level of security) since the security of the derived keys may be needed also years from now. Hugo On Mon, 19 Nov 2001 Internet-Drafts@ietf.org wrote: > 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 HMAC-SHA-256-96 Algorithm and Its Use With IPsec > Author(s) : S. Frankel, S. Kelly > Filename : draft-ietf-ipsec-ciph-sha-256-00.txt > Pages : 8 > Date : 16-Nov-01 > > Ths document describes the use of the HMAC algorithm in conjunction > with the SHA-256 algorithm as an authentication mechanism within the > context of the IPsec Authentication Header and the IPsec Encapsulat- > ing Security Payload. HMAC with SHA-256 provides data origin authen- > tication and integrity protection. This version of the HMAC-SHA-256 > authenticator specifies truncation to 96 bits, and is therefore named > HMAC-SHA-256-96. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-sha-256-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also 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-ciph-sha-256-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ipsec-ciph-sha-256-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-ipsec@lists.tislabs.com Thu Nov 22 15:31:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAMNVI809297; Thu, 22 Nov 2001 15:31:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19452 Thu, 22 Nov 2001 17:33:13 -0500 (EST) Date: Fri, 23 Nov 2001 00:42:43 +0200 (IST) From: Hugo Krawczyk To: Derek Atkins cc: ipsec list Subject: Re: SOI: identity protection and DOS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 20 Nov 2001, Derek Atkins wrote: [...] > > I happen to agree with Radia's point that you should try to protect > the initiator's identity before the responder's identity (which > implies the responder should authenticate to the initiator first). > Yes, this implies an extra round trip, but if the initiator wants to > protect their identity they should have the choice to do so. > No, it does NOT imply an extra round trip. It is the other way around. Protecting the initiator from active attacker takes just 3 messages. Protecting the responder takes 4. See the SIGMA draft (http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt) Hugo > -derek > From owner-ipsec@lists.tislabs.com Thu Nov 22 15:32:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAMNWb809327; Thu, 22 Nov 2001 15:32:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA19442 Thu, 22 Nov 2001 17:27:44 -0500 (EST) Date: Fri, 23 Nov 2001 00:37:18 +0200 (IST) From: Hugo Krawczyk To: Brian Hunter cc: ipsec list Subject: Re: IKE-SIGMA: draft-krawczyk-ipsec-ike-sigma-00.txt In-Reply-To: <3BFB8827.B120F14B@sit.fraunhofer.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear Brian, Thanks for the comments. First of all keep in mind that the cookies technique just covers a type of easy-to-mount DoS attack, but certainly not all possibilities. This is why it is SO IMPORTANT to use an adaptive method. You do not want to almost duplicate ALL traffic produced by the protocol (i.e from 3 messages to 5) at ALL times, just to provide a defense in relatively few cases against this limited type of DoS attack. As for your specific issues: I may be missing something but regarding the first point you make, the draft is clear about the fact that no protection is provided or intended in the case that the attacker can intercept both messages 1 and 2. Certainly, this is not prevented even if you include SA and KE under the RC calculation. As for the second point: I did consider adding SA, KE for situations like this, however I rejected the idea. In the case that RC is computed with SHA-1 or MD5 adding these values would TRIPLE the time to compute RC (with a 1024-bit prime). If you use a 128-bit block cipher for the computation (say AES) then adding these fields 10-PLICATE the cost of generation and verification! This certainly is NOT worth the little defense that this whole thing achieves. After all if the attacker can intercept messages 1 and 2, and be so fast in sending message 3 with the (forged) initiator's IP address then the same attacker can produce the whole attack by sending message 1 with I's address. The dammage caused to I by the attack you describe is not so bad and not in any case not what we are trying to solve. RC is a defense for R not for I. If I misunderstood your suggestion, please explain again. This part of my SIGMA draft describing RC is certainly a "detail" of my whole proposal and can be changed if improvements are found. (Actually, I'd like to hear of possible improvements since I also describe this RC mechanism in the context of the PIC protocol of IPSRA draft-ietf-ipsra-pic-04.txt, which may soon become a standard track RFC.) Thanks, Hugo On Wed, 21 Nov 2001, Brian Hunter wrote: > I am only commenting on the content of the proposal and not on whether > or not this proposal should be accepted into the WG. I am not sure if > these comments should be left until after the draft is accepted or not. > > After reading the draft, I would like to propose a modification to the > suggested scheme for creating RCs in 2.3. It is noted that this is not > a mandatory scheme since RCs are only used by the responder, but by > suggesting it in the draft, it is likely that it will be used by at > least some implementations. > > The purpose of the RC is to prevent DoS and is only used when the > Responder believes it is under attack. The fourth note in section 2.3 > states that the RC also protects against attackers who intercept the > second message of the exchange. > -Note 4 > "The inclusion of Ni under the computation of RC achieves, at > no extra cost, a strengthening of the DoS protection mechanism > provided by RC: an attacker that intercepts the second message > from R to I (which includes the RC cookie and the Initiator's > IP address), but did not generate or intercept the first message > from I to R, cannot use the intercepted cookie RC for sending a > seemingly-valid message 3 since this attacker lacks the unique > value Ni that needs to be included in this third message." > > However, this provides no protection against an attacker who can listen > to messages 1 and 2 of the exchange and then send a seemingly-valid > message 3. The sixth note tries to prevent a replay-attack but I > believe the use of this window and tracking mechanism opens up a new > potential DoS attack. > -Note 6 > "The parameter T included in the cookie computation is intended to > prevent the attacker from replaying old values of message 3. > However, for the period of time that a certain value of T is > acceptable at R an attacker could replay the message 3 with this > value of T. The simplest solution to this is to implement T as a > counter and keep track of the values in the current window that > have been already received. In this way, no replay at all is > possible." > > Now if the attacker can read message 2 (and message 1) and send a > seemingly-valid message 3 before the Initiator can, he has denied the > Initiator from using this negotiation since the Responder will silently > reject all further message 3s. The problem lies in the fact that the > attacker is capable of changing the proposed SA and KE in the third > message without the Responder being able to tell the difference. Thus, > the Responder believes message 3 is from the Initiator and will send > message 4 to the Initiator but the SA and KE may not be acceptable to > the Initiator and it must re-start the whole negotiation. > > Thus, if an attacker can make a Responder believe it is under attack and > starts to use RCs, then the attacker can actually cause DoS because of > the RCs and extra messages. > > This can be avoided by adding SA and KE (and OIDii if present) from > message 1 to the hashed values to obtain v. Thus v would now look like > this: > v = prf(K, T | IPi | Ni | SA | KE [| OIDii]) > > Now when the Responder verifies v sent back from the Initiator in > message 3, it can verify that SA and KE in message 3 are the same as > those in message 1. In this manner, a quicker attacker can only insert > a valid message 3, which would actually decrease the round trip time and > speed up the negotiation. > > Note that this modification does not increase the size of v since it can > still be truncated as per the fifth note in 2.3. Nor does it create any > state on the Responder. > > The drawback to this method is that depending on the length of SA and > KE, an extra hash round(s) may be required to perform the prf. > > Is this a viable solution to this attack? > > Brian > From owner-ipsec@lists.tislabs.com Fri Nov 23 02:41:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANAfT817601; Fri, 23 Nov 2001 02:41:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA20335 Fri, 23 Nov 2001 04:28:53 -0500 (EST) Message-ID: <20011123093746.76852.qmail@web8006.mail.in.yahoo.com> Date: Fri, 23 Nov 2001 09:37:46 +0000 (GMT) From: =?iso-8859-1?q?ranjeet=20barve?= Subject: Regardind IPsec Databases To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Please could you help me on the following points, 1) This question is with reference with the few postings on the mailing list regarding Number of SPD Records. I do agree that the Number of SPD entries is a function of the local access control policy and the breadth of connectivity. But can a rough estimate of the number of SPD,SAD and SA database entries be made given that the gateway supports 25 tunnels ,100 tunnels and 1000 tunnels simultaneously as three different cases. If yes, then please can you give me the rough estimates for the same. 2) It was mentioned in a few postings that the SPD and SAD databases are STATIC. Does this mean that one is not supposed to Delete entries(policies)from these Databases? Actually deleting a single entry from the SPD database could lead to recursive deletions and re-arranging of the SAD Database and consequently re-ordering of numerous pointers from the SPD to SAD database. Or does it mean that they dont change dynamically? 3) Whenever we are supposed to change the Action field of the IPsec Policy entry from IPsec bundle to Relay or Discard, what happens to the pointer that existed initially from the SPD policy to SAD entry specific to that policy (nextSADPtr) and the corresponding entries in the SAD. Regards, Ranjeet. (ranjeet@it.iitb.ac.in) ____________________________________________________________ *NEW* over 2200 active jobs at Yahoo! Careers *NEW* Visit http://in.careers.yahoo.com/ From owner-ipsec@lists.tislabs.com Fri Nov 23 06:34:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANEYb803553; Fri, 23 Nov 2001 06:34:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20696 Fri, 23 Nov 2001 08:25:40 -0500 (EST) From: Steve.Robinson@psti.com Subject: Re: Regardind IPsec Databases To: ranjeet barve Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 23 Nov 2001 08:40:31 -0500 X-MIMETrack: Serialize by Router on ARCPrecise/ARC(Release 5.0.8 |June 18, 2001) at 11/23/2001 01:41:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ranjeet barve cc: Sent by: Subject: Regardind IPsec Databases owner-ipsec@lists.t islabs.com 11/23/01 04:37 AM >>2) It was mentioned in a few postings that the SPD and >>SAD databases are STATIC. Does this mean that one is >>not supposed to Delete entries(policies)from these >>Databases? Actually deleting a single entry from the >>SPD database could lead to recursive deletions and >>re-arranging of the SAD Database and consequently >>re-ordering of numerous pointers from the SPD to SAD >>database. >>Or does it mean that they dont change dynamically? STEVE: When in doubt, always refer to the RFC's. RFC2401 says nothing about the databases being static -- so if someone implemented their code like that (are you referring to Freeswan?) that's their decision. You can set up your databases however you want internally. I linked the security associations to the individual policies, so that I can dynamically add and remove policies fairly easily. It also reduces look-up times during packet processing -- but it does add code complexity to keep things dynamic. It really depends on your application needs. What is your application doing? Will it be on a very static network for a long period of time, or are you going to have to reboot every week to add/remove nodes from the network you are on? The bottom line is, do you want your solution to be scalable? Look at why DNS was created, will your application suffer from similar problems 5 years down the road? From owner-ipsec@lists.tislabs.com Fri Nov 23 09:28:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fANHSB813872; Fri, 23 Nov 2001 09:28:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20982 Fri, 23 Nov 2001 11:23:56 -0500 (EST) Message-ID: <3BFE7A28.5FDCF0DD@sit.fraunhofer.de> Date: Fri, 23 Nov 2001 17:32:43 +0100 From: Brian Hunter X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugo Krawczyk CC: ipsec list Subject: Re: IKE-SIGMA: draft-krawczyk-ipsec-ike-sigma-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Hugo, Thanks, I now better understand the costs of my proposal and why it wasn't already pursued. I will just add a couple of comments. > RC is a defense for R not for I. My thoughts in this regard were that denying I, for any number of different Is, a valid IKE session IS a DoS against R since R cannot service valid I requests. Of course the affected Is would be a subset of all Is since the attacker must have access to read message 1 and 2 of the exchanges. I was thinking that this type (and all possible types) of denied service should be prevented. However, due to the rarity of the attack and the additional computational costs for RC generation (as you point out, 3-10 times extra work) needed by the prevention scheme, I see that my idea has a high cost/benefit ratio. I also realize that my idea would work against the effectiveness of the save-the-resources-RC by requiring more computations by R. Thank you for your explanations and feedback. Brian From owner-ipsec@lists.tislabs.com Sun Nov 25 07:28:31 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAPFSU819347; Sun, 25 Nov 2001 07:28:30 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA25336 Sun, 25 Nov 2001 09:07:14 -0500 (EST) Message-ID: <000001c175bb$87227100$0c00a8c0@internet> Reply-To: "Mahdavi" From: "Mahdavi" To: "ipsec" Subject: routing and outbound. Date: Sun, 25 Nov 2001 17:25:30 +0330 Organization: PayamPardaz MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C175D6.2E1D2E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C175D6.2E1D2E40 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi. Imagine an IPSEC armed router. As any knows routers have interfaces. = Each interface may be IPSEC enabled or not( Am I right !!?? ). Upon arrival of any packet to router which serries of task must be done = on the acket?=20 1- Inbound , Outbound and then Routing. 2- Inbound , Routing and then Outbound. 3- Routing , inbound and then Outbound.=20 each of these configuration has weaknesses.=20 a)-in case 1 there is high probability danger of denial of service for = protected subnetwork when at least one of routers interfaces is IPSEC = unarmed.=20 b)-case 2 has logical flaw. After Outbound process new packet will be = made with new IP header. so this needs routing again.=20 c)- case 3 means that IPSEC Process must be done after Routing. this has = spoofing danger.=20 now what configuration is correct or may be I have a basic = missundrestanding.=20 best regars=20 mahdavi ------=_NextPart_000_0007_01C175D6.2E1D2E40 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi.
 
Imagine an IPSEC armed router. As any = knows routers=20 have interfaces. Each interface may be IPSEC enabled or not( Am I=20 right !!?? ).
 
Upon arrival of any packet to router = which serries=20 of task must be done on the acket?
 
1- Inbound , Outbound and then=20 Routing.
2- Inbound , Routing and then=20 Outbound.
3- Routing , inbound and then Outbound. =
 
each of these configuration has = weaknesses.=20
 
a)-in case 1 there is high probability = danger of=20 denial of service for protected subnetwork when at least one of routers=20 interfaces is IPSEC unarmed.
b)-case 2 has logical flaw. After = Outbound process=20 new packet will be made with new IP header. so this needs routing again. =
c)- case 3 means that IPSEC Process = must be done=20 after Routing. this has spoofing danger.
 
now what configuration is correct or = may be I have=20 a basic missundrestanding.
 
best regars
 
mahdavi
------=_NextPart_000_0007_01C175D6.2E1D2E40-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Sun Nov 25 10:03:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAPI3t827892; Sun, 25 Nov 2001 10:03:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA25484 Sun, 25 Nov 2001 12:15:21 -0500 (EST) Reply-To: From: "Lars Eggert" To: "Mahdavi" , "ipsec" Subject: RE: routing and outbound. Date: Sun, 25 Nov 2001 09:24:48 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000001c175bb$87227100$0c00a8c0@internet> Importance: Normal Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0012_01C17593.06FC87E0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C17593.06FC87E0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit Mahdavi, are you doing hop-by-hop IPSec, i.e. construct a virtual topology out of IPsec tunnels? If so, we have some information on this in draft-touch-ipsec-vpn-01.txt (expired, -02 has been submitted, but not yet announced). If you aren't (i.e. you're simply routing IPsec packets), nothing happens at routers: IPsec is end-to-end. Or maybe I didn't understand your question correctly? Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mahdavi Sent: Sunday, November 25, 2001 5:56 AM To: ipsec Subject: routing and outbound. Hi. Imagine an IPSEC armed router. As any knows routers have interfaces. Each interface may be IPSEC enabled or not( Am I right !!?? ). Upon arrival of any packet to router which serries of task must be done on the acket? 1- Inbound , Outbound and then Routing. 2- Inbound , Routing and then Outbound. 3- Routing , inbound and then Outbound. each of these configuration has weaknesses. a)-in case 1 there is high probability danger of denial of service for protected subnetwork when at least one of routers interfaces is IPSEC unarmed. b)-case 2 has logical flaw. After Outbound process new packet will be made with new IP header. so this needs routing again. c)- case 3 means that IPSEC Process must be done after Routing. this has spoofing danger. now what configuration is correct or may be I have a basic missundrestanding. best regars mahdavi ------=_NextPart_000_0012_01C17593.06FC87E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF5jCCArUw ggIeoAMCAQICAwWBRzANBgkqhkiG9w0BAQIFADCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsT FENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAw MC44LjMwMB4XDTAxMDgyNDE2NDAwMFoXDTAyMDgyNDE2NDAwMFowVDEPMA0GA1UEBBMGRWdnZXJ0 MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFy c2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0AvLBsD78nxcUHeHkaMgl3b4 qYPnfgbf8Lh+HQP8RgGMRG/Yb+vTpkGezlwt9pkJxiD11uZDy4CNNJUu3gKxKSb+zRV70O+lkwwf tuHoLHoH4xwo3LcQ2LGDpd+I95tUN4dfJ3TmeEcUSF50dC/SuUI4w8AlhXQ8IxrhgdayTpECAwEA AaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREE ETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQECBQADgYEAheZhn0pQ A8zI7U2K1ZIAl11j0a1DKxnp3GtTvOUrGRB3WvYxidvdZ1kizhEsWeXU81TkNDH0DaRqtOEeu6Q2 OhB+jeKEqY7IDAJE4/fI0e+d6PnG1hd+vEvYmsKHkmzBhPc94XUOKNWO+qVNP2NGyNI3QIDy5wX4 fdcOo1S34r4wggMpMIICkqADAgECAgEMMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEV MBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNv bmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDIwODI5MjM1OTU5WjCB kjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQD Ex9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz63K737nRvMLwzkH/5NHGgo22Y 8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR3hzpq+AYA6h8Q0JQUYeDPPA5tJtU ihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcN AQEEBQADgYEAcxtvJmWL/xU0S1liiu1EvknH6A27j7kNaiYqYoQfuIdjdBxtt88aU5FL4c3mONnt UPQ6bDSSrOaSnG7BIwHCCafvS65y3QZn9VBvLli4tgvBUFe17BzX7xe21Yibt6KIGu05Wzl9NPy2 lhglTWr0ncXDkS+plrgFPFL83eliA0gxggKqMIICpgIBATCBmjCBkjELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFp bCBSU0EgMjAwMC44LjMwAgMFgUcwCQYFKw4DAhoFAKCCAWUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMDExMTI1MTcyNDQ4WjAjBgkqhkiG9w0BCQQxFgQUOMNXygwL nQ6qosgaKD2liLOv2L4wWAYJKoZIhvcNAQkPMUswSTAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgasGCSsGAQQB gjcQBDGBnTCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UE BxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwAgMFgUcwDQYJKoZI hvcNAQEBBQAEgYBy5SYHZUBCiT6aWzsNvxhX3tK6ulVhNdzT2C8eC4OimWg4ymYafTT3i5Wc56vC Pmz1Ao30w7cpvVHfS3S3/ZYuqEUY1Ii1EZMMo2MEcjOyXktY/3ZP329cfdEv83RsRno8F63nKBSk S4Muib2cfADVQWVVyQPfVO5xrn2Vl2V7GAAAAAAAAA== ------=_NextPart_000_0012_01C17593.06FC87E0-- From owner-ipsec@lists.tislabs.com Sun Nov 25 14:20:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAPMKa809311; Sun, 25 Nov 2001 14:20:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA25737 Sun, 25 Nov 2001 16:13:36 -0500 (EST) Message-ID: <002601c175f7$4ee83fe0$9f5db0d5@mahdavi> From: "mahdavi" To: "ipsec" References: Subject: Re: routing and outbound. Date: Mon, 26 Nov 2001 00:52:32 +0330 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Lars Eggert. No. I am trying to design an IPSEC armed router. A router acts as a security gateway so it usese tunnel mode not tronsport. Now my question is if there is a router that has some interfaces and these interfaces may be IPSEC armed or not, now which is the correct configuration, case 1 , 2 or 3? which one? or there may be other way ? and what do you mean by hop-by-hop IPSEC ? ----- Original Message ----- From: "Lars Eggert" To: "Mahdavi" ; "ipsec" Sent: Sunday, November 25, 2001 8:54 PM Subject: RE: routing and outbound. > Mahdavi, > > are you doing hop-by-hop IPSec, i.e. construct a virtual topology out of > IPsec tunnels? If so, we have some information on this in > draft-touch-ipsec-vpn-01.txt (expired, -02 has been submitted, but not yet > announced). > > If you aren't (i.e. you're simply routing IPsec packets), nothing happens > at routers: IPsec is end-to-end. > > Or maybe I didn't understand your question correctly? > > Lars > -- > Lars Eggert Information Sciences Institute > http://www.isi.edu/larse/ University of Southern California > > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Mahdavi > Sent: Sunday, November 25, 2001 5:56 AM > To: ipsec > Subject: routing and outbound. > > > Hi. > > Imagine an IPSEC armed router. As any knows routers have interfaces. Each > interface may be IPSEC enabled or not( Am I right !!?? ). > > Upon arrival of any packet to router which serries of task must be done on > the acket? > > 1- Inbound , Outbound and then Routing. > 2- Inbound , Routing and then Outbound. > 3- Routing , inbound and then Outbound. > > each of these configuration has weaknesses. > > a)-in case 1 there is high probability danger of denial of service for > protected subnetwork when at least one of routers interfaces is IPSEC > unarmed. > b)-case 2 has logical flaw. After Outbound process new packet will be made > with new IP header. so this needs routing again. > c)- case 3 means that IPSEC Process must be done after Routing. this has > spoofing danger. > > now what configuration is correct or may be I have a basic > missundrestanding. > > best regars > > mahdavi > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Sun Nov 25 20:41:50 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQ4fn817292; Sun, 25 Nov 2001 20:41:49 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA26283 Sun, 25 Nov 2001 22:32:27 -0500 (EST) From: Atul4sharma@aol.com Message-ID: <153.49b865a.293313e1@aol.com> Date: Sun, 25 Nov 2001 22:41:21 EST Subject: Re: routing and outbound. To: mahdavi110@yahoo.com, ipsec@lists.tislabs.com CC: atul.sharma@nokia.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_153.49b865a.293313e1_boundary" X-Mailer: AOL 6.0 for Windows US sub 10536 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --part1_153.49b865a.293313e1_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit A packet would go through both inbound and outbound ipsec processing only if a tunnel is being terminated at the router and a new tunnel is being initiated from the router on the same packet stream. I would guess this would constitute a hop by hop IPsec. Typically, you would perform: Inbound processing, Routing OR Outbound processing, Routing In the cases you mention you assume that routing has to be performed once. That may not be necessarily valid. It all depends on your design. One possibility could be that SPD rule processing tells you whether (Inbound or Outbound) IPsec processing is needed or whether Routing is needed. Here you could get by with just one routing iteration. Other possibility could be you receive a packet on an IPsec enabled interface. It goes through inbound IPsec processing. Comes out and gets routed to another interface. Depending on whether the outgoing interface is IPsec enabled or not the packet goes through another round of IPsec processing and routing. That would be close to case 2- you mentioned. I am sure there are other ways to do it too. Then nesting of tunnels can add another complexity to take care of. --Atul In a message dated 11/25/2001 4:59:13 PM Eastern Standard Time, mahdavi110@yahoo.com writes: > Hi Lars Eggert. > No. I am trying to design an IPSEC armed router. A router acts as a > security gateway so it usese tunnel mode not tronsport. > Now my question is if there is a router that has some interfaces and these > interfaces may be IPSEC armed or not, now which is the correct > configuration, case 1 , 2 or 3? which one? or there may be other way ? > > and what do you mean by hop-by-hop IPSEC ? > > --part1_153.49b865a.293313e1_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit
A packet would go through both inbound and outbound ipsec processing only
if  a tunnel is being terminated at the router and a new tunnel is being initiated
from the router on the same packet stream. I would guess this would constitute
a hop by hop IPsec.

Typically, you would perform:
      Inbound processing,  Routing OR
      Outbound processing, Routing

In the cases you mention you assume that routing has to be
performed once. That may not be necessarily valid. It all depends
on your design.

One possibility could be that SPD rule processing tells you whether
(Inbound or Outbound) IPsec processing is needed or whether Routing
is needed. Here you could get by with just one routing iteration.

Other possibility could be you receive a packet on  an IPsec enabled
interface. It goes through inbound IPsec processing. Comes out and gets
routed to another interface. Depending on whether  the outgoing interface
is IPsec enabled or not the packet goes through another round of IPsec
processing and routing. That would be close to case 2- you mentioned.

I am sure there are other ways to do it too.

Then nesting of tunnels can add another complexity to take care of.

--Atul

In a message dated 11/25/2001 4:59:13 PM Eastern Standard Time, mahdavi110@yahoo.com writes:


Hi Lars Eggert.
No. I am trying to  design an IPSEC armed router. A router acts as a
security gateway so it usese tunnel mode not tronsport.
Now my question is if there is a router that has some interfaces and these
interfaces may be IPSEC armed or not, now which is the correct
configuration, case 1 , 2 or 3? which one? or there may be other way ?

and  what do you mean by hop-by-hop IPSEC ?



--part1_153.49b865a.293313e1_boundary-- From owner-ipsec@lists.tislabs.com Sun Nov 25 21:13:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQ5Dh817730; Sun, 25 Nov 2001 21:13:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA26367 Sun, 25 Nov 2001 23:25:11 -0500 (EST) Message-ID: <3C01C5B0.7020902@juniper.net> Date: Sun, 25 Nov 2001 20:31:44 -0800 From: Abraham Shacham User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.5) Gecko/20011019 X-Accept-Language: en-us MIME-Version: 1.0 To: dharkins@tibernian.com CC: ipsec@lists.tislabs.com, ippcp@external.cisco.com Subject: Re: IKEv2 (son-of-ike) draft - IPComp-related comments References: <20011118071052.0F71654C53@tailor.sailpix.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk dharkins@tibernian.com wrote: > Please send comments to the list. Attached are few IPComp-related, mostly editorial, comments. Thanks, avram >1.1 The IKE Protocol > > IKE performs mutual authentication between two parties and > establishes an IKE security association that includes shared secret > information that can be used to efficiently establish SAs for ESP > (RFC 2406), AH (RFC 2402) and/or IPcomp (RFC 2393). s/IPcomp/IPComp/ s/RFC 2393/RFC 3173/ >7.3.1 Proposal Substructure [...] > o SPI Size (1 byte) - During phase 1 negotiation this field > MUST be zero. During phase 2 negotiation it is equal to the > size, in bytes, of the SPI of the corresponding protocol > (4 for ESP and AH, 2 for IPcomp). Current implementations are divided on the size of SPI for IPComp, leading to a compromise where two-octet field is a SHOULD, four-octet a MAY, and the receiving node MUST be able to process both forms (see RFC3173, 4.1. Use of IKE). A single field size of two-octet could simplify the matter, no doubt, but such change should first gain implementors' support. >7.3.2 Transform Substructure [...] > For Transform Type 6 (Compression), defined Transform-IDs are: > > Name Number Defined In > RESERVED 0 > IPCOMP_OUI 1 (w/attributes) > IPCOMP_DEFLATE 2 > (RFC2394) > IPCOMP_LZS 3 > (RFC2395) > > values 4-240 are reserved to IANA. Values 241-255 are for > private use among mutually consenting parties. Following RFC 3051, the above should read: For Transform Type 6 (Compression), defined Transform-IDs are: Name Number Defined In RESERVED 0 IPCOMP_OUI 1 (w/attributes) IPCOMP_DEFLATE 2 (RFC2394) IPCOMP_LZS 3 (RFC2395) IPCOMP_LZJH 4 (RFC3051) values 5-240 are reserved to IANA. Values 241-255 are for private use among mutually consenting parties. === eom === > > > From owner-ipsec@lists.tislabs.com Mon Nov 26 03:43:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQBhL827218; Mon, 26 Nov 2001 03:43:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27797 Mon, 26 Nov 2001 05:31:24 -0500 (EST) Message-ID: <003001c17666$89c33ce0$0c00a8c0@internet> Reply-To: "Mahdavi" From: "Mahdavi" To: , "ipsec" Cc: References: <153.49b865a.293313e1@aol.com> Subject: Re: routing and outbound. Date: Mon, 26 Nov 2001 14:08:18 +0330 Organization: PayamPardaz MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C17683.CC34F2E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C17683.CC34F2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi.=20 Thanks for your detailed answer.=20 I want to undrestand sequence of inbound , outbound and routing in a = hub-and-spoke system.=20 you told=20 >"In the cases you mention you assume that routing has to be=20 >performed once. That may not be necessarily valid. It all depends=20 >on your design."=20 =20 now, in hub-and-spoke configuration how many routing iteration required. = also you told=20 >Other possibility could be you receive a packet on an IPsec enabled=20 >interface. It goes through inbound IPsec processing. Comes out and gets = >routed to another interface. Depending on whether the outgoing = interface=20 >is IPsec enabled or not the packet goes through another round of IPsec=20 >processing and routing. That would be close to case 2- you mentioned.=20 you mean after inbound , routing and outbound it may be need for another = routing iteration again ? now what happens if another interface choosed = after these new routing phase ?=20 =20 clearly I want to undrestand sequnce of IPSEC process and routing when a = hub-and-spoke mentioned ?=20 thanks before=20 mahdavi ----- Original Message -----=20 From: Atul4sharma@aol.com=20 To: mahdavi110@yahoo.com ; ipsec@lists.tislabs.com=20 Cc: atul.sharma@nokia.com=20 Sent: Monday, November 26, 2001 7:11 AM Subject: Re: routing and outbound. A packet would go through both inbound and outbound ipsec processing = only=20 if a tunnel is being terminated at the router and a new tunnel is = being initiated=20 from the router on the same packet stream. I would guess this would = constitute=20 a hop by hop IPsec.=20 Typically, you would perform:=20 Inbound processing, Routing OR=20 Outbound processing, Routing=20 In the cases you mention you assume that routing has to be=20 performed once. That may not be necessarily valid. It all depends=20 on your design.=20 One possibility could be that SPD rule processing tells you whether=20 (Inbound or Outbound) IPsec processing is needed or whether Routing=20 is needed. Here you could get by with just one routing iteration.=20 Other possibility could be you receive a packet on an IPsec enabled=20 interface. It goes through inbound IPsec processing. Comes out and = gets=20 routed to another interface. Depending on whether the outgoing = interface=20 is IPsec enabled or not the packet goes through another round of IPsec = processing and routing. That would be close to case 2- you mentioned.=20 I am sure there are other ways to do it too.=20 Then nesting of tunnels can add another complexity to take care of.=20 --Atul=20 In a message dated 11/25/2001 4:59:13 PM Eastern Standard Time, = mahdavi110@yahoo.com writes:=20 ------=_NextPart_000_002B_01C17683.CC34F2E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi.
Thanks for your detailed answer. =
I want to undrestand sequence of = inbound , outbound=20 and routing in a hub-and-spoke system.
 
you told
>"In the cases you mention you = assume that=20 routing has to be
>performed once. That may not be necessarily = valid. It=20 all depends
>on your design."
 
now, in hub-and-spoke configuration how = many=20 routing iteration required.
also you told
>Other possibility could be you = receive a packet=20 on  an IPsec enabled
>interface. It goes through inbound = IPsec=20 processing. Comes out and gets
>routed to another interface. = Depending on=20 whether  the outgoing interface
>is IPsec enabled or not the = packet=20 goes through another round of IPsec
>processing and routing. That = would=20 be close to case 2- you mentioned.
you mean after inbound , routing and = outbound it=20 may be need for another routing iteration again ? now what happens if = another=20 interface choosed after these new routing phase ?
 
clearly I want to undrestand sequnce of = IPSEC=20 process and routing when a hub-and-spoke mentioned ?
 
thanks before
 
mahdavi
----- Original Message -----
From:=20 Atul4sharma@aol.com
To: mahdavi110@yahoo.com ; ipsec@lists.tislabs.com
Cc: atul.sharma@nokia.com
Sent: Monday, November 26, 2001 = 7:11=20 AM
Subject: Re: routing and = outbound.


A = packet would go=20 through both inbound and outbound ipsec processing only =
if  a=20 tunnel is being terminated at the router and a new tunnel is being = initiated=20
from the router on the same packet stream. I would guess this = would=20 constitute
a hop by hop IPsec.

Typically, you would = perform:=20
      Inbound processing, =  Routing OR=20
      Outbound processing, Routing=20

In the cases you mention you assume that routing has to be=20
performed once. That may not be necessarily valid. It all depends =
on=20 your design.

One possibility could be that SPD rule processing = tells=20 you whether
(Inbound or Outbound) IPsec processing is needed or = whether=20 Routing
is needed. Here you could get by with just one routing = iteration.=20

Other possibility could be you receive a packet on  an = IPsec=20 enabled
interface. It goes through inbound IPsec processing. Comes = out and=20 gets
routed to another interface. Depending on whether  the = outgoing=20 interface
is IPsec enabled or not the packet goes through another = round of=20 IPsec
processing and routing. That would be close to case 2- you=20 mentioned.

I am sure there are other ways to do it too. =

Then=20 nesting of tunnels can add another complexity to take care of. =

--Atul=20

In a message dated 11/25/2001 4:59:13 PM Eastern Standard = Time,=20 mahdavi110@yahoo.com writes:=20


------=_NextPart_000_002B_01C17683.CC34F2E0-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Mon Nov 26 03:52:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQBqg828105; Mon, 26 Nov 2001 03:52:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA27876 Mon, 26 Nov 2001 06:04:26 -0500 (EST) Message-Id: <200111261113.GAA18937@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-03.txt Date: Mon, 26 Nov 2001 06:13:50 -0500 Sender: owner-ipsec@lists.tislabs.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 : More MODP Diffie-Hellman groups for IKE Author(s) : T. Kivinen, M. Kojo Filename : draft-ietf-ipsec-ike-modp-groups-03.txt Pages : 7 Date : 21-Nov-01 This document defines new MODP groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups. The selection of the primes for theses groups follows the criteria estab- lished by Richard Schroeppel as described in [RFC-2412]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ike-modp-groups-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011121140934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-modp-groups-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121140934.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 26 03:52:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQBqj828127; Mon, 26 Nov 2001 03:52:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA27870 Mon, 26 Nov 2001 06:04:17 -0500 (EST) Message-Id: <200111261113.GAA18925@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v3-01.txt Date: Mon, 26 Nov 2001 06:13:41 -0500 Sender: owner-ipsec@lists.tislabs.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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-01.txt Pages : 20 Date : 21-Nov-01 This memo describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-v3-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v3-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011121140922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121140922.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Nov 26 04:06:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQC6V829434; Mon, 26 Nov 2001 04:06:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA27912 Mon, 26 Nov 2001 06:19:10 -0500 (EST) Date: Mon, 26 Nov 2001 13:28:56 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: IKEv2 and SIGMA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The editors of IKEv2 have done a great work in simplifying the specifications setup for IKE. While the current specification is not complete in all aspects it seems to provide a strong basis for converging to a final fully-detailed and implementable specification. This is real progress! I have quite a few comments on the current specification (cryptographic and functional aspects). But by now I'd like to address one fundamental issue related to the cryptographic soundness of the current design. Namely, the protocol does not achieve a strong cryptographic binding between the exchanged DH key and the party identities (an essential security requirement put forth by the STS paper [DVW]). This can be indirectly achieved in IKEv2 via ESP if one MANDATES strong integrity in ESP (otherwise integrity is optional in ESP), but even then a truly sound key exchange protocol should not rely on external mechanisms to provide the most essential security properties (in contrast, using ESP for id protection is perectly reasonable). The solution to this problem is quite simple: put back the prf (or HASH) computation under the signature; a detailed specification can be found in my recent SIGMA proposal [SIGMA]. Moreover, I would recommend integrating the SIGMA protocol to the current IKEv2 specification framework. This would have the effect of providing full cryptographic security AND improving performance by reducing the number of messages and the latency of SA activation. Given the IKEv2 draft, specifying SIGMA in this context requires minimal work. In addition, the SIGMA protocol would allow to have, in addition to the main PK-based protocol, a single mode that simultaneously supports Phase 2 functionality AND provides support for pre-shared keys. Hugo [DVW] W. Diffie, P. van Oorschot and M.Wiener, "Authentication and authenticated key exchanges", Designs, Codes and Cryptography, 2, 1992. [SIGMA] H. Krawczyk, "The IKE-SIGMA Protocol", http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt. From owner-ipsec@lists.tislabs.com Mon Nov 26 06:44:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQEiP808871; Mon, 26 Nov 2001 06:44:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA28280 Mon, 26 Nov 2001 08:45:49 -0500 (EST) Reply-To: From: "Awan Kumar" To: "IpsecMailingList (E-mail)" Cc: Subject: rfc 2709 Tunnel mode ipsec with NAT Date: Mon, 26 Nov 2001 19:07:41 +0530 Message-Id: <000d01c1767f$865005c0$0702060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi , I have some queries regarding rfc2709 1) figure 3 states that perform IPC-NAT then perform outbound security , My question is the address translated in Inner Ip header ?? or ip packet from the private domain is not altered and outer Ip header is put in which source address will be the Global Ip address . I am eagerly waiting for the answer so that I can post my next query thanxs in advance . ---------------------------- Awan Kumar Sharma Sr. Software Engg., Future Software Ltd., Chennai, India. Ph: 4330 550 Extn: 437 (www.futsoft.com) ------------------------------ From owner-ipsec@lists.tislabs.com Mon Nov 26 06:58:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQEwX809258; Mon, 26 Nov 2001 06:58:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28401 Mon, 26 Nov 2001 09:06:38 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0CC9@MAIL.NetOctave.com> From: Mark Winstead To: ipsec@lists.tislabs.com Subject: RE: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-03.txt Date: Mon, 26 Nov 2001 09:16:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I note that the introduction section of this paper sort of cites two sources for analysis of security equivalent key sizes. Why not cite them in the paper? It seems to be useful information for potential users. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, November 26, 2001 6:14 AM Cc: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-ike-modp-groups-03.txt 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 : More MODP Diffie-Hellman groups for IKE Author(s) : T. Kivinen, M. Kojo Filename : draft-ietf-ipsec-ike-modp-groups-03.txt Pages : 7 Date : 21-Nov-01 This document defines new MODP groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, 4096, 6144, and 8192 bit Diffie-Hellman groups. The selection of the primes for theses groups follows the criteria estab- lished by Richard Schroeppel as described in [RFC-2412]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ike-modp-groups-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-ipsec@lists.tislabs.com Mon Nov 26 10:39:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQId9826279; Mon, 26 Nov 2001 10:39:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28878 Mon, 26 Nov 2001 12:40:23 -0500 (EST) From: Ghislaine Labouret To: "Eissa, Mohamed" Cc: ipsec@lists.tislabs.com Subject: Re: latest ipsec/pki bake off results Date: Fri, 23 Nov 2001 11:10:25 +0100 Organization: HSC (Herve Schauer Consultants) References: <6549284BE680D511815C0002A50A67770D131B@hdsmsx102.hd.intel.com> In-Reply-To: <6549284BE680D511815C0002A50A67770D131B@hdsmsx102.hd.intel.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20011123100923.0A1DB20F81@itesec.hsc.fr> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 16 Nov 2001 07:51:50 -0800, Eissa, Mohamed wrote: > Can anybody help me to find to the latest bake off results, specially > IKE/PKIX portion? Although much more modest than a bakeoff, you might also be interested by the results of some IKE interoperability tests conducted last month in France: http://www.hsc.fr/ipsec/ipsec2001/ Sincerely, -- Ghislaine Labouret, Network security consultant Hervé Schauer Consultants (HSC) - http://www.hsc.fr/ Phone (+33)-141-409-700 - Fax (+33)-141-409-709 From owner-ipsec@lists.tislabs.com Mon Nov 26 10:39:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQIdL826292; Mon, 26 Nov 2001 10:39:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA28820 Mon, 26 Nov 2001 12:12:02 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15362.31215.577809.622607@thomasm-u1.cisco.com> Date: Mon, 26 Nov 2001 09:20:47 -0800 (PST) To: Hugo Krawczyk Cc: Derek Atkins , ipsec list Subject: Re: SOI: identity protection and DOS In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > On 20 Nov 2001, Derek Atkins wrote: > [...] > > > > I happen to agree with Radia's point that you should try to protect > > the initiator's identity before the responder's identity (which > > implies the responder should authenticate to the initiator first). > > Yes, this implies an extra round trip, but if the initiator wants to > > protect their identity they should have the choice to do so. > > > > No, it does NOT imply an extra round trip. It is the other way around. > Protecting the initiator from active attacker takes just 3 messages. > Protecting the responder takes 4. > See the SIGMA draft > (http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt) If you allow for pre-shared keys, then it clearly requires an extra message or two. Which is why we should determine what the actual requirement is re pre-shared keys. If it's a requirement, then we need to confront the time/protection tradeoff. If it's not a requirement, this mostly vanishes. Mike From owner-ipsec@lists.tislabs.com Mon Nov 26 10:57:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQIvP826925; Mon, 26 Nov 2001 10:57:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA28973 Mon, 26 Nov 2001 13:00:09 -0500 (EST) Message-ID: <3C028627.E11B6422@redcreek.com> Date: Mon, 26 Nov 2001 10:12:55 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mahdavi CC: ipsec Subject: Re: routing and outbound. References: <000001c175bb$87227100$0c00a8c0@internet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mahdavi wrote: > > Hi. > > Imagine an IPSEC armed router. As any knows routers have interfaces. > Each interface may be IPSEC enabled or not( Am I right !!?? ). > > Upon arrival of any packet to router which serries of task must be > done on the acket? > > 1- Inbound , Outbound and then Routing. > 2- Inbound , Routing and then Outbound. > 3- Routing , inbound and then Outbound. > > each of these configuration has weaknesses. > > a)-in case 1 there is high probability danger of denial of service for > protected subnetwork when at least one of routers interfaces is IPSEC > unarmed. > b)-case 2 has logical flaw. After Outbound process new packet will be > made with new IP header. so this needs routing again. > c)- case 3 means that IPSEC Process must be done after Routing. this > has spoofing danger. > > now what configuration is correct or may be I have a basic > missundrestanding. > > best regars > > mahdavi Howdy, Try this... InBound/OutBound, Rounting, InBound/OutBound, Rounting, InBound/OutBound .... untill you have a packet which may pass an interface without further IPsec processing. Of course, such an implementation may turn out to be rather slow in typical traffic patterns. I'm sure it is possible to read the standards and not come up with such a pesimistic view of their meaning. And I'm sure that most vendors do not recurse through policy applications until a 'pass' rule is met for traffic. But, (IMHO) this turns out not to have all that much impact on interoperability. Its a behavour contained entirley within your system and does not impact your peer. So, your are left to implementers discresion in this area. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Mon Nov 26 11:11:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQJBp827425; Mon, 26 Nov 2001 11:11:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29056 Mon, 26 Nov 2001 13:08:42 -0500 (EST) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: Call for Agenda Items... Phone: (781) 391-3464 Message-Id: Date: Mon, 26 Nov 2001 13:17:37 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a call for proposed agenda items for the IPSEC meeting at Salt Lake City. We have a number of proposed items on the Agenda already (see below); if you have other suggestions for the working group to tackle while we're together at SLC, please send them to me and Barbara. Please note that presentations of topics that haven't yet been discussed on the working group mailing list are strongly discuouraged. If there's something that you'd like to present at SLC, the chances that Barbara and I will schedule go up immensely if the proposal has already been submitted as an I-D, and if there has been intelligent discussion of said proposal on the mailing list. :-) - Ted Proposed IPSEC agenda items for SLC =================================== *) SCTP/IPsec draft (angelos); 5 minutes *) Revised ESP (Karen Seo, Steve Kent) *) IPsec performance: I have a bunch of measurements with/without a crypto accelerator on OpenBSD, and comparative numbers for SSL, SCP/SFTP on software; this is a "response" to the argument on the mailing list about performance issues. Basically, I can trivially get 150Mb/s 3DES-SHA1 with a $300 PCI card, and there is no reason why this cannot be made to go faster (in theory, up to 300Mb/s --- but that's iffy) --- angelos; 10 minutes *) discuss the "suggested ID" draft (draft-keromytis-ike-id-00.txt) --- angelos or Bill Sommerfeld; 5 minutes Son-Of-IKE discussion ===================== *) Requirements document (Cheryl Madson) *) discuss the JFK draft (angelos, steve bellovin); 20 minutes *) IKE V2 (Radia, Dan Harkins) *) a taxonomy of desirable properties of an exchange (identity hiding of initiator, identity hiding of responder, statelessness, parallel computation of Diffie-Hellman, ability to easily fit in new key types in the future, ability to negotiate crypto algorithms, ...) and perhaps a comparison of IKEv2, JFK, and various variants of each that might have different desirable properties. (Charlie Kaufman) *) IKE-SIGMA (Hugo) From owner-ipsec@lists.tislabs.com Mon Nov 26 11:13:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQJDQ827488; Mon, 26 Nov 2001 11:13:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29091 Mon, 26 Nov 2001 13:13:18 -0500 (EST) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: Attempt to restart IPSEC MIB discussion.... Phone: (781) 391-3464 Message-Id: Date: Mon, 26 Nov 2001 13:22:39 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Now that we've had a few weeks to cool off, I'd like to try to restart the IPSEC MIB discussion, hopefully on a more technically substantive level than we had a few weeks ago. As a starting point, I'd like to refer folks to a message which John Shriver posted to the list on November 8th. It was by far the most technically substantive message posted on this thread for many weeks, and naturally, it attracted no responses. :-) I'd like to encourage those people who have argued both in favor and against the flow monitoring MIB to thoughtly look at John's comments and arguments, and to respond in a like manner. Many thanks!! - Ted From: "Shriver, John" To: ipsec@lists.tislabs.com Cc: "Shriver, John" , rks@cisco.com, "'Leo Temoshenko'" Subject: discussion of IPsec MIB requirements and goals, and my review of IPsec Flow Monitoring MIB Date: Thu, 8 Nov 2001 14:10:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Status: RO Content-Length: 14533 Lines: 274 OK, I have finally had a chance to do a thoughtful review of the IPsec Flow Monitoring MIB. Took a while until I could take the time away from pressing deliverables to do so. Now I can participate in an informed discussion. (This is a LONG message.) I should start with how I got involved in the IPsec MIB. It was a combination of two things. One, I was working at Shiva with BBN on a proprietary IPsec MIB for a product I was then involved with. Two, I saw Tim Jenkins' MIB work, and saw that it showed a lot of work, but didn't meet BBN's criteria (lots of artificial indices), and it really didn't meet David Perkins' "MIB design rules". (For those who are designing SNMP MIBs, "Understanding SNMP MIBs" is a must-read.) So, I started providing lots of comments to Tim. I was about the only person commenting. So many comments that Tim offered to make me a co-author, which I accepted. There were a set of criteria that we developed as we worked on the MIB. I think I can put most of them in a list here: 1. Well-formed by Perkins' criteria. 2. Meaningful indices on tables wherever possible, rather than synthetic indexes (starting at 1). 3. Ability to look things up directly via an index, rather than a table search, wherever possible. 4. Layered. Start with IPsec, since that's mandatory. Then ISAKMP, since it was a protocol in its own right. Then IKE on top of ISAKMP. 5. Augment rows wherever possible when going up through the MIB documents/layers. Some are full formal AUGMENTS, others are sparse augmentation, which isn't formally expressable in SMIv2. 6. Extensible without having to change the base MIB. No assignments of IPsec magic numbers by the IANA should break or obsolete the MIB. (The magic numbers are what I have in the Textual-Conventions MIB, which would be updated by the IANA after release.) If you don't do this, the MIBs will never reach Full Standard, because they will always be tracking new assignments. (Consider the frustrating fate of the dot3 MIB, trying to keep up with the IEEE defining new flavors of Ethernet.) 7. Allow what the IPsec specifications allow, rather than limiting the MIB to current conventional IPsec useage. 8. Minimize revealing much more than you could learn by sniffing the wire. While there are parts of the MIB which deserve access controls, there's nothing SENSITIVE like keys in it. 9. There should be MIBs for the raw IPsec unidirectional security associations. 10. Allow key negotiations other than IKE to be supported over ISAKMP. 11. Avoid counters that could help a cracker tell if they finally found the right value in a keyspace search. (Things like authentication error counters, etc.) Even more so with traps. 12. Be careful about the length of OID's, especially large index variables. 13. Try and make all index variables definite-length, to avoid the pain of having to insert the length sub-identifier and sort by it. 14. Maximize compatibility with management via SNMPv1 with SMIv1. Basically, be stingy with Counter64, and careful about the Notification OIDs. One frustration that we had was the hopeless generality of the IPsec specifications. There was little "pruning" of the requirements before switching to the protocol development stage. Thus IPsec is everything to everyone. An example of this is identities for Phase 2 key exchanges in IKE. In the spec, the number space is the same one used for Phase 1 key exchanges in ISAKMP. But many of these make absolutely no sense in Phase 2. Like what would "user fully-qualified domain name" mean in this context? In reality, only the address-based identities make sense in this context. When we were trying to add identities to the Phase 2 tables, we queried the list as to whether we could assume that they would always be one of the address types? Someone authoritatively replied "no". I think it was Dan Harkins, who at that time did not like the idea of putting any restrictions on IKE. (I do think Dan's viewpoint has shifted...) The same sort of problem came up trying to build a table of ISAKMP Phase 1 associations. It would be simple to just do it by the two IP addresses. But, because the ISAKMP/IKE specs do not resolve how to handle collision of establishment of Phase 1 associations, even whether to consider tearing one down, one is forced to add the two cookies as indexes, as that is the only way to uniquely identify the connections. So, as I note, the rambling generality of IPsec's specifications complicates MIB writing, if you want to write a MIB to the spec, rather than to what people just happen to be doing today. Now, one of the underlying assumptions I made above is probably non-functional now. That is the layering of ISAKMP and IKE into separate layers. If I understand the intent of the working group correctly these days, the intent is to merge them into one specification now, and to remove ISAKMP's support for any protocol other than IKE. If this is the case, and the assignment of ISAKMP magic numbers is being frozen, I can definitely see that it would be fully appropriate for us to merge our ISAKMP and IKE MIBs, removing a bunch of obsolete columns from the ISAKMP part. Since almost all the tables are augmenting, this will greatly reduce the number of tables. But, we need strong assurances that this would be the right direction to go in! So, now let's wander through the IPsec Flow Monitoring MIB, and consider the design problems in it. Consider section 4, bullet 1. This is about the need to modity ipSecEndPtTable to support a new identity type, based on SCTP. This table corresponds to our selectorTable (IPsec Monitoring MIB). The difference is that selectorTable returns the raw data from the IKE negotiation, with a Ident Type and raw identity data. No attempt is made at pretty formatting. Nor did we reduce this to supporting only the identity types that were meaningful in this context. The ipSecEndPtTable does make the assumption that only the address based identity types made any sense. (I somewhat agree with that.) But, then it gets skewered on my design goal 6 above, as adding a new identity type breaks it. Neither solution is really pretty, the raw ID's are a pain to parse, the change tracking is a loser too. Perhaps it could be like my group table, there is a table for each ID type, with the correct rows, and the base table has a "pointer" to the right table/row to describe the identity. As for section 4, bullet 4, this brings up the need to layer things. This MIB should not be changed to support NAT and IPsec over UDP. These should be layered MIBs, hopefully done by AUGMENTing existing rows in the final IPsec MIBs. We know that the hard part of SNMP instruementation is generating the table index data structures for efficient GET and GET-NEXT operations, so that if multiple SNMP table share the same set of indices, you aren't repeating the "hard" part of the code. To the MIB text proper. The IkePeerType TC is very similar to the InetAddressType in RFC 2851, "Textual Conventions for Internet Network Addresses". I think we're pretty much mandated to use that MIB when we are putting IP addresses into other MIBs. However, there is one type there which isn't an IP address, which is id_dn (I presume X.500 Distinguished Name). However, this is the core a bunch of serious MIB problems, which are discussed later. I don't see why TruthValue isn't suitable instead of defining TrapStatus. The Flow Monitoring MIB's ikaGlobalStats section is very much like our isakmpNegStats and IkeGlobals. But, it has a lot of very intersting counters. These are very well considered counters, obviously added due to very real-world issues. These are a very valuable contribution to the whole MIB discussion. Perhaps a little effort is in order making the definitions of these counters a little more rigorous? However, I'm a little worried (for security reasons) about ikeGlobalAuthFails. Could be too useful to a cracker. Then, I come to another one of the layering issues. The Flow Monitoring MIB appears to include support for the XAUTH and config-mode protocols, starting at ikeGlobalInXauthFailures. While I know as much as anyone that these expired Internet-Drafts are expired, at present they are not on the standards track. Each should be implemented in a seperate MIB, which at present would have to remain proprietary. I don't think the working group wants to MIBify protocols which they couldn't reach consensus on. The Flow Monitoring MIB ikePeerTable runs into a structural problem. It can't be validly implemented. The reason is that when ikePeerLocalType and/or ikePeerRemoteType is id_dn, ikePeerLocalValue and/or ikePeerRemoteValue may very readily be so long that the Object Identifier will exceed the maximum number of sub-identifiers (230 if I remember). Moreover, having these indexes be indefinite-length strings invokes the annoying requirement of a sub-identifier of length in the OID/index. This is why our IKE MIB has the ikeEndpointTable. This is a table of endpoints, indexed by an arbitrary indexes (violating our own no-search rules), containing the endpoint data. Then we can use this arbitrary index to index other tables that need to be indexed by endpoint. It wasn't something we were very happy with, but for Phase 1 identities, there really wasn't any other choice for valid SNMP SMIv2. Another problem with the id-dn identity type is that you haven't documented the encoding of the related value. Is it in DER? If I remember right, there are some knotty issues about certs with the same name, but coded in different language, and whether they are the same or different... Also, the coding of ikePeerLocalType and ikePeerRemoteType is too limited. While there are real restraints on Phase 2 identity types, there are no restrictions on Phase 1 identity types. I don't think that "user FDQN" or "X.500 GeneralName" or "IP V6 address range" have been deprecated yet. (See IpsecDoiIdentType in the DOI Textual Conventions MIB.) Meanwhile, there's no way short of table search to find an IKE Phase 1 SA by the IP addresses. We have that in index of the saTable in the ISAKMP MIB, and it's sparsely-augmented partner ikeSaTable in the IKE MIB. There are also bunch of helper tables in our MIBs (some of which could be made optional), that let you find the Phase 1 SA's created by particular peers, etc. As noted before, the ikePeerTable has a bunch of config-mode entries that need to be bumped up to a separte proprietary MIB. I do appreciate the purpose of the separation of ikePeerTable and ikeTunnelTable. This makes sense, and could be applied to our structure. But, ikeTunnelTable should be indexed by address types/addresses/cookies. The variable ikeTunDiffHellmanGrp does not allow for private groups or as-yet-undefined groups), yet IKE does. Unless IKE Version 2 plans to delete this, I think my saOakleyGroupDesc/saOakleyGroup variables meet the goal of supporting what the spec allows. It also avoids obsolescence problems. Remember that the supporting modpGroupTable, ecpGroupTable and ec2nGroupTable are only required if you actually choose to support negotiating new groups. I wonder why ikeTunStatus has a syntax of TunnelStatus, it could also have a restricted version of RowStatus instead, which might let management stations present it better. The counters of exchange types at the end of this table, starting with ikeTunInNewGrpRequests, and proceeding into more config-mode counter variables, again shows why I did the exchangeTable. Here, new exchange types just instantiate new index values, and no MIB changes are needed when you do things like add Config-Mode. ikePeerCorrTable has the same problem as before of supporting X.500 DistinguishedName strings as indices. Otherwise, it is the same concept as our suiteByCreatorsTable, but with different indices. I do like the various "Wraps" counters, such as ipSecGlobalInOctWraps, that's a nice way to provide SNMPv1 compatability. I do not view IPCOMP as part of IPsec, I would propose that the IPCOMP variables, such as ipSecGlobalInDecompOctets belongs in a IPCOMP MIB. The ipsecTunnelTable is essentially equivalent to our suiteTable. Both have an arbitrary index, as a proper index is just ridiculously long and complicated. The major difference is that suiteTable has references to rows in the IPsec MIB, for each of the raw SA's that make up a tunnel/suite. The Flow Monitoring MIB has flattened this out. I will admit that it is a perfectly valid topic to discuss whether there should be a MIB like the IPsec Monitoring MIB. Perhaps at current network/crypto bandwidths, these rows would be created and destroyed so fast that (1) they would vanish before you chased a reference to them and (2) it would be a computational burden updating the table indices all the time. Perhaps flattening the most essential elements into a higher level MIB is a better solution. On the other hand, how does one monitor a static-SA/static-key only IPsec/IPv4 implementation, which is perfectly valid? (Of course, it also makes for a rather useless product...) Also, I think that ipSecTunelTable assumes that only the canonical three transformations are used, in the canonical order. (Is this a restriction that Son-of-IKE will impose?) The ipSecEndPtTable was discussed earlier, how it cannot be stable with the introduction of new Phase 2 ID types. The ipSecSaTable is similar to our phase2SaTable, but folds in a bit of the IPsec Monitoring MIB. I presume that the intent here is to allow listing the raw SAs in the order that they are applied? I really don't have any issues with the history tables. They are a most interesting idea. They also could be in a MIB by themselves. They could be resource-intensive... I haven't looked at the notifications yet. Hopefully none can be used by key-crackers on a "traffic analysis" basis. I think by the time one changes the indices on the tables that have "structural problems", and allow more extensibility, the tables start to look a lot like the ones Tim and I have been working on for a few years. I think if we prune some things, maybe merge ISAKMP/IKE, and decide if we want an IPsec proper MIB, we can merge the excellent counters with the basic table strategy that has been evolving over two years. The claim that there are "major differences" doesn't ring completely true to me. There are many key similarities, often hidden by different terminology. From owner-ipsec@lists.tislabs.com Mon Nov 26 11:14:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQJEa827520; Mon, 26 Nov 2001 11:14:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29085 Mon, 26 Nov 2001 13:10:42 -0500 (EST) Date: Mon, 26 Nov 2001 13:19:33 -0500 (EST) From: Henry Spencer To: Michael Thomas cc: Hugo Krawczyk , ipsec list Subject: Re: SOI: identity protection and DOS In-Reply-To: <15362.31215.577809.622607@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Nov 2001, Michael Thomas wrote: > If you allow for pre-shared keys, then it clearly > requires an extra message or two. "If I hit myself on the head with a hammer, it hurts." The fix is obvious: sort out some simple zero-infrastructure authentication approach -- manually-shared raw public keys, simple self-signed certificates, whatever -- and forget shared secrets. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 26 11:16:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQJGq827610; Mon, 26 Nov 2001 11:16:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29117 Mon, 26 Nov 2001 13:17:07 -0500 (EST) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: WG LAST CALL: draft-ietf-ipsec-sctp-02.txt Phone: (781) 391-3464 Message-Id: Date: Mon, 26 Nov 2001 13:26:13 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been somewhat remiss in starting the WG last call on this document, for which I offer Angelos my most sincere apologies (a job search and a few other distractions got in the way). But, there's no time like the present, and the document is done, so even though it's just before the SLC IETF meeting, I'd like to start a one week working group last call on the IPSEC/SCTP document. Assuming that no issues are turned up during this last call, the document will be forwarded to the Secretariat and IETF for advancement as a Proposed Standard. - Ted From owner-ipsec@lists.tislabs.com Mon Nov 26 11:23:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQJNi827774; Mon, 26 Nov 2001 11:23:44 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA29136 Mon, 26 Nov 2001 13:20:22 -0500 (EST) From: "Theodore Ts'o" To: ipsec@lists.tislabs.com Subject: LAST CALL: NAT TRAVERSAL DRAFTS Phone: (781) 391-3464 Message-Id: Date: Mon, 26 Nov 2001 13:29:18 -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd also like to call a one week working group last call on the following documents relating to IPSEC NAT Traversal: draft-ietf-ipsec-udp-encaps-01.txt draft-ietf-ipsec-nat-t-ike-01.txt draft-ietf-ipsec-udp-encaps-justification-00.txt The first two documents are planned to be advanced as a Proposed Standard, and the last document is planned to be advanced as an Informational RFC. If there are no issues arising from this last call, these documents will be forwarded to the Secretariat and IESG for advancement. - Ted From owner-ipsec@lists.tislabs.com Mon Nov 26 12:32:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQKWD802773; Mon, 26 Nov 2001 12:32:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29500 Mon, 26 Nov 2001 14:39:59 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Theodore Ts'o" To: Subject: LAST CALL: NAT TRAVERSAL DRAFTS Phone: (781) 391-3464 Message-ID: Date: Mon, 26 Nov 2001 13:29:18 -0500 X-OriginalArrivalTime: 26 Nov 2001 19:49:31.0828 (UTC) FILETIME=[77722F40:01C176B3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd also like to call a one week working group last call on the following documents relating to IPSEC NAT Traversal: draft-ietf-ipsec-udp-encaps-01.txt draft-ietf-ipsec-nat-t-ike-01.txt draft-ietf-ipsec-udp-encaps-justification-00.txt The first two documents are planned to be advanced as a Proposed Standard, and the last document is planned to be advanced as an Informational RFC. If there are no issues arising from this last call, these documents will be forwarded to the Secretariat and IESG for advancement. - Ted From owner-ipsec@lists.tislabs.com Mon Nov 26 12:33:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQKX9802913; Mon, 26 Nov 2001 12:33:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29469 Mon, 26 Nov 2001 14:34:40 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Theodore Ts'o" To: Subject: Call for Agenda Items... Phone: (781) 391-3464 Message-ID: Date: Mon, 26 Nov 2001 13:17:37 -0500 X-OriginalArrivalTime: 26 Nov 2001 19:44:10.0515 (UTC) FILETIME=[B7EDB630:01C176B2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a call for proposed agenda items for the IPSEC meeting at Salt Lake City. We have a number of proposed items on the Agenda already (see below); if you have other suggestions for the working group to tackle while we're together at SLC, please send them to me and Barbara. Please note that presentations of topics that haven't yet been discussed on the working group mailing list are strongly discuouraged. If there's something that you'd like to present at SLC, the chances that Barbara and I will schedule go up immensely if the proposal has already been submitted as an I-D, and if there has been intelligent discussion of said proposal on the mailing list. :-) - Ted Proposed IPSEC agenda items for SLC =================================== *) SCTP/IPsec draft (angelos); 5 minutes *) Revised ESP (Karen Seo, Steve Kent) *) IPsec performance: I have a bunch of measurements with/without a crypto accelerator on OpenBSD, and comparative numbers for SSL, SCP/SFTP on software; this is a "response" to the argument on the mailing list about performance issues. Basically, I can trivially get 150Mb/s 3DES-SHA1 with a $300 PCI card, and there is no reason why this cannot be made to go faster (in theory, up to 300Mb/s --- but that's iffy) --- angelos; 10 minutes *) discuss the "suggested ID" draft (draft-keromytis-ike-id-00.txt) --- angelos or Bill Sommerfeld; 5 minutes Son-Of-IKE discussion ===================== *) Requirements document (Cheryl Madson) *) discuss the JFK draft (angelos, steve bellovin); 20 minutes *) IKE V2 (Radia, Dan Harkins) *) a taxonomy of desirable properties of an exchange (identity hiding of initiator, identity hiding of responder, statelessness, parallel computation of Diffie-Hellman, ability to easily fit in new key types in the future, ability to negotiate crypto algorithms, ...) and perhaps a comparison of IKEv2, JFK, and various variants of each that might have different desirable properties. (Charlie Kaufman) *) IKE-SIGMA (Hugo) From owner-ipsec@lists.tislabs.com Mon Nov 26 12:37:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQKbJ803429; Mon, 26 Nov 2001 12:37:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29525 Mon, 26 Nov 2001 14:43:39 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Theodore Ts'o" To: Subject: Attempt to restart IPSEC MIB discussion.... Phone: (781) 391-3464 Message-ID: Date: Mon, 26 Nov 2001 13:22:39 -0500 X-OriginalArrivalTime: 26 Nov 2001 19:52:37.0562 (UTC) FILETIME=[E626F1A0:01C176B3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Now that we've had a few weeks to cool off, I'd like to try to restart the IPSEC MIB discussion, hopefully on a more technically substantive level than we had a few weeks ago. As a starting point, I'd like to refer folks to a message which John Shriver posted to the list on November 8th. It was by far the most technically substantive message posted on this thread for many weeks, and naturally, it attracted no responses. :-) I'd like to encourage those people who have argued both in favor and against the flow monitoring MIB to thoughtly look at John's comments and arguments, and to respond in a like manner. Many thanks!! - Ted From: "Shriver, John" To: ipsec@lists.tislabs.com Cc: "Shriver, John" , rks@cisco.com, "'Leo Temoshenko'" Subject: discussion of IPsec MIB requirements and goals, and my review of IPsec Flow Monitoring MIB Date: Thu, 8 Nov 2001 14:10:10 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Status: RO Content-Length: 14533 Lines: 274 OK, I have finally had a chance to do a thoughtful review of the IPsec Flow Monitoring MIB. Took a while until I could take the time away from pressing deliverables to do so. Now I can participate in an informed discussion. (This is a LONG message.) I should start with how I got involved in the IPsec MIB. It was a combination of two things. One, I was working at Shiva with BBN on a proprietary IPsec MIB for a product I was then involved with. Two, I saw Tim Jenkins' MIB work, and saw that it showed a lot of work, but didn't meet BBN's criteria (lots of artificial indices), and it really didn't meet David Perkins' "MIB design rules". (For those who are designing SNMP MIBs, "Understanding SNMP MIBs" is a must-read.) So, I started providing lots of comments to Tim. I was about the only person commenting. So many comments that Tim offered to make me a co-author, which I accepted. There were a set of criteria that we developed as we worked on the MIB. I think I can put most of them in a list here: 1. Well-formed by Perkins' criteria. 2. Meaningful indices on tables wherever possible, rather than synthetic indexes (starting at 1). 3. Ability to look things up directly via an index, rather than a table search, wherever possible. 4. Layered. Start with IPsec, since that's mandatory. Then ISAKMP, since it was a protocol in its own right. Then IKE on top of ISAKMP. 5. Augment rows wherever possible when going up through the MIB documents/layers. Some are full formal AUGMENTS, others are sparse augmentation, which isn't formally expressable in SMIv2. 6. Extensible without having to change the base MIB. No assignments of IPsec magic numbers by the IANA should break or obsolete the MIB. (The magic numbers are what I have in the Textual-Conventions MIB, which would be updated by the IANA after release.) If you don't do this, the MIBs will never reach Full Standard, because they will always be tracking new assignments. (Consider the frustrating fate of the dot3 MIB, trying to keep up with the IEEE defining new flavors of Ethernet.) 7. Allow what the IPsec specifications allow, rather than limiting the MIB to current conventional IPsec useage. 8. Minimize revealing much more than you could learn by sniffing the wire. While there are parts of the MIB which deserve access controls, there's nothing SENSITIVE like keys in it. 9. There should be MIBs for the raw IPsec unidirectional security associations. 10. Allow key negotiations other than IKE to be supported over ISAKMP. 11. Avoid counters that could help a cracker tell if they finally found the right value in a keyspace search. (Things like authentication error counters, etc.) Even more so with traps. 12. Be careful about the length of OID's, especially large index variables. 13. Try and make all index variables definite-length, to avoid the pain of having to insert the length sub-identifier and sort by it. 14. Maximize compatibility with management via SNMPv1 with SMIv1. Basically, be stingy with Counter64, and careful about the Notification OIDs. One frustration that we had was the hopeless generality of the IPsec specifications. There was little "pruning" of the requirements before switching to the protocol development stage. Thus IPsec is everything to everyone. An example of this is identities for Phase 2 key exchanges in IKE. In the spec, the number space is the same one used for Phase 1 key exchanges in ISAKMP. But many of these make absolutely no sense in Phase 2. Like what would "user fully-qualified domain name" mean in this context? In reality, only the address-based identities make sense in this context. When we were trying to add identities to the Phase 2 tables, we queried the list as to whether we could assume that they would always be one of the address types? Someone authoritatively replied "no". I think it was Dan Harkins, who at that time did not like the idea of putting any restrictions on IKE. (I do think Dan's viewpoint has shifted...) The same sort of problem came up trying to build a table of ISAKMP Phase 1 associations. It would be simple to just do it by the two IP addresses. But, because the ISAKMP/IKE specs do not resolve how to handle collision of establishment of Phase 1 associations, even whether to consider tearing one down, one is forced to add the two cookies as indexes, as that is the only way to uniquely identify the connections. So, as I note, the rambling generality of IPsec's specifications complicates MIB writing, if you want to write a MIB to the spec, rather than to what people just happen to be doing today. Now, one of the underlying assumptions I made above is probably non-functional now. That is the layering of ISAKMP and IKE into separate layers. If I understand the intent of the working group correctly these days, the intent is to merge them into one specification now, and to remove ISAKMP's support for any protocol other than IKE. If this is the case, and the assignment of ISAKMP magic numbers is being frozen, I can definitely see that it would be fully appropriate for us to merge our ISAKMP and IKE MIBs, removing a bunch of obsolete columns from the ISAKMP part. Since almost all the tables are augmenting, this will greatly reduce the number of tables. But, we need strong assurances that this would be the right direction to go in! So, now let's wander through the IPsec Flow Monitoring MIB, and consider the design problems in it. Consider section 4, bullet 1. This is about the need to modity ipSecEndPtTable to support a new identity type, based on SCTP. This table corresponds to our selectorTable (IPsec Monitoring MIB). The difference is that selectorTable returns the raw data from the IKE negotiation, with a Ident Type and raw identity data. No attempt is made at pretty formatting. Nor did we reduce this to supporting only the identity types that were meaningful in this context. The ipSecEndPtTable does make the assumption that only the address based identity types made any sense. (I somewhat agree with that.) But, then it gets skewered on my design goal 6 above, as adding a new identity type breaks it. Neither solution is really pretty, the raw ID's are a pain to parse, the change tracking is a loser too. Perhaps it could be like my group table, there is a table for each ID type, with the correct rows, and the base table has a "pointer" to the right table/row to describe the identity. As for section 4, bullet 4, this brings up the need to layer things. This MIB should not be changed to support NAT and IPsec over UDP. These should be layered MIBs, hopefully done by AUGMENTing existing rows in the final IPsec MIBs. We know that the hard part of SNMP instruementation is generating the table index data structures for efficient GET and GET-NEXT operations, so that if multiple SNMP table share the same set of indices, you aren't repeating the "hard" part of the code. To the MIB text proper. The IkePeerType TC is very similar to the InetAddressType in RFC 2851, "Textual Conventions for Internet Network Addresses". I think we're pretty much mandated to use that MIB when we are putting IP addresses into other MIBs. However, there is one type there which isn't an IP address, which is id_dn (I presume X.500 Distinguished Name). However, this is the core a bunch of serious MIB problems, which are discussed later. I don't see why TruthValue isn't suitable instead of defining TrapStatus. The Flow Monitoring MIB's ikaGlobalStats section is very much like our isakmpNegStats and IkeGlobals. But, it has a lot of very intersting counters. These are very well considered counters, obviously added due to very real-world issues. These are a very valuable contribution to the whole MIB discussion. Perhaps a little effort is in order making the definitions of these counters a little more rigorous? However, I'm a little worried (for security reasons) about ikeGlobalAuthFails. Could be too useful to a cracker. Then, I come to another one of the layering issues. The Flow Monitoring MIB appears to include support for the XAUTH and config-mode protocols, starting at ikeGlobalInXauthFailures. While I know as much as anyone that these expired Internet-Drafts are expired, at present they are not on the standards track. Each should be implemented in a seperate MIB, which at present would have to remain proprietary. I don't think the working group wants to MIBify protocols which they couldn't reach consensus on. The Flow Monitoring MIB ikePeerTable runs into a structural problem. It can't be validly implemented. The reason is that when ikePeerLocalType and/or ikePeerRemoteType is id_dn, ikePeerLocalValue and/or ikePeerRemoteValue may very readily be so long that the Object Identifier will exceed the maximum number of sub-identifiers (230 if I remember). Moreover, having these indexes be indefinite-length strings invokes the annoying requirement of a sub-identifier of length in the OID/index. This is why our IKE MIB has the ikeEndpointTable. This is a table of endpoints, indexed by an arbitrary indexes (violating our own no-search rules), containing the endpoint data. Then we can use this arbitrary index to index other tables that need to be indexed by endpoint. It wasn't something we were very happy with, but for Phase 1 identities, there really wasn't any other choice for valid SNMP SMIv2. Another problem with the id-dn identity type is that you haven't documented the encoding of the related value. Is it in DER? If I remember right, there are some knotty issues about certs with the same name, but coded in different language, and whether they are the same or different... Also, the coding of ikePeerLocalType and ikePeerRemoteType is too limited. While there are real restraints on Phase 2 identity types, there are no restrictions on Phase 1 identity types. I don't think that "user FDQN" or "X.500 GeneralName" or "IP V6 address range" have been deprecated yet. (See IpsecDoiIdentType in the DOI Textual Conventions MIB.) Meanwhile, there's no way short of table search to find an IKE Phase 1 SA by the IP addresses. We have that in index of the saTable in the ISAKMP MIB, and it's sparsely-augmented partner ikeSaTable in the IKE MIB. There are also bunch of helper tables in our MIBs (some of which could be made optional), that let you find the Phase 1 SA's created by particular peers, etc. As noted before, the ikePeerTable has a bunch of config-mode entries that need to be bumped up to a separte proprietary MIB. I do appreciate the purpose of the separation of ikePeerTable and ikeTunnelTable. This makes sense, and could be applied to our structure. But, ikeTunnelTable should be indexed by address types/addresses/cookies. The variable ikeTunDiffHellmanGrp does not allow for private groups or as-yet-undefined groups), yet IKE does. Unless IKE Version 2 plans to delete this, I think my saOakleyGroupDesc/saOakleyGroup variables meet the goal of supporting what the spec allows. It also avoids obsolescence problems. Remember that the supporting modpGroupTable, ecpGroupTable and ec2nGroupTable are only required if you actually choose to support negotiating new groups. I wonder why ikeTunStatus has a syntax of TunnelStatus, it could also have a restricted version of RowStatus instead, which might let management stations present it better. The counters of exchange types at the end of this table, starting with ikeTunInNewGrpRequests, and proceeding into more config-mode counter variables, again shows why I did the exchangeTable. Here, new exchange types just instantiate new index values, and no MIB changes are needed when you do things like add Config-Mode. ikePeerCorrTable has the same problem as before of supporting X.500 DistinguishedName strings as indices. Otherwise, it is the same concept as our suiteByCreatorsTable, but with different indices. I do like the various "Wraps" counters, such as ipSecGlobalInOctWraps, that's a nice way to provide SNMPv1 compatability. I do not view IPCOMP as part of IPsec, I would propose that the IPCOMP variables, such as ipSecGlobalInDecompOctets belongs in a IPCOMP MIB. The ipsecTunnelTable is essentially equivalent to our suiteTable. Both have an arbitrary index, as a proper index is just ridiculously long and complicated. The major difference is that suiteTable has references to rows in the IPsec MIB, for each of the raw SA's that make up a tunnel/suite. The Flow Monitoring MIB has flattened this out. I will admit that it is a perfectly valid topic to discuss whether there should be a MIB like the IPsec Monitoring MIB. Perhaps at current network/crypto bandwidths, these rows would be created and destroyed so fast that (1) they would vanish before you chased a reference to them and (2) it would be a computational burden updating the table indices all the time. Perhaps flattening the most essential elements into a higher level MIB is a better solution. On the other hand, how does one monitor a static-SA/static-key only IPsec/IPv4 implementation, which is perfectly valid? (Of course, it also makes for a rather useless product...) Also, I think that ipSecTunelTable assumes that only the canonical three transformations are used, in the canonical order. (Is this a restriction that Son-of-IKE will impose?) The ipSecEndPtTable was discussed earlier, how it cannot be stable with the introduction of new Phase 2 ID types. The ipSecSaTable is similar to our phase2SaTable, but folds in a bit of the IPsec Monitoring MIB. I presume that the intent here is to allow listing the raw SAs in the order that they are applied? I really don't have any issues with the history tables. They are a most interesting idea. They also could be in a MIB by themselves. They could be resource-intensive... I haven't looked at the notifications yet. Hopefully none can be used by key-crackers on a "traffic analysis" basis. I think by the time one changes the indices on the tables that have "structural problems", and allow more extensibility, the tables start to look a lot like the ones Tim and I have been working on for a few years. I think if we prune some things, maybe merge ISAKMP/IKE, and decide if we want an IPsec proper MIB, we can merge the excellent counters with the basic table strategy that has been evolving over two years. The claim that there are "major differences" doesn't ring completely true to me. There are many key similarities, often hidden by different terminology. From owner-ipsec@lists.tislabs.com Mon Nov 26 12:37:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQKbs803530; Mon, 26 Nov 2001 12:37:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29506 Mon, 26 Nov 2001 14:40:37 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 From: "Theodore Ts'o" To: Subject: WG LAST CALL: draft-ietf-ipsec-sctp-02.txt Phone: (781) 391-3464 Message-ID: Date: Mon, 26 Nov 2001 13:26:13 -0500 X-OriginalArrivalTime: 26 Nov 2001 19:49:56.0359 (UTC) FILETIME=[86115170:01C176B3] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've been somewhat remiss in starting the WG last call on this document, for which I offer Angelos my most sincere apologies (a job search and a few other distractions got in the way). But, there's no time like the present, and the document is done, so even though it's just before the SLC IETF meeting, I'd like to start a one week working group last call on the IPSEC/SCTP document. Assuming that no issues are turned up during this last call, the document will be forwarded to the Secretariat and IETF for advancement as a Proposed Standard. - Ted From owner-ipsec@lists.tislabs.com Mon Nov 26 12:39:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQKdq803784; Mon, 26 Nov 2001 12:39:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA29512 Mon, 26 Nov 2001 14:41:29 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <15362.31215.577809.622607@thomasm-u1.cisco.com> References: <15362.31215.577809.622607@thomasm-u1.cisco.com> Date: Mon, 26 Nov 2001 11:49:58 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: SOI: identity protection and DOS Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:20 AM -0800 11/26/01, Michael Thomas wrote: > If you allow for pre-shared keys, then it clearly > requires an extra message or two. Which is why we > should determine what the actual requirement is > re pre-shared keys. If it's a requirement, then > we need to confront the time/protection tradeoff. > If it's not a requirement, this mostly vanishes. Positive traits of IKEv1 pre-shared keys: a) easy for each party to set up b) not susceptible to CRL time lag or CA key compromise c) fewer exponentiations on each side for IPsec key setup Negative traits of IKEv1 pre-shared keys: d) hard to scale e) unless identity protection is not needed, the initiator must be at known IP address, and there must be only one pre-shared key at that address f) out-of-band swapping of the key must be done privately If what is most important is (a) and (b), and the problem of (d) is not important, both the JFK and IKEv2 implementations can be trivially set up for this by allowing one or both sides to use self-signed certificates, where the other side has trusted the public key in the certificate using some out-of-band mechanism. In JFK and IKEv2 using this method, you don't get advantage (c), but you don't have disadvantage (e) or (f). Thus, for the scenarios of "quick interop testing" and "a WAN made up of a handful of gateways", JFK and IKEv2 already work just fine if the implementations allow for trusting self-signed certs based on key hashes. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Nov 26 12:51:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQKp5804233; Mon, 26 Nov 2001 12:51:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29594 Mon, 26 Nov 2001 15:00:09 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 Nov 2001 15:09:35 -0500 Message-Id: <20011126200935.19BDE7B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Paul Hoffman / VPNC writes : >At 9:20 AM -0800 11/26/01, Michael Thomas wrote: >> If you allow for pre-shared keys, then it clearly >> requires an extra message or two. Which is why we >> should determine what the actual requirement is >> re pre-shared keys. If it's a requirement, then >> we need to confront the time/protection tradeoff. >> If it's not a requirement, this mostly vanishes. > >Positive traits of IKEv1 pre-shared keys: >a) easy for each party to set up >b) not susceptible to CRL time lag or CA key compromise >c) fewer exponentiations on each side for IPsec key setup > >Negative traits of IKEv1 pre-shared keys: >d) hard to scale >e) unless identity protection is not needed, the initiator must be at >known IP address, and there must be only one pre-shared key at that >address >f) out-of-band swapping of the key must be done privately > >If what is most important is (a) and (b), and the problem of (d) is >not important, both the JFK and IKEv2 implementations can be >trivially set up for this by allowing one or both sides to use >self-signed certificates, where the other side has trusted the public >key in the certificate using some out-of-band mechanism. In JFK and >IKEv2 using this method, you don't get advantage (c), but you don't >have disadvantage (e) or (f). Or even IKEv1 -- and that's precisely the point. Using certificates does *not* require existence of a PKI, or even a pki. (That's the great lesson of ssh, btw -- it's very easy to deploy something based on exchanging public keys, without dragging any central authority into the picture.) You do have the exponentiations; what that buys you (apart from simplicity of the protocol) is protection of authentication material in event of peer compromise. That is, I can hand Alice and Bob the same public key for me. If Bob is compromised, that does not allow the attacker to impersonate me when talking to Alice. To do that with pre-shared symmetric keys, I'd have to have a separate key for each correspondent, and (depending on just how those keys were employed) I might have to worry about MITM attacks. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Mon Nov 26 13:21:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQLL8805349; Mon, 26 Nov 2001 13:21:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29705 Mon, 26 Nov 2001 15:19:34 -0500 (EST) Date: Mon, 26 Nov 2001 15:28:29 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: SOI: identity protection and DOS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Nov 2001, Paul Hoffman / VPNC wrote: > Positive traits of IKEv1 pre-shared keys: > a) easy for each party to set up > b) not susceptible to CRL time lag or CA key compromise > c) fewer exponentiations on each side for IPsec key setup You forgot: bb) no supporting CA/CRL infrastructure required One might consider that to fall under (a), but I think it's important enough to merit separate comment. In simple situations or for small specialized implementations, minimizing the weight of infrastructure can be a significant advantage even when the setup effort would be considered acceptable. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Nov 26 14:07:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQM77807140; Mon, 26 Nov 2001 14:07:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA29863 Mon, 26 Nov 2001 16:07:52 -0500 (EST) Date: Mon, 26 Nov 2001 23:16:37 +0200 From: Sara Bitan Subject: Re: SOI: identity protection and DOS To: Michael Thomas , Henry Spencer Cc: ipsec list Message-id: <004501c176bf$a3763a30$ec4c5ac2@commagine.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <15362.31215.577809.622607@thomasm-u1.cisco.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Pre-shared keys do not require extra messages. The P-SIGMA protocol requires just three messages, like SIGMA. I think pre-shared keys authentication is a requirement, and it doesn't necessary imply huge overhead. There are several good (and popular) protocols out there that supply shared keys to two parties. I know that in the real world certificates are not as popular and widely used as we would like them to be. An insecure certificates deployment will be much more harmful that a *correct* and useful pre-shared key authentication mode. Sara ----- Original Message ----- From: Michael Thomas To: Hugo Krawczyk Cc: Derek Atkins ; ipsec list Sent: Monday, November 26, 2001 7:20 PM Subject: Re: SOI: identity protection and DOS > Hugo Krawczyk writes: > > On 20 Nov 2001, Derek Atkins wrote: > > [...] > > > > > > I happen to agree with Radia's point that you should try to protect > > > the initiator's identity before the responder's identity (which > > > implies the responder should authenticate to the initiator first). > > > Yes, this implies an extra round trip, but if the initiator wants to > > > protect their identity they should have the choice to do so. > > > > > > > No, it does NOT imply an extra round trip. It is the other way around. > > Protecting the initiator from active attacker takes just 3 messages. > > Protecting the responder takes 4. > > See the SIGMA draft > > (http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt) > > If you allow for pre-shared keys, then it clearly > requires an extra message or two. Which is why we > should determine what the actual requirement is > re pre-shared keys. If it's a requirement, then > we need to confront the time/protection tradeoff. > If it's not a requirement, this mostly vanishes. > > Mike From owner-ipsec@lists.tislabs.com Mon Nov 26 14:58:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQMwY810258; Mon, 26 Nov 2001 14:58:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29995 Mon, 26 Nov 2001 17:01:24 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman / VPNC'" , Subject: RE: SOI: identity protection and DOS Date: Mon, 26 Nov 2001 17:06:54 -0500 Message-ID: <003501c176c6$aa5fece0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Some comments on this: (e) is only due to a flaw in IKEv1, and is unrelated to the use of preshared keys in general. (f) is not really valid because you need an out-of-band mechanism either way. (d) is the real reason for not using preshared keys. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Monday, November 26, 2001 2:50 PM > To: ipsec@lists.tislabs.com > Subject: Re: SOI: identity protection and DOS > > > At 9:20 AM -0800 11/26/01, Michael Thomas wrote: > > If you allow for pre-shared keys, then it clearly > > requires an extra message or two. Which is why we > > should determine what the actual requirement is > > re pre-shared keys. If it's a requirement, then > > we need to confront the time/protection tradeoff. > > If it's not a requirement, this mostly vanishes. > > Positive traits of IKEv1 pre-shared keys: > a) easy for each party to set up > b) not susceptible to CRL time lag or CA key compromise > c) fewer exponentiations on each side for IPsec key setup > > Negative traits of IKEv1 pre-shared keys: > d) hard to scale > e) unless identity protection is not needed, the initiator must be at > known IP address, and there must be only one pre-shared key at that > address > f) out-of-band swapping of the key must be done privately > > If what is most important is (a) and (b), and the problem of (d) is > not important, both the JFK and IKEv2 implementations can be > trivially set up for this by allowing one or both sides to use > self-signed certificates, where the other side has trusted the public > key in the certificate using some out-of-band mechanism. In JFK and > IKEv2 using this method, you don't get advantage (c), but you don't > have disadvantage (e) or (f). > > Thus, for the scenarios of "quick interop testing" and "a WAN made up > of a handful of gateways", JFK and IKEv2 already work just fine if > the implementations allow for trusting self-signed certs based on key > hashes. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Mon Nov 26 15:31:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQNVY811917; Mon, 26 Nov 2001 15:31:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00097 Mon, 26 Nov 2001 17:30:56 -0500 (EST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <003501c176c6$aa5fece0$1e72788a@andrewk3.ca.newbridge.com> References: <003501c176c6$aa5fece0$1e72788a@andrewk3.ca.newbridge.com> Date: Mon, 26 Nov 2001 14:40:08 -0800 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: RE: SOI: identity protection and DOS Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:06 PM -0500 11/26/01, Andrew Krywaniuk wrote: > > Positive traits of IKEv1 pre-shared keys: >> a) easy for each party to set up >> b) not susceptible to CRL time lag or CA key compromise >> c) fewer exponentiations on each side for IPsec key setup >> >> Negative traits of IKEv1 pre-shared keys: >> d) hard to scale >> e) unless identity protection is not needed, the initiator must be at >> known IP address, and there must be only one pre-shared key at that >> address > > f) out-of-band swapping of the key must be done privately > > >Some comments on this: > >(e) is only due to a flaw in IKEv1, and is unrelated to the use of preshared >keys in general. Yup. Some people think that identity protection is absolutely needed in every circumstance, but most people would agree that identity protection isn't worth preventing pre-shared secrets from working with mobile users. >(f) is not really valid because you need an out-of-band mechanism either >way. Not true. You only need a authenticated transport for the public key hashes: you don't have to keep them private. >(d) is the real reason for not using preshared keys. ...for some people. In many environments, scaling is not an an issue. It is easy to argue that setting up simple CA and keeping its key secret and issuing CRLs and so on for a 5-gateway WAN is more difficult that passing around five preshared secrets on the phone. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Nov 26 15:39:49 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQNdm812113; Mon, 26 Nov 2001 15:39:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA00122 Mon, 26 Nov 2001 17:44:57 -0500 (EST) Mime-Version: 1.0 X-Sender: karen.seo@po1.bbn.com Message-Id: Date: Mon, 26 Nov 2001 17:58:28 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: new Internet Draft -- IP Encapsulating Security Payload (ESP) Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Just a follow-up to the IETF announcement of the new draft (now available in the Internet Drafts directories as draft-ietf-ipsec-esp-v3-01.txt)....This draft differs from the previous ESP spec (RFC 2406) as follows: o Confidentiality-only service -- now a SHOULD, not a MUST. o SPI -- modified to better reflect the differences between unicast and multicast SA lookups. For unicast, the SPI may be used alone to select an SA; for multicast, the SPI is combined with destination address to select an SA. o Sequence number -- added a new option for a 64-bit sequence number for very high-speed communications. o Payload data -- broadened model to accommodate combined mode algorithms. o Padding for improved traffic flow confidentiality -- added requirement to be able to add bytes after the end of the IP Payload, prior to the beginning of the Padding field. o Next Header -- added requirement to be able to generate and discard dummy padding packets (Next Header = 59) o ICV -- broadened model to accommodate combined mode algorithms. o Algorithms -- Added combined confidentiality mode algorithms. o Inbound and Outbound packet processing -- there are now two paths -- (1) separate confidentiality and integrity algorithms, (2) combined confidentiality mode algorithms. Because of the addition of combined mode algorithms, the encryption/decryption and integrity sections have been combined for both inbound and outbound packet processing. Thank you, Karen From owner-ipsec@lists.tislabs.com Mon Nov 26 15:57:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAQNvQ813740; Mon, 26 Nov 2001 15:57:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00236 Mon, 26 Nov 2001 18:09:16 -0500 (EST) Date: Tue, 27 Nov 2001 01:18:56 +0200 (IST) From: Hugo Krawczyk To: Dan Harkins cc: IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: <200111261211.fAQCBRL00559@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Nov 2001, Dan Harkins wrote: > Hugo, > > Thanks for pointing this out. It is our intent that the integrity > check in ESP be mandatory when ESP is protecting IKEv2 messages. > The peers sign each D-H exponential and each nonce and SKEYID_a, > derived from the D-H exponentials and the nonces, is used as the > key to the ESP integrity check. I think some wordsmithing in Appendix > B is in order. > Dan, while you can formally "solve" the immediate security issue by rewording Appendix B, I believe that the design weakness still stays there after the re-wording: As I said in my note, I believe (and hope that you agree) that A TRULY SOUND KEY EXCHANGE PROTOCOL SHOULD NOT RELY ON EXTERNAL MECHANISMS TO PROVIDE ITS MOST ESSENTIAL SECURITY PROPERTIES In particular, the protocol MUST DEFINE ITS OWN AUTHENTICATION MECHANISMS. By using ESP for the AUTHENTICITY of the protocol you are violating this principle. This is no just a dogmatic approach to design. I can see many things going wrong by using ESP. I am attaching at the end a sample list of 7 different specific weaknesses due to reliance on ESP. (I am moving this long list to the end for the benefit of the rushing readers; however, anyone that is interested in the REAL SECURITY of these protocols should seriously consider these subtle but essential issues). Now, Dan, what makes this discussion quite unnecessary is that you are not gaining anything by resorting to an external authentication mechanism! You can do it RIGHT and at the same processing/performance/complexity cost (or less)! Hugo PS: On the inappropriateness of using ESP for providing authentication in IKEv2 - seven examples (please, read them seriously) (1) authentication in ESP is optional (as we said, IKEv2 should mandate its use with STRONG integrity protection); (2) the specification of ESP, or its underlying assumptions (such as MUST vs MAY), may change one day without relation to its use in IKE in a way that will compromise IKE's security (this concern would be valid even for a stable protocol, more so for ESP whose version 3 was just posted) (3) already now IKEv2 VIOLATES one of the current assumptions of ESP: IKEv2 uses the same SKEYSEED_a/e in both directions while ESP ASSUMES unidirectional keys for protecting traffic. This violation can easily break a perfectly secure ESP mechanism (stream ciphers are an example). [Yes, I know that can be re-specified too in IKEv2, but that is not the point] (4) since the session identifier contained in HDR is NOT included under the ESP scope, the the binding between the key and party IDs to the specific session is not fully achieved. This is important when several simultaneous sessions between the same peers are run (which is certainly a case that IKE should care about). (5) the application of ESP in IKEv2 is mainly motivated by a secondary security requirement, namely identity protection, and the essential role of ESP in protocol authentication is not made explicit in the protocol design; (6) This "obscurity" may cause seemingly unrelated changes in the protocol to break its security. For example, if one eventually decides to make ID protection optional (this happened in the past to both Photuris and IKEv1 -- the latter via aggressive mode) then the WHOLE security of IKEv2 is compromised (7) more subtle, seemingly unrelated changes in the protocol may turn the protocol insecure. An example: Assume that we decide (and I would suggest doing that) to add an optional identity payload in the first message from I to R (similar to the field OIDii in SIGMA) to facilitate R's policy decisions from the start of the protocol (e.g. to help deciding on SA responses). Then someone (that does not need ID protection) could send IDi in this first message and omit it from message 3. Apparently, this should not change the protocol security but it DOES. In this case the integrity transform of ESP will NOT be applied to IDi and the security of the protocol would be BROKEN. This is subtle, true and dangerous... On Mon, 26 Nov 2001, Dan Harkins wrote: > Hugo, > > Thanks for pointing this out. It is our intent that the integrity > check in ESP be mandatory when ESP is protecting IKEv2 messages. > The peers sign each D-H exponential and each nonce and SKEYID_a, > derived from the D-H exponentials and the nonces, is used as the > key to the ESP integrity check. I think some wordsmithing in Appendix > B is in order. > > Dan. > > On Mon, 26 Nov 2001 13:28:56 +0200 you wrote > > > > Namely, the protocol does not achieve a strong cryptographic binding > > between the exchanged DH key and the party identities (an essential security > > requirement put forth by the STS paper [DVW]). > > > > This can be indirectly achieved in IKEv2 via ESP if one MANDATES > > strong integrity in ESP (otherwise integrity is optional in ESP), > > but even then a truly sound key exchange protocol should not rely on > > external mechanisms to provide the most essential security properties > > (in contrast, using ESP for id protection is perectly reasonable). > > > > The solution to this problem is quite simple: put back the prf (or HASH) > > computation under the signature; a detailed specification can be found in > > my recent SIGMA proposal [SIGMA]. > From owner-ipsec@lists.tislabs.com Mon Nov 26 16:17:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAR0Hs814312; Mon, 26 Nov 2001 16:17:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00330 Mon, 26 Nov 2001 18:25:18 -0500 (EST) Date: Tue, 27 Nov 2001 01:34:58 +0200 (IST) From: Hugo Krawczyk To: IPsec WG Subject: On shared keys (was RE: SOI: identity protection and DOS) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Everyone agrees that public key is the ONLY way to a scalable Internet-wide protocol. No question about it. In particular, any key-exchange protocol for IPsec MUST provide a PK-based exchange. This, however, does not mean that shared keys are bad. Nor it means that shared-key techniques are less secure than PK ones. (Actually, one can argue that in the context of ipsec that already needs to trust shared key mechanisms to secure data, the addition of PK at the level of key-exchange is just adding a possible weak link -- and for all we know PK may be a WEAK link...) Anyway, we need PK techniques for scalability not for security. And one more and important (in my view) observation: The reason people distrust shared keys so much is that they perceive shared-keys as synonyms for "manual installation" and "passwords". They forget that there are MANY important and practical scenarios where a STRONG securely shared key is easily available. In these cases, not using them is a waste. Hugo On Mon, 26 Nov 2001, Paul Hoffman / VPNC wrote: > At 5:06 PM -0500 11/26/01, Andrew Krywaniuk wrote: > > > Positive traits of IKEv1 pre-shared keys: > >> a) easy for each party to set up > >> b) not susceptible to CRL time lag or CA key compromise > >> c) fewer exponentiations on each side for IPsec key setup > >> > >> Negative traits of IKEv1 pre-shared keys: > >> d) hard to scale > >> e) unless identity protection is not needed, the initiator must be at > >> known IP address, and there must be only one pre-shared key at that > >> address > > > f) out-of-band swapping of the key must be done privately > > > > > >Some comments on this: > > > >(e) is only due to a flaw in IKEv1, and is unrelated to the use of preshared > >keys in general. > > Yup. Some people think that identity protection is absolutely needed > in every circumstance, but most people would agree that identity > protection isn't worth preventing pre-shared secrets from working > with mobile users. > > >(f) is not really valid because you need an out-of-band mechanism either > >way. > > Not true. You only need a authenticated transport for the public key > hashes: you don't have to keep them private. > > >(d) is the real reason for not using preshared keys. > > ...for some people. In many environments, scaling is not an an issue. > It is easy to argue that setting up simple CA and keeping its key > secret and issuing CRLs and so on for a 5-gateway WAN is more > difficult that passing around five preshared secrets on the phone. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Mon Nov 26 16:20:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAR0K9814364; Mon, 26 Nov 2001 16:20:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00348 Mon, 26 Nov 2001 18:28:01 -0500 (EST) Date: Tue, 27 Nov 2001 01:37:13 +0200 (IST) From: Hugo Krawczyk To: Michael Thomas cc: Derek Atkins , ipsec list Subject: Re: SOI: identity protection and DOS In-Reply-To: <15362.31215.577809.622607@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael, I don't understand what pre-shared keys have to do with my comment as you cite. Let me repeat and clarify my previous comment: in a signature-based authentication mode it is CHEAPER (in term of number of messages in the protocol) to protect the initiator's identity than the responder's against active attacks. Protecting the initiator can be done in 3 messages (as in SIGMA), protecting the responder takes at least 4 (as in IKEv2). How many messages it takes to protect BOTH identities against active attacks? The answer is: it is IMPOSSIBLE to do so in a signature-based protocol. And since you mention shared-keys, an advantage they have over a signature mode is that you can achieve protection of BOTH identities against active attackers and at the price of just three messages (see P-SIGMA). Hugo On Mon, 26 Nov 2001, Michael Thomas wrote: > Hugo Krawczyk writes: > > On 20 Nov 2001, Derek Atkins wrote: > > [...] > > > > > > I happen to agree with Radia's point that you should try to protect > > > the initiator's identity before the responder's identity (which > > > implies the responder should authenticate to the initiator first). > > > Yes, this implies an extra round trip, but if the initiator wants to > > > protect their identity they should have the choice to do so. > > > > > > > No, it does NOT imply an extra round trip. It is the other way around. > > Protecting the initiator from active attacker takes just 3 messages. > > Protecting the responder takes 4. > > See the SIGMA draft > > (http://www.ee.technion.ac.il/~hugo/draft-krawczyk-ipsec-ike-sigma-00.txt) > > If you allow for pre-shared keys, then it clearly > requires an extra message or two. Which is why we > should determine what the actual requirement is > re pre-shared keys. If it's a requirement, then > we need to confront the time/protection tradeoff. > If it's not a requirement, this mostly vanishes. > > Mike > From owner-ipsec@lists.tislabs.com Mon Nov 26 16:56:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAR0ub814980; Mon, 26 Nov 2001 16:56:37 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00528 Mon, 26 Nov 2001 19:00:38 -0500 (EST) Date: Tue, 27 Nov 2001 02:10:20 +0200 (IST) From: Hugo Krawczyk To: Dan Harkins cc: IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: <200111261441.fAQEfVL00735@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dan, Let me answer to two main points. Other issues can be discussed in another opportunity (it is 2am here:) I have good news and bad news for you: (1) *Good news* I think that the use of ESP in Appendix B instead of the complex language of IKE's appendix B is a GOOD THING. I recommend keeping it. HOWEVER, as I already said, use it ONLY for the purpose of ID PROTECTION (not for protocol authentication)!!! For KEY-EXCHNAGE AUTHENTICATION all you need to add is a prf-ed HASH! That is straigthforward to specify (I already did in few lines) and requires no change in Appendix B. (2) *Bad news* In response to my example (7) you write: > > In this case IDi would be signed by each party. Since you're proposing > putting all things, including IDi, into the signed hash anyway why is it > dangerous to add just IDi to the mix of exponentials and nonces? > IT IS VERY DANGEROUS! DOING WHAT YOU SUGGEST IS INSECURE! That's the whole point. These things are NOT intuitive! (Or become intuitive only after years of formal analysis of protocols) I have said this since 1995: SIGNING YOUR OWN ID IS NOT ENOUGH: YOU MUST APPLY TO THE ID A PRF (OR MAC) KEYED WITH THE DH KEY!!! Hugo PS: an angry comment at 2 AM: some people recommend using 8000-bit DH exponents for security, but we can easily accept key exchange protocols with flawed authentication! :( On Mon, 26 Nov 2001, Dan Harkins wrote: > On Tue, 27 Nov 2001 01:18:56 +0200 you wrote > > > > Now, Dan, what makes this discussion quite unnecessary is that you are not > > gaining anything by resorting to an external authentication mechanism! > > You can do it RIGHT and at the same processing/performance/complexity > > cost (or less)! > > We were gaining is losing lots of text describing a separate magic number > space, chaining of IVs, padding, all that stuff that's in IKEv1 that is > much better described in ESP. > > > Hugo > > > > PS: On the inappropriateness of using ESP for providing authentication > > in IKEv2 - seven examples (please, read them seriously) > > > > (1) authentication in ESP is optional (as we said, IKEv2 should mandate > > its use with STRONG integrity protection); > > That can be solved by wordsmithing of Appendix B. > > > (2) the specification of ESP, or its underlying assumptions (such as MUST > > vs MAY), may change one day without relation to its use in IKE in a way that > > will compromise IKE's security (this concern would be valid even for a stable > > protocol, more so for ESP whose version 3 was just posted) > > This is a good point. > > > (3) already now IKEv2 VIOLATES one of the current assumptions of ESP: > > IKEv2 uses the same SKEYSEED_a/e in both directions while ESP > > ASSUMES unidirectional keys for protecting traffic. This violation > > can easily break a perfectly secure ESP mechanism (stream ciphers are an > > example). > > [Yes, I know that can be re-specified too in IKEv2, but that is not the point > >] > > If the bidirectional nature of the key is not a problem then it should not > matter where the specification is for how data is padded and formatted. > (assuming of course that that specification does not change in a way that > affects IKE-- point 2 above). > > > (4) since the session identifier contained in HDR is NOT included under > > the ESP scope, the the binding between the key and party IDs to the specific > > session is not fully achieved. This is important when several simultaneous > > sessions between the same peers are run (which is certainly a case > > that IKE should care about). > > It is. Appendix B says, "Whereas in ESP the header that is integrity > protected but not encrypted is a total of 8 bytes (SPI+Sequence #) > plus the IV, in IKE it is the IKE Header which is 28 bytes plus the > IV (see section 7.1)." > > > (5) the application of ESP in IKEv2 is mainly motivated by a secondary > > security requirement, namely identity protection, and the essential role > > of ESP in protocol authentication is not made explicit in the protocol design > >; > > No, it's motivated by the desire to make things simpler. There is very well > written text (which very few people have a problem understanding) describing > how to pad, encrypt, and authenticate a message which we'd like to refer to. > IKEv2 can repeat this text if such an in situ definition is required but > if it's not then it is convenient to refer to other text. > > > (6) This "obscurity" may cause seemingly unrelated changes in the protocol > > to break its security. For example, if one eventually decides to make > > ID protection optional (this happened in the past to both Photuris > > and IKEv1 -- the latter via aggressive mode) then the WHOLE security of > > IKEv2 is compromised > > I'm sorry, I'm not following. This is not ID protection related. It is > a specification of how to pad, encrypt, and authenticate a blob of bits. > IKEv2 could specify it itself but instead it refers to another specification. > > > (7) more subtle, seemingly unrelated changes in the protocol may turn the > > protocol insecure. An example: > > Assume that we decide (and I would suggest doing that) to add an optional > > identity payload in the first message from I to R (similar to the field OIDii > > in SIGMA) to facilitate R's policy decisions from the start of the protocol > > (e.g. to help deciding on SA responses). Then someone (that does not need > > ID protection) could send IDi in this first message and omit it from > > message 3. Apparently, this should not change the protocol security > > but it DOES. In this case the integrity transform of ESP will NOT be applied > > to IDi and the security of the protocol would be BROKEN. > > This is subtle, true and dangerous... > > In this case IDi would be signed by each party. Since you're proposing > putting all things, including IDi, into the signed hash anyway why is it > dangerous to add just IDi to the mix of exponentials and nonces? > > Dan. > > > From owner-ipsec@lists.tislabs.com Mon Nov 26 17:04:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAR14p815128; Mon, 26 Nov 2001 17:04:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00572 Mon, 26 Nov 2001 19:09:38 -0500 (EST) Date: Tue, 27 Nov 2001 02:19:24 +0200 (IST) From: Hugo Krawczyk To: Dan Harkins cc: IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: <200111261454.fAQEsnL00769@fatty.lounge.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk SIGMA does need these specifications and the draft explicitly says that the description is NOT intended to represent a complete specification. I wrote this draft with the idea of providing "son-of-ike" with SECURE, SIMPLE, INEXPENSIVE cryptographic mechanisms. At the same time (I did not know of the advanced stage of your new draft) you did a great work in creating the necessary surrounding specifications. I do NOT consider IKEv2 and SIGMA as competing proposals but rather as excellent complementary work ready to be merged. Hugo On Mon, 26 Nov 2001, Dan Harkins wrote: > Hugo, > > On Tue, 27 Nov 2001 01:18:56 +0200 you wrote > > > > (2) the specification of ESP, or its underlying assumptions (such as MUST > > vs MAY), may change one day without relation to its use in IKE in a way that > > will compromise IKE's security (this concern would be valid even for a stable > > protocol, more so for ESP whose version 3 was just posted) > > SIGMA refers to RFC2409 in the same manner and for the same reason that > IKEv2 refers to RFC2406. > > Don't you think that SIGMA should completely define its method of padding, > encryption, and IV generation itself and not rely on a specification which > may change one day? > > Dan. > > > From owner-ipsec@lists.tislabs.com Mon Nov 26 18:46:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAR2kk817082; Mon, 26 Nov 2001 18:46:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00942 Mon, 26 Nov 2001 20:55:51 -0500 (EST) To: Sara Bitan Cc: Michael Thomas , Henry Spencer , ipsec list Subject: Re: SOI: identity protection and DOS References: <15362.31215.577809.622607@thomasm-u1.cisco.com> <004501c176bf$a3763a30$ec4c5ac2@commagine.net> From: Derek Atkins Date: 26 Nov 2001 21:05:06 -0500 In-Reply-To: Sara Bitan's message of "Mon, 26 Nov 2001 23:16:37 +0200" Message-ID: Lines: 20 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sara, Sara Bitan writes: > I think pre-shared keys authentication is a requirement, and it doesn't > necessary imply huge overhead. There are several good (and popular) Do you mean pre-shared secret-key or pre-shared public-key? I happen to agree with Steve that pre-shared public-key is sufficient (and probably superior) to pre-shared secret-key authentication. In other words, we pre-share RSA Public Keys. No certificates are necessarily required. As was pointed out, see SSH for an example of how this works. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 27 00:37:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAR8bR827444; Tue, 27 Nov 2001 00:37:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01386 Tue, 27 Nov 2001 02:23:46 -0500 (EST) Message-ID: <3C0341B8.9E55F691@F-Secure.com> Date: Tue, 27 Nov 2001 09:33:12 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Derek Atkins CC: Sara Bitan , Michael Thomas , Henry Spencer , ipsec list Subject: Re: SOI: identity protection and DOS References: <15362.31215.577809.622607@thomasm-u1.cisco.com> <004501c176bf$a3763a30$ec4c5ac2@commagine.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2001 07:33:09.0053 (UTC) FILETIME=[C2DF7ED0:01C17715] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins wrote: > Do you mean pre-shared secret-key or pre-shared public-key? I happen > to agree with Steve that pre-shared public-key is sufficient (and > probably superior) to pre-shared secret-key authentication. In other > words, we pre-share RSA Public Keys. No certificates are necessarily > required. As was pointed out, see SSH for an example of how this > works. I agree that pre-shared public key is sufficient, and argue that either one is necessary for at least easy testing. There's also one benefit to this not already mentioned (that I noticed), i.e. that "foobar" or "you'll never guess" are not public keys. Ari -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Tue Nov 27 03:34:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARBYg816610; Tue, 27 Nov 2001 03:34:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA01858 Tue, 27 Nov 2001 05:42:06 -0500 (EST) Message-Id: <200111271051.FAA17986@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ike-hash-revised-03.txt Date: Tue, 27 Nov 2001 05:51:31 -0500 Sender: owner-ipsec@lists.tislabs.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 : Fixing IKE Phase 1 & 2 Authentication HASH Author(s) : T. Kivinen Filename : draft-ietf-ipsec-ike-hash-revised-03.txt Pages : 6 Date : 26-Nov-01 This document defines new method of calculating the authentication HASH of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. The way the HASH is currently defined in the [RFC-2409] does not authen- ticate the ISAKMP [RFC-2408] packet header, nor does it authenticate any extra ISAKMP payloads inside phase 1 ISAKMP packets. This causes a secu- rity problem when using extra ISAKMP payloads as already defined in the IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). There is also suggestion how to fix the Phase 2 authentication hashes so that they will also authenticate the ISAKMP packet header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-hash-revised-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ike-hash-revised-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ike-hash-revised-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011126101330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ike-hash-revised-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ike-hash-revised-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011126101330.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Nov 27 04:55:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARCtf825541; Tue, 27 Nov 2001 04:55:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA02010 Tue, 27 Nov 2001 06:58:03 -0500 (EST) Message-Id: <3.0.3.32.20011127041016.00ef1ff8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 27 Nov 2001 04:10:16 -0800 To: "Steven M. Bellovin" , Paul Hoffman / VPNC From: Alex Alten Subject: Re: SOI: identity protection and DOS Cc: ipsec@lists.tislabs.com In-Reply-To: <20011126200935.19BDE7B55@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:09 PM 11/26/2001 -0500, Steven M. Bellovin wrote: ... > >Or even IKEv1 -- and that's precisely the point. Using certificates >does *not* require existence of a PKI, or even a pki. (That's the >great lesson of ssh, btw -- it's very easy to deploy something based on >exchanging public keys, without dragging any central authority into the >picture.) You do have the exponentiations; what that buys you (apart >from simplicity of the protocol) is protection of authentication >material in event of peer compromise. That is, I can hand Alice and >Bob the same public key for me. If Bob is compromised, that does not >allow the attacker to impersonate me when talking to Alice. To do that >with pre-shared symmetric keys, I'd have to have a separate key for >each correspondent, and (depending on just how those keys were >employed) I might have to worry about MITM attacks. > Steve, you have hit the nail right on the head as usual! I came to the conclusion about 6 months ago that the *only* feature that makes PK crypto worth having in establishing secure network communications is the ability to make a "leap of faith" about the other side's identity without having to worry about private key exposure. Otherwise, why bother with it? Especially if you need a central trusted 3rd party. Then a symmetric based system just blows away a PK based system in terms of price/performance and ease of implementation. BTW, once you allow "leap of faith" trust to be established at will within the system by peers then the scalability issue is no longer a problem. Of course access control or policy enforcement will need to be (re)designed with this type of trust model in mind. Maybe we should call this a Pretty Good Internet Key Exchange? (Hopefully this time I won't be accused of being anti-IKE or a Taliban sympathizer.) - Alex -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Tue Nov 27 06:19:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAREJ6803109; Tue, 27 Nov 2001 06:19:07 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02265 Tue, 27 Nov 2001 08:24:36 -0500 (EST) Message-Id: <200111261454.fAQEsnL00769@fatty.lounge.org> To: Hugo Krawczyk Cc: IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: Your message of "Tue, 27 Nov 2001 01:18:56 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <766.1006786489.1@tibernian.com> Date: Mon, 26 Nov 2001 06:54:49 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, On Tue, 27 Nov 2001 01:18:56 +0200 you wrote > > (2) the specification of ESP, or its underlying assumptions (such as MUST > vs MAY), may change one day without relation to its use in IKE in a way that > will compromise IKE's security (this concern would be valid even for a stable > protocol, more so for ESP whose version 3 was just posted) SIGMA refers to RFC2409 in the same manner and for the same reason that IKEv2 refers to RFC2406. Don't you think that SIGMA should completely define its method of padding, encryption, and IV generation itself and not rely on a specification which may change one day? Dan. From owner-ipsec@lists.tislabs.com Tue Nov 27 06:19:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAREJH803141; Tue, 27 Nov 2001 06:19:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02266 Tue, 27 Nov 2001 08:24:42 -0500 (EST) Message-Id: <200111261441.fAQEfVL00735@fatty.lounge.org> To: Hugo Krawczyk Cc: IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: Your message of "Tue, 27 Nov 2001 01:18:56 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <732.1006785690.1@tibernian.com> Date: Mon, 26 Nov 2001 06:41:31 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Nov 2001 01:18:56 +0200 you wrote > > Now, Dan, what makes this discussion quite unnecessary is that you are not > gaining anything by resorting to an external authentication mechanism! > You can do it RIGHT and at the same processing/performance/complexity > cost (or less)! We were gaining is losing lots of text describing a separate magic number space, chaining of IVs, padding, all that stuff that's in IKEv1 that is much better described in ESP. > Hugo > > PS: On the inappropriateness of using ESP for providing authentication > in IKEv2 - seven examples (please, read them seriously) > > (1) authentication in ESP is optional (as we said, IKEv2 should mandate > its use with STRONG integrity protection); That can be solved by wordsmithing of Appendix B. > (2) the specification of ESP, or its underlying assumptions (such as MUST > vs MAY), may change one day without relation to its use in IKE in a way that > will compromise IKE's security (this concern would be valid even for a stable > protocol, more so for ESP whose version 3 was just posted) This is a good point. > (3) already now IKEv2 VIOLATES one of the current assumptions of ESP: > IKEv2 uses the same SKEYSEED_a/e in both directions while ESP > ASSUMES unidirectional keys for protecting traffic. This violation > can easily break a perfectly secure ESP mechanism (stream ciphers are an > example). > [Yes, I know that can be re-specified too in IKEv2, but that is not the point >] If the bidirectional nature of the key is not a problem then it should not matter where the specification is for how data is padded and formatted. (assuming of course that that specification does not change in a way that affects IKE-- point 2 above). > (4) since the session identifier contained in HDR is NOT included under > the ESP scope, the the binding between the key and party IDs to the specific > session is not fully achieved. This is important when several simultaneous > sessions between the same peers are run (which is certainly a case > that IKE should care about). It is. Appendix B says, "Whereas in ESP the header that is integrity protected but not encrypted is a total of 8 bytes (SPI+Sequence #) plus the IV, in IKE it is the IKE Header which is 28 bytes plus the IV (see section 7.1)." > (5) the application of ESP in IKEv2 is mainly motivated by a secondary > security requirement, namely identity protection, and the essential role > of ESP in protocol authentication is not made explicit in the protocol design >; No, it's motivated by the desire to make things simpler. There is very well written text (which very few people have a problem understanding) describing how to pad, encrypt, and authenticate a message which we'd like to refer to. IKEv2 can repeat this text if such an in situ definition is required but if it's not then it is convenient to refer to other text. > (6) This "obscurity" may cause seemingly unrelated changes in the protocol > to break its security. For example, if one eventually decides to make > ID protection optional (this happened in the past to both Photuris > and IKEv1 -- the latter via aggressive mode) then the WHOLE security of > IKEv2 is compromised I'm sorry, I'm not following. This is not ID protection related. It is a specification of how to pad, encrypt, and authenticate a blob of bits. IKEv2 could specify it itself but instead it refers to another specification. > (7) more subtle, seemingly unrelated changes in the protocol may turn the > protocol insecure. An example: > Assume that we decide (and I would suggest doing that) to add an optional > identity payload in the first message from I to R (similar to the field OIDii > in SIGMA) to facilitate R's policy decisions from the start of the protocol > (e.g. to help deciding on SA responses). Then someone (that does not need > ID protection) could send IDi in this first message and omit it from > message 3. Apparently, this should not change the protocol security > but it DOES. In this case the integrity transform of ESP will NOT be applied > to IDi and the security of the protocol would be BROKEN. > This is subtle, true and dangerous... In this case IDi would be signed by each party. Since you're proposing putting all things, including IDi, into the signed hash anyway why is it dangerous to add just IDi to the mix of exponentials and nonces? Dan. From owner-ipsec@lists.tislabs.com Tue Nov 27 06:24:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAREOB803278; Tue, 27 Nov 2001 06:24:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02247 Tue, 27 Nov 2001 08:22:49 -0500 (EST) Message-Id: <200111261211.fAQCBRL00559@fatty.lounge.org> To: Hugo Krawczyk Cc: IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: Your message of "Mon, 26 Nov 2001 13:28:56 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <556.1006776687.1@tibernian.com> Date: Mon, 26 Nov 2001 04:11:27 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo, Thanks for pointing this out. It is our intent that the integrity check in ESP be mandatory when ESP is protecting IKEv2 messages. The peers sign each D-H exponential and each nonce and SKEYID_a, derived from the D-H exponentials and the nonces, is used as the key to the ESP integrity check. I think some wordsmithing in Appendix B is in order. Dan. On Mon, 26 Nov 2001 13:28:56 +0200 you wrote > > Namely, the protocol does not achieve a strong cryptographic binding > between the exchanged DH key and the party identities (an essential security > requirement put forth by the STS paper [DVW]). > > This can be indirectly achieved in IKEv2 via ESP if one MANDATES > strong integrity in ESP (otherwise integrity is optional in ESP), > but even then a truly sound key exchange protocol should not rely on > external mechanisms to provide the most essential security properties > (in contrast, using ESP for id protection is perectly reasonable). > > The solution to this problem is quite simple: put back the prf (or HASH) > computation under the signature; a detailed specification can be found in > my recent SIGMA proposal [SIGMA]. From owner-ipsec@lists.tislabs.com Tue Nov 27 06:25:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAREPX803308; Tue, 27 Nov 2001 06:25:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02272 Tue, 27 Nov 2001 08:25:35 -0500 (EST) X-Originating-IP: [198.4.92.5] From: "Prakash Jain" To: ipsec@lists.tislabs.com, nat@ietf.org Subject: ipsec/NAT query Date: Tue, 27 Nov 2001 09:11:04 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 27 Nov 2001 09:11:05.0341 (UTC) FILETIME=[7169E2D0:01C17723] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am new to both ipsec and NAT. I am facing some problem having ipsec with NAT. I want to know if both can work together when they are not on same box, for example, scenario is as follows, ipsec Router ipsec client ----------------box doing---------N/w cloud----- server (A) NAT (B ) (C) <---------------------ipsec tunnel from A to C---------------> I think tunneling can be supported thru NAT but not very sure about ipsec (and its flavour ESP/AH) in above scenarios. I have following queries, 1. Does NAT implementation require something specific to ipsec (ipsec-nat ALG??) in above scenario? 2. Does ipsec protocol/negotiation involve client's ipaddress in any way? 3. Can ipsec and NAT have generic compatible implemantations (say ipsec client and NAT are from different vendors) in above scenarios? 4. Please give some relevent links on the web for above info. I will appreciate an early reply. Thanks and regards, Prakash ---------- Get your FREE download of MSN Explorer at http://explorer.msn.com From owner-ipsec@lists.tislabs.com Tue Nov 27 07:19:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARFJD808156; Tue, 27 Nov 2001 07:19:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02495 Tue, 27 Nov 2001 09:19:11 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15363.41738.290718.340912@pkoning.dev.equallogic.com> Date: Tue, 27 Nov 2001 09:28:26 -0500 (EST) From: Paul Koning To: hugo@ee.technion.ac.il Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and SIGMA References: <200111261211.fAQCBRL00559@fatty.lounge.org> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> ... Hugo> As I said in my note, I believe (and hope that you agree) that Hugo> A TRULY SOUND KEY EXCHANGE PROTOCOL SHOULD NOT RELY ON EXTERNAL Hugo> MECHANISMS TO PROVIDE ITS MOST ESSENTIAL SECURITY PROPERTIES Hugo> In particular, the protocol MUST DEFINE ITS OWN AUTHENTICATION Hugo> MECHANISMS. I completely agree. Hugo> By using ESP for the AUTHENTICITY of the protocol you are Hugo> violating this principle. One good reason for insisting on this is that the ESP draft continues to permit -- and even encourage -- the known-insecure confidentiality-only mode. It's a good thing to see it change from "MUST" to "SHOULD" on that topic, but the right change is to "SHOULD NOT" and to mark that "feature" historic and deprecated. paul From owner-ipsec@lists.tislabs.com Tue Nov 27 09:13:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARHD4818720; Tue, 27 Nov 2001 09:13:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02836 Tue, 27 Nov 2001 10:58:12 -0500 (EST) Subject: Re: WG LAST CALL: draft-ietf-ipsec-sctp-02.txt To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Charles Kunzinger" Date: Tue, 27 Nov 2001 11:07:45 -0500 X-MIMETrack: Serialize by Router on D04NMS46/04/M/IBM(Release 5.0.8 |June 18, 2001) at 11/27/2001 11:07:32 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have two comments: 1. The formatting of the new ID_RECURSE is not yet defined, either in this draft or in the DOI (RFC 2407). I feel that the internet draft itself must include them explicitly--otherwise, interoperability of implementations can not be guaranteed. In particular, the interent draft should show the format used to list multiple "identities" within the payload of the "ID_RECURSE": that is, does each individual ID entity carry its own "type" and "length field". Stated differently, we need to specify the format for what RFC 2407 calls the "Identification Data" to be carried within the RECURSE_ID payload. (Of course, at some later date, the formats could be moved from the draft into the DOI and then be referenced in later versions of this draft.) 2. (Nit picking) The name "ID_RECURSE" implies recursion, which is not used to construct this payload. I would suggest using a name such as "ID_LIST", which is more indicative of how this new field would be used. ____________________________________________________ Charles A Kunzinger (kunzinge@us.ibm.com) Network Processor Architecture & Solutions (Dept 8NJV) Phone: Tie 444-4142, external 1-919-254-4142 Fax: Tie 441-3061, external 1-919-543-3061 From owner-ipsec@lists.tislabs.com Tue Nov 27 09:36:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARHaD820330; Tue, 27 Nov 2001 09:36:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02979 Tue, 27 Nov 2001 11:38:18 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15363.50043.499209.27907@thomasm-u1.cisco.com> Date: Tue, 27 Nov 2001 08:46:51 -0800 (PST) To: Paul Koning Cc: hugo@ee.technion.ac.il, ipsec@lists.tislabs.com Subject: Re: IKEv2 and SIGMA In-Reply-To: <15363.41738.290718.340912@pkoning.dev.equallogic.com> References: <200111261211.fAQCBRL00559@fatty.lounge.org> <15363.41738.290718.340912@pkoning.dev.equallogic.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Koning writes: > >>>>> "Hugo" == Hugo Krawczyk writes: > Hugo> ... > Hugo> As I said in my note, I believe (and hope that you agree) that > Hugo> A TRULY SOUND KEY EXCHANGE PROTOCOL SHOULD NOT RELY ON EXTERNAL > Hugo> MECHANISMS TO PROVIDE ITS MOST ESSENTIAL SECURITY PROPERTIES > > Hugo> In particular, the protocol MUST DEFINE ITS OWN AUTHENTICATION > Hugo> MECHANISMS. > > I completely agree. I have a hard time reconciling this with the modularity principle. Begging, borrowing and stealing is Good Thing, IMO. Mike From owner-ipsec@lists.tislabs.com Tue Nov 27 09:48:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARHms820995; Tue, 27 Nov 2001 09:48:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03059 Tue, 27 Nov 2001 11:53:15 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15363.50951.988003.42518@thomasm-u1.cisco.com> Date: Tue, 27 Nov 2001 09:01:59 -0800 (PST) To: Hugo Krawczyk Cc: IPsec WG Subject: On shared keys (was RE: SOI: identity protection and DOS) In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > Everyone agrees that public key is the ONLY way to a scalable > Internet-wide protocol. No question about it. In particular, > any key-exchange protocol for IPsec MUST provide a PK-based exchange. I don't think I agree if by Internet-wide you mean any-any scaling. I frankly don't think that such a thing exists, or is likely to exist. Thus while PK exchanges give many useful properties, enrollment, compromise, and administration are still problems for both. Indeed, the only thing in existence right now that scales to any appreciable degree is *not* based on asymmetric keys (GSM). It seems to scale well enough for its application and acceptible risk parameters. Mike From owner-ipsec@lists.tislabs.com Tue Nov 27 10:00:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARI0a821258; Tue, 27 Nov 2001 10:00:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03138 Tue, 27 Nov 2001 12:12:03 -0500 (EST) Message-Id: <3.0.3.32.20011127092421.00f70cd0@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 27 Nov 2001 09:24:21 -0800 To: Hugo Krawczyk , IPsec WG From: Alex Alten Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 01:34 AM 11/27/2001 +0200, Hugo Krawczyk wrote: >Everyone agrees that public key is the ONLY way to a scalable >Internet-wide protocol. No question about it. In particular, >any key-exchange protocol for IPsec MUST provide a PK-based exchange. > No. I STRONGLY disagree. I'll give a counter example. The banking ATM network uses DES keys. It has scaled, in practice, world wide. And BTW, it's security & trust model is excellent. Have you ever heard of a major compromise, say on the scale of 25,000 card #'s being stolen (like with Visa?). Certainly nobody distrusts it because it uses symmetric keys for authentication. In fact I'm certain YOU trust it at least a couple a times a month. :-) - Alex -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Tue Nov 27 10:02:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARI28821308; Tue, 27 Nov 2001 10:02:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03113 Tue, 27 Nov 2001 12:07:19 -0500 (EST) Date: Tue, 27 Nov 2001 19:16:18 +0200 (IST) From: Hugo Krawczyk To: Sara Bitan cc: Michael Thomas , Henry Spencer , ipsec list Subject: Re: SOI: identity protection and DOS In-Reply-To: <004501c176bf$a3763a30$ec4c5ac2@commagine.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think that this observation by Sara is important: > > An insecure certificates deployment will be much more harmful than a > *correct* and useful pre-shared key authentication mode." For those that cite SSH as an example: much of the success of SSL and SSH is based on the permissiveness with which people USE public keys and certificates in these protocols (who reads certificate-related pop-up warnings in https? how many consciously check a PK in a first SSH handshake?) We want IPsec to succeed but not to "imitate" the above SSL and SSH usage weaknesses. Hugo > > On Mon, 26 Nov 2001, Sara Bitan wrote: > > Pre-shared keys do not require extra messages. > The P-SIGMA protocol requires just three messages, like SIGMA. > > I think pre-shared keys authentication is a requirement, and it doesn't > necessary imply huge overhead. There are several good (and popular) > protocols out there that supply shared keys to two parties. > I know that in the real world certificates are not as popular and widely > used as we would like them to be. An insecure certificates deployment will > be much more harmful that a *correct* and useful pre-shared key > authentication mode. > > Sara From owner-ipsec@lists.tislabs.com Tue Nov 27 10:07:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARI7c821392; Tue, 27 Nov 2001 10:07:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03107 Tue, 27 Nov 2001 12:05:59 -0500 (EST) Date: Tue, 27 Nov 2001 19:14:54 +0200 (IST) From: Hugo Krawczyk To: Derek Atkins cc: Sara Bitan , Michael Thomas , Henry Spencer , ipsec list Subject: Re: SOI: identity protection and DOS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Specifying pre-shared (secret) key mechanism does not prevent (or impede) the use of manually installed certificates. It is just that the two things are NOT equivalent. ANY "manually installed", either with seret keys or certificates, is WEAK, as it requires a direct human intervention. It may be great for testing, and useful for fast-dirty security. (And, yes, for manual installation I prefer certs too -- at least they do not have secrecy protection requirements). However, here, we are talking about GOOD security with GOOD performance. It is in this domain where SHARED secret keys can be very useful. Examples: organizations where the authentication services are provided by a third party (a KDC, an authentication server, etc.) In those cases, providing a fresh, strong, authenticated shared secret key to both peers (e.g. a client and a gateway) is perfectly possible, secure and computationally cheaper. And I certainly do not have to tell you that these second and third-party type models are in widespread use today. They deserve a WELL-DESIGNED shared-key support in IKE. Hugo On 26 Nov 2001, Derek Atkins wrote: > Sara, > > Sara Bitan writes: > > > I think pre-shared keys authentication is a requirement, and it doesn't > > necessary imply huge overhead. There are several good (and popular) > > Do you mean pre-shared secret-key or pre-shared public-key? I happen > to agree with Steve that pre-shared public-key is sufficient (and > probably superior) to pre-shared secret-key authentication. In other > words, we pre-share RSA Public Keys. No certificates are necessarily > required. As was pointed out, see SSH for an example of how this > works. > > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Tue Nov 27 10:28:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARIS2821997; Tue, 27 Nov 2001 10:28:02 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03188 Tue, 27 Nov 2001 12:21:39 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15363.52653.888855.648786@thomasm-u1.cisco.com> Date: Tue, 27 Nov 2001 09:30:21 -0800 (PST) To: Ari Huttunen Cc: Derek Atkins , Sara Bitan , Michael Thomas , Henry Spencer , ipsec list Subject: Re: SOI: identity protection and DOS In-Reply-To: <3C0341B8.9E55F691@F-Secure.com> References: <15362.31215.577809.622607@thomasm-u1.cisco.com> <004501c176bf$a3763a30$ec4c5ac2@commagine.net> <3C0341B8.9E55F691@F-Secure.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ari Huttunen writes: > Derek Atkins wrote: > > Do you mean pre-shared secret-key or pre-shared public-key? I happen > > to agree with Steve that pre-shared public-key is sufficient (and > > probably superior) to pre-shared secret-key authentication. In other > > words, we pre-share RSA Public Keys. No certificates are necessarily > > required. As was pointed out, see SSH for an example of how this > > works. > > I agree that pre-shared public key is sufficient, and argue that either > one is necessary for at least easy testing. There's also one benefit > to this not already mentioned (that I noticed), i.e. that > "foobar" or "you'll never guess" are not public keys. It's probably worth tossing into the debate that KINK provides the ability to do third party as well as peer-peer[*] symmetric key SA establishment, which hopefully meets all of the other requirements. I'm sort of neutral about whether SOI should provide the ability to use pre-shared keys again, but unlike the first go-round of IKE, we do have a viable alternative if you like pre-shared keys. Mike [*] All that is needed to construct a peer to peer protocol out of KINK is to implement AS-REQ/TGS-REQ on the KINK peer and camp on port 88. From owner-ipsec@lists.tislabs.com Tue Nov 27 10:40:40 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARIee823556; Tue, 27 Nov 2001 10:40:40 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03351 Tue, 27 Nov 2001 12:40:58 -0500 (EST) From: Charlie_Kaufman@iris.com Subject: Re: IKEv2 and SIGMA To: Hugo Krawczyk Cc: IPsec WG X-Mailer: Lotus Notes Build M11_10312001 Beta 4 October 31, 2001 Message-ID: Date: Tue, 27 Nov 2001 12:36:12 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Release 5.0.8 |June 18, 2001) at 11/27/2001 12:43:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 26 Nov 2001, Hugo Krawczyk wrote: > I'd like to address one fundamental issue > related to the cryptographic soundness of the current design. > Namely, the protocol does not achieve a strong cryptographic binding > between the exchanged DH key and the party identities (an essential security > requirement put forth by the STS paper [DVW]). > > This can be indirectly achieved in IKEv2 via ESP if one MANDATES > strong integrity in ESP (otherwise integrity is optional in ESP), > but even then a truly sound key exchange protocol should not rely on > external mechanisms to provide the most essential security properties > (in contrast, using ESP for id protection is perectly reasonable). You're quite right; the spec should say that an integrity protection algorithm is mandatory (and it sort of does in Appendix B, but it should be more prominent and mentioned in the Security Considerations section). > > The solution to this problem is quite simple: put back the prf (or HASH) > computation under the signature; a detailed specification can be found in > my recent SIGMA proposal [SIGMA]. > This is certainly an alternative. As specified, the concatenation of the first two messages is signed, which had a certain elegance and ease of specification. But including additional fields under the hash would not be difficult. I believe that for the protection of Phase 2, it is necessary to make the integrity protection mandatory anyway. And I believe that if the integrity protection in ESP turns out to be inadequate, having a fix that works only for key management is of little value. How strongly do you feel that it's important? I prefer specifying the fields to be concatenated and signed rather than the HMAC construction because of the complexity of specifying signing an HMAC with DSS when DSS specifies that you must sign the SHA-1 of something. But this is only a specification challenge, not an implementation challenge, so if there is a good security reason to use the HMAC construction, we could do that too. > Moreover, I would recommend integrating the SIGMA protocol to the current > IKEv2 specification framework. This would have the effect of providing full > cryptographic security AND improving performance by reducing the number of > messages and the latency of SA activation. Given the IKEv2 draft, specifying > SIGMA in this context requires minimal work. I agree it would be straightforward. SIGMA proposes several protocols with different properties. I am reluctant to have options, since they limit interoperability. Is there one that you believe would be workable as *the* protocol that has advantages over the current proposal? > In addition, the SIGMA protocol would allow to have, in addition to the > main PK-based protocol, a single mode that simultaneously supports > Phase 2 functionality AND provides support for pre-shared keys. I agree that support for pre-shared keys would be a useful alternative, but I think the mechanism for it requires more thought. IKEv1 main mode has the problem (and SIGMA duplicates it to some degree) that identities are hidden on the wire but the protocol can't complete if the two ends don't know the identities of the peers by some out of band mechanism (like based on IP addresses). This fails in the common case of a mobile user connecting in via IPsec to a corporate firewall. We decided not to muddy the debate over a single simple-every-implementation-interoperates-with-every-other proposal for IKEv2, but if the other issues seem stable we could start discussing this. > As I said in my note, I believe (and hope that you agree) that > A TRULY SOUND KEY EXCHANGE PROTOCOL SHOULD NOT RELY ON > EXTERNAL MECHANISMS TO PROVIDE ITS MOST ESSENTIAL SECURITY PROPERTIES > > In particular, the protocol MUST DEFINE ITS OWN AUTHENTICATION MECHANISMS. I disagree. I believe protocols should not unnecessarily invent new authentication mechanisms any more than they should invent new cryptographic algorithms. If there is an existing one that is suitable, it's better to use it than to do something a little different because it simplifies analysis. But I agree that assumptions about those protocols must be made explicit, so that changes in those protocols later a less likely to introduce weaknesses. By specifying that we use the ESP Integrity Protection mechanisms, we're assuming that ESP has no weak Integrity Protection algorithms (which it currently doesn't, but could in the future). I'd be willing to narrow the reference to specific ESP options (e.g. HMAC MD5 and HMAC SHA1), or even a single one. That would prohibit later introduction of weaker algorithms in the future, while still making it syntactically obvious how we would migrate to a stronger one (e.g. HMAC SHA2). ---------- But I believe all of what appears to be disagreement is largely theoretical. If IKEv2 includes some additional fields under the signature as you propose, the basic security properties are guaranteed even without depending on the strength of the Integrity Protection algorithm, and that change seems both easy and conservative. Will you be at the upcoming IETF? This conversation might be easier over a whiteboard or a napkin. --Charlie This footnote confirms that either (1) this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses, (2) this email message was sent by a virus that appends this footnote, or (3) (most likely) the sender of this message is trying to raise awareness of how foolish it would be to place any confidence in footnotes like this. From owner-ipsec@lists.tislabs.com Tue Nov 27 11:27:45 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARJRj825416; Tue, 27 Nov 2001 11:27:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03607 Tue, 27 Nov 2001 13:27:22 -0500 (EST) Message-ID: <10C8636AE359D4119118009027AE9987120B7F69@FMSMSX34> From: "Walker, Jesse" To: "'Radia Perlman - Boston Center for Networking'" , ipsec@lists.tislabs.com Subject: RE: IKEv2 (son-of-ike) draft Date: Tue, 27 Nov 2001 10:36:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Radia, Dan, Charlie, and you have done a nice job with this draft document. Thanks for making this effort; it is a very hard job. I especially commend the lucid key roll-over discussion, as the lack of one was a devil tormenting implementors of the RFC 2401-2412 series. With that in mind, the following text on page 21 from Clause 5 "Informational (Phase 2) Exchange" jumped out at me: ESP, AH, and IPcomp SAs always exist in pairs, with one SA in each direction. When an SA is closed, both members of the pair MUST be closed. ... The recipient MUST close the designated SAs. Normally, the reply in the Informational Exchange will contain delete payloads for the paired SAs going in the other direction. There is one exception. If by chance both ends of a set of SAs independently decide to close them, each may send a delete payload and the two requests may cross in the network. If a node receives a delete request for SAs that it has already issued a delete request for, it MUST delete the incoming SAs while processing the request and the outgoing SAs while processing the response. In that case, the responses MUST NOT include delete payloads for the deleted SAs, since that would result in duplicate deletion and could in theory delete the wrong SA. This does not sound quite right. The Internet between the SA source and sink is a large re-ordering buffer, so the Delete can arrive before many already-transmitted data packets protected by the SA. It might be that this problem is not worth fixing, as the packet loss is transient and infrequent and any solution outweighs the introduced complexity, and I can accept this conclusion. However, as network speeds increase, the consequences this kind of reordering will become more evident and irritating, as more packets can be buffered, so it seems like we should at least have the discussion at least once. Let us call the communicating peers A and B, with A initiating the Delete; the A to B direction will be denoted by A->B, and analogously B->A for the B to A direction. Intuitively A will roll-over from the old A->B SA to the new by deciding to transmit on the new replacement A->B SA but receive on both the old and the new B->A SAs, and then send the Delete. Once it has made this decision there is no reason for it to maintain the old A->B SA, because it knows it will never use this for packets it sends to B. When B on the other hand receives the Delete, it doesn't know that it will receive no more protected datagrams for the old A->B SA. A faces a similar dilemma when it receives B's Delete response. It seems like there are two potential difficulties here. First the deletion of the half-duplex SAs are tightly coupled to occur together, and second, the receiver of a Delete doesn't have enough information to intelligently decide when to effect the delete of is old incoming SA. What seems needed is something like incorporating the SA's last sequence number sent into the Delete payload, and then adding a new state to an SA to allow the timing of the Delete of an SA to be decoupled somewhat from that of its bretheren in the opposite direction; perhaps the incoming SA has to be timed out after the outgoing one has been deleted, if it has not received to the end of the reported sequence space. -- Jesse -----Original Message----- From: Radia Perlman - Boston Center for Networking [mailto:Radia.Perlman@sun.com] Sent: Monday, November 19, 2001 11:55 AM To: ipsec@lists.tislabs.com Subject: IKEv2 (son-of-ike) draft And to answer some of the recent email on the list...this protocol does maintain the phase 1/phase 2 notion, but sets up both phase 1 and phase 2 in a single 2-round-trip exchange. After the initial exchange, additional SAs can be set up, or the SA can be rekeyed, with a single round trip. And it does identity hiding of both ends. Most of the work was in rewriting the three documents into a single self-contained document, and cleaning up the "networking" type issues and overly complex encodings such as the SA payload. Radia ------------- Begin Forwarded Message ------------- To: ipsec@lists.tislabs.com From: dharkins@tibernian.com Subject: IKEv2 (son-of-ike) draft MIME-Version: 1.0 Content-ID: <2377.1006067452.1@SailPix.com> This draft was submitted but hasn't shown up yet in the repository (the I-D editor is, no doubt, swamped) so in the interest of giving people more time to look at it prior to Salt Lake here's a link: http://www.lounge.org/draft-ietf-ipsec-ikev2-00.txt Please send comments to the list. Dan. ------------- End Forwarded Message ------------- From owner-ipsec@lists.tislabs.com Tue Nov 27 12:03:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARK3G826776; Tue, 27 Nov 2001 12:03:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03763 Tue, 27 Nov 2001 14:11:06 -0500 (EST) Message-ID: <89680B404BA1DD419E6D93B28B41899B03231B@01mail.nomadix.com> From: Bikramjit Singh To: "'Prakash Jain'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: ipsec/NAT query Date: Tue, 27 Nov 2001 11:11:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17777.5ABBB870" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17777.5ABBB870 Content-Type: text/plain; charset="iso-8859-1" Check out the Linux VPN Masquerade HOWTO and related document on what is possible/issues if NATing is done in the middle of an IPsec connection.. -Bikram -----Original Message----- From: Prakash Jain [mailto:jainp@hotmail.com] Sent: Tuesday, November 27, 2001 1:11 AM To: ipsec@lists.tislabs.com; nat@ietf.org Subject: ipsec/NAT query Hi, I am new to both ipsec and NAT. I am facing some problem having ipsec with NAT. I want to know if both can work together when they are not on same box, for example, scenario is as follows, ipsec Router ipsec client ----------------box doing---------N/w cloud----- server (A) NAT (B ) (C) <---------------------ipsec tunnel from A to C---------------> I think tunneling can be supported thru NAT but not very sure about ipsec (and its flavour ESP/AH) in above scenarios. I have following queries, 1. Does NAT implementation require something specific to ipsec (ipsec-nat ALG??) in above scenario? 2. Does ipsec protocol/negotiation involve client's ipaddress in any way? 3. Can ipsec and NAT have generic compatible implemantations (say ipsec client and NAT are from different vendors) in above scenarios? 4. Please give some relevent links on the web for above info. I will appreciate an early reply. Thanks and regards, Prakash ---------- Get your FREE download of MSN Explorer at http://explorer.msn.com ------_=_NextPart_001_01C17777.5ABBB870 Content-Type: text/html; charset="iso-8859-1"
Check out the Linux VPN Masquerade HOWTO and related document on what is possible/issues if NATing is done in the middle of an IPsec connection..
 
-Bikram
-----Original Message-----
From: Prakash Jain [mailto:jainp@hotmail.com]
Sent: Tuesday, November 27, 2001 1:11 AM
To: ipsec@lists.tislabs.com; nat@ietf.org
Subject: ipsec/NAT query

Hi, I am new to both ipsec and NAT. I am facing some problem having ipsec with NAT. I want to know if both can work together when they are not on same box, for example, scenario is as follows, ipsec Router ipsec client ----------------box doing---------N/w cloud----- server (A) NAT (B ) (C) <---------------------ipsec tunnel from A to C---------------> I think tunneling can be supported thru NAT but not very sure about ipsec (and its flavour ESP/AH) in above scenarios. I have following queries, 1. Does NAT implementation require something specific to ipsec (ipsec-nat ALG??) in above scenario? 2. Does ipsec protocol/negotiation involve client's ipaddress in any way? 3. Can ipsec and NAT have generic compatible implemantations (say ipsec client and NAT are from different vendors) in above scenarios? 4. Please give some relevent links on the web for above info. I will appreciate an early reply. Thanks and regards, Prakash ---------- Get your FREE download of MSN Explorer at http://explorer.msn.com
------_=_NextPart_001_01C17777.5ABBB870-- From owner-ipsec@lists.tislabs.com Tue Nov 27 12:05:15 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARK5F826845; Tue, 27 Nov 2001 12:05:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03757 Tue, 27 Nov 2001 14:08:35 -0500 (EST) To: Hugo Krawczyk Cc: Sara Bitan , Michael Thomas , Henry Spencer , ipsec list Subject: Re: SOI: identity protection and DOS References: From: Derek Atkins Date: 27 Nov 2001 14:17:36 -0500 In-Reply-To: Hugo Krawczyk's message of "Tue, 27 Nov 2001 19:14:54 +0200 (IST)" Message-ID: Lines: 21 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > And I certainly do not have to tell you that these second and third-party > type models are in widespread use today. > They deserve a WELL-DESIGNED shared-key support in IKE. This protocol already exists. It is called "KINK". Why don't we focus SoI on Public-Key and Kink on Secret key techniques? That way we don't wind up with such a generic panacea featuritis protocol -- instead of we wind up with two simpler protocols which can (hopefully) be verified independently. > Hugo -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 27 12:18:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARKI6827373; Tue, 27 Nov 2001 12:18:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03800 Tue, 27 Nov 2001 14:23:58 -0500 (EST) Message-ID: <3C03EB45.607B57D5@redcreek.com> Date: Tue, 27 Nov 2001 11:36:37 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 CC: IPsec WG Subject: Re: On shared keys References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: > > Everyone agrees that public key is the ONLY way to a scalable > Internet-wide protocol. No question about it. In particular, > any key-exchange protocol for IPsec MUST provide a PK-based exchange. I agree that, in theory, a PK based system should scale further than a PSK based system. But in practice, we live in a world where PSK based authentication methods have been made to scale to an entirely sufficient degree by almost every corporation. The advantages of scaling further yet seems pretty dim in most of their eyes when compared to the cost of re-tooling their credential handling. The set of organizations who need greater scalability than PSKs is small (but non-ignorable). The set of organizations who currently have working infrastructures to support PSK authentications is large. So, do we need a PSK authentication method as well as a PK authentication method? Each of the three next generation IKE replacement drafts dropped support for PSK authentication specifically in the interest of protocol simplicity. This is a laudable goal and should not be lightly dismissed. Simplicity increases both interoperability and security. Some have argued that we need a PSK authentication method because it is easy to test. This argument does not overcome the arguments in favor of protocol simplicity in my view. But, I would like to make the point (as others have) that a PSK authentication system which can easily interact with popular back-end authentication servers and will not tie the peers down to pre-configured, known IP addresses would be a highly usable and popular protocol as it would conviently address a great need. IMHO, such an authentication method is in more demand than a PK authentication method even though the PK authentication could scale larger. Next generation IKEers have all set about the goals of reducing complexity and setup cost. But I would also request (and here starts a new war) that the authors of IKE replacement protocols also consider taking on the goals set forth in the ipsra WG (draft-ietf-ipsra-reqmts-04.txt) but with the ability to 'change IKE'. I think that we should do a PSK authentication method because it would be useful. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Tue Nov 27 12:44:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARKit828262; Tue, 27 Nov 2001 12:44:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03908 Tue, 27 Nov 2001 14:49:21 -0500 (EST) To: Michael Thomas Cc: Hugo Krawczyk , IPsec WG Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <15363.50951.988003.42518@thomasm-u1.cisco.com> From: Derek Atkins Date: 27 Nov 2001 14:58:45 -0500 In-Reply-To: Michael Thomas's message of "Tue, 27 Nov 2001 09:01:59 -0800 (PST)" Message-ID: Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas writes: > I don't think I agree if by Internet-wide you mean > any-any scaling. I frankly don't think that such a > thing exists, or is likely to exist. Thus while PK > exchanges give many useful properties, enrollment, > compromise, and administration are still problems > for both. Indeed, the only thing in existence > right now that scales to any appreciable degree is > *not* based on asymmetric keys (GSM). It seems to > scale well enough for its application and > acceptible risk parameters. Except that keys are transmitted between "countries" in clear-text... > Mike -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 27 12:48:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARKmW828378; Tue, 27 Nov 2001 12:48:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03980 Tue, 27 Nov 2001 15:00:15 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15363.62186.160914.487198@thomasm-u1.cisco.com> Date: Tue, 27 Nov 2001 12:09:14 -0800 (PST) To: ipsec list Subject: SOI: selector exclusion lists/ranges X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A while back I think we had a discussion about IKE's inability to express port ranges for selectors. I have an admittedly parochial desire for this feature because I'd like to have the ability to protect all traffic to a node except where I'm protecting things at application layer, ala SRTP. Currently, the only way to do that would be to enumerate every port that you want protected; with 65k ports, that's a bit hard to swallow. In reality, I really don't think this ability is all that unique when you think beyond IKE/IPsec as being a VPN establishment mechanism; other things are surely in this situation. Indeed, this may be one way to fix the current implicit meaning of an IKE selector which is "everything but port 500". Since KINK will also have a well known port for key management, this would give the implementation an unambiguous way to express whether it wants other key management protocols inside or outside of the selector. Thus I think we should have a requirement which states: "The protocol MUST have the ability to express port ranges for flow selectors, as well as have the ability to selectively enumerate ports which fall outside of the flow selector." Mike From owner-ipsec@lists.tislabs.com Tue Nov 27 12:56:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARKuL828597; Tue, 27 Nov 2001 12:56:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA03915 Tue, 27 Nov 2001 14:50:03 -0500 (EST) Message-ID: <3C03F0A5.7080302@isi.edu> Date: Tue, 27 Nov 2001 11:59:33 -0800 From: Lars Eggert User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011121 X-Accept-Language: en, de MIME-Version: 1.0 To: Joe Touch , ipsec@lists.tislabs.com Subject: Updated ID: draft-touch-ipsec-vpn-02.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, with the recent discussion on IPsec in combination with dynamic routing, we'd like to point out that we submitted an update to the "Use of IPsec Transport Mode for Virtual Networks" ID - which includes a discussion of this issue - a few days ago (it hasn't been announced yet). In the meantime, the ID is available from http://www.isi.edu/touch/pubs/draft-touch-ipsec-vpn-02.txt Thanks, Lars -- Lars Eggert Information Sciences Institute http://www.isi.edu/larse/ University of Southern California From owner-ipsec@lists.tislabs.com Tue Nov 27 13:03:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARL3A828836; Tue, 27 Nov 2001 13:03:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04000 Tue, 27 Nov 2001 15:06:57 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15363.62556.418647.555240@thomasm-u1.cisco.com> Date: Tue, 27 Nov 2001 12:15:24 -0800 (PST) To: Derek Atkins Cc: Michael Thomas , Hugo Krawczyk , IPsec WG Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) In-Reply-To: References: <15363.50951.988003.42518@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek Atkins writes: > Michael Thomas writes: > > > I don't think I agree if by Internet-wide you mean > > any-any scaling. I frankly don't think that such a > > thing exists, or is likely to exist. Thus while PK > > exchanges give many useful properties, enrollment, > > compromise, and administration are still problems > > for both. Indeed, the only thing in existence > > right now that scales to any appreciable degree is > > *not* based on asymmetric keys (GSM). It seems to > > scale well enough for its application and > > acceptible risk parameters. > > Except that keys are transmitted between "countries" in clear-text... Far be it for me to defend telco standards, but the key is acceptible risk. In any case, all I really meant to dispute is that you can't build scalable strong auth systems without PKI. It's manifestly possible. Mike From owner-ipsec@lists.tislabs.com Tue Nov 27 13:23:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARLNm829442; Tue, 27 Nov 2001 13:23:48 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04110 Tue, 27 Nov 2001 15:36:57 -0500 (EST) Message-ID: <3C03FC66.74EEEA37@redcreek.com> Date: Tue, 27 Nov 2001 12:49:42 -0800 From: Ricky Charlet Organization: Redcreek Communications X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: ipsec list Subject: Re: SOI: selector exclusion lists/ranges References: <15363.62186.160914.487198@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Thomas wrote: > Thus I think we should have a requirement which > states: > > "The protocol MUST have the ability to express > port ranges for flow selectors, as well as have > the ability to selectively enumerate ports which > fall outside of the flow selector." > > Mike Ooh, ooh, ooh!! And lists (not restricted to ranges) of subnets bound to a single SA too please! -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Tue Nov 27 13:56:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARLuo800573; Tue, 27 Nov 2001 13:56:50 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA04252 Tue, 27 Nov 2001 15:57:42 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Ricky Charlet Cc: Michael Thomas , ipsec list Subject: Re: SOI: selector exclusion lists/ranges Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2001 16:07:05 -0500 Message-Id: <20011127210706.21F037B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3C03FC66.74EEEA37@redcreek.com>, Ricky Charlet writes: >Michael Thomas wrote: >> Thus I think we should have a requirement which >> states: >> >> "The protocol MUST have the ability to express >> port ranges for flow selectors, as well as have >> the ability to selectively enumerate ports which >> fall outside of the flow selector." >> >> Mike > > > > Ooh, ooh, ooh!! And lists (not restricted to ranges) of subnets bound >to a single SA too please! In principle, both make sense. In practice, I'm hearing that a lot of IPsec interoperability problems are due to different notions of what has to be supported in SAs. We should think about simplifying that, too. (I plan on making some concrete suggestions on that, but I ran out of time to write anything up before the I-D cut-off.) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Tue Nov 27 14:03:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARM3F800804; Tue, 27 Nov 2001 14:03:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04432 Tue, 27 Nov 2001 16:19:51 -0500 (EST) Message-ID: <20011127211313.96897.qmail@web13007.mail.yahoo.com> Date: Tue, 27 Nov 2001 13:13:13 -0800 (PST) From: Jeffrey lo Subject: Re: [NAT] ipsec/NAT query To: Prakash Jain , ipsec@lists.tislabs.com, nat@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There were some work done on this problem in RSIP. Refer to RFC 3102-3105. Jeffrey --- Prakash Jain wrote:
Hi, I am new to both ipsec and NAT. I am facing some problem having ipsec with NAT. I want to know if both can work together when they are not on same box, for example, scenario is as follows, ipsec Router ipsec client ----------------box doing---------N/w cloud----- server (A) NAT (B ) (C) <---------------------ipsec tunnel from A to C---------------> I think tunneling can be supported thru NAT but not very sure about ipsec (and its flavour ESP/AH) in above scenarios. I have following queries, 1. Does NAT implementation require something specific to ipsec (ipsec-nat ALG??) in above scenario? 2. Does ipsec protocol/negotiation involve client's ipaddress in any way? 3. Can ipsec and NAT have generic compatible implemantations (say ipsec client and NAT are from different vendors) in above scenarios? 4. Please give some relevent links on the web for above info. I will appreciate an early reply. Thanks and regards, Prakash ---------- Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ nat mailing list nat@ietf.org http://www1.ietf.org/mailman/listinfo/nat __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 From owner-ipsec@lists.tislabs.com Tue Nov 27 14:05:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARM4x800850; Tue, 27 Nov 2001 14:04:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04360 Tue, 27 Nov 2001 16:09:00 -0500 (EST) Message-ID: <49B96FCC784BC54F9675A6B558C3464E5D0CCD@MAIL.NetOctave.com> From: Mark Winstead To: "IPSEC (E-mail)" Subject: IKEv2, AES, and Diffie-Hellman groups - a few remarks, a question and a clarification request Date: Tue, 27 Nov 2001 16:18:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17789.0C22AE0A" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C17789.0C22AE0A Content-Type: text/plain; charset="iso-8859-1" I finally got to reading IKEv2. I join many in the community in thanking the authors for their efforts. Some comments, et al: Comment 1: There is an inconsistency in security between the "MUST" implement AES and "MUST" implement the 1536 bit group 5 --- In paragraph 7.3.4, the only mandatory encryption algorithm is AES, which has smallest key size of 128 bits. To properly support a 128 bit key with a Diffie Hellman group, one must use a modp group of size between ~2000 bits and ~3100 bits (depending on whose analysis you believe). Yet the only mandatory support for Diffie Hellman groups is the fifth group, described in paragraph 8.5. This is a 1536 bit group, too small by all evaluations I know about. See www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-groups-03.txt for more discussion on this point. Comment 2: Diffie-Hellman groups three (8.3) and four (8.4) have a characteristic considered vulnerable by many EC cryptographic experts. Group 3 is a EC2N group with field size 155, and Group 4 is a EC2N group with field size 185. Fields of composite size (size not a prime number) can be decomposed into a field extension of an extension, considered a structural feature vulnerable to cryptographic attacks. This is why it is widely considered wise to pick EC2N groups over fields of prime size. See http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt for more discussion of the problems with groups three and four Comment 2a: No Diffie-Hellman group in the IKEv2 draft is sufficient for AES. Commonly cited values for key exchanges Symmetric | EC2N | MODP (AES) 128 | 283 | 3072 (AES) 192 | 409 | 7680 (AES) 256 | 571 | 15360 The largest modp group cited is 1536 bits, and the largest EC2N group is 185 It seems to me that there should be some MUST and SHOULD implement pre-defined groups that support the mandatory to be implemented AES. More over, groups in section 8.3 and 8.4 probably should be changed to MAY implement from SHOULD, and group five in 8.5 should be a SHOULD or MAY group, but not a MUST group. Comment 3: No reference to AES in bibliography AES is mandatory, but there is no pointer to a description of it. Comment 4: Shouldn't ECDSA be included among authentication methods (7.3.2, Transform Type 3)? This is essentially DSS (method 2) done with either an EC2N group or a ECP group rather than an MODP group. If Diffie-Hellman groups include EC2N and ECP groups, it seems logical to me that DSS should include them. See http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-02.txt . Comment 5: In appendix A, in the description class for Diffie-Hellman groups, while a "complete" generator two is not needed, it is insufficient to have simply the definition of a curve and the x coordinate. There are still two possibilities given an x coordinate and a curve -- but all it takes is a single bit to determine which of the two to use. And actually, which y coordinate (generator two) only matters for ECDSA, but not for a Diffie-Hellman exchange (the x coordinate, used for the secret value, will be the same regardless of the y coordinate chosen). A question: Why no pre-defined ECP groups (section 8)? Generally speaking, EC2N groups are considered faster in hardware than ECP, but ECP is much easier to program into software (and some claim faster in software than EC2N) and understand by more novice crypto programmers (even most more seasoned programmers). A request for clarification: AES (as defined in the FIPS draft) comes in three flavors -- 128 bit keys, 192 bit keys, and 256 bit keys. IKEv2 only says AES is mandatory. I would suggest that if it is meant that all 3 key sizes must be supported, then say so. And actually I would suggest only 128 bit keys be mandatory, and that 192 bit and 256 bit keys may be supported. I believe that would be consistent with http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-02.txt . Mark Winstead Senior Mathematician NetOctave, Inc. P.O. Box 14824 RTP, NC 27709 919.463.9903 x328 mark.winstead@netoctave.com ------_=_NextPart_001_01C17789.0C22AE0A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I = finally got to=20 reading IKEv2. I join many in the community in thanking the authors for = their=20 efforts.
 
Some = comments, et=20 al:
 
Comment 1: There is=20 an inconsistency in security between the "MUST" implement AES and = "MUST"=20 implement the 1536 bit group 5 ---
In = paragraph 7.3.4,=20 the only mandatory encryption algorithm is AES, which has smallest key = size of=20 128 bits. To properly support a 128 bit key with a Diffie Hellman = group, one=20 must use a modp group of size between ~2000 bits and ~3100 bits = (depending on=20 whose analysis you believe).  Yet the only mandatory support = for=20 Diffie Hellman groups is the fifth group, described in paragraph 8.5. = This is a=20 1536 bit group, too small by all evaluations I know about. See www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-modp-grou= ps-03.txt=20 for more discussion on this point.
 
Comment 2:=20 Diffie-Hellman groups three (8.3) and four (8.4) have a characteristic=20 considered vulnerable by many EC cryptographic = experts.
Group = 3 is a EC2N=20 group with field size 155, and Group 4 is a EC2N group with field size = 185.=20 Fields of composite size (size not a prime number) can be = decomposed=20 into a field extension of an extension, considered a = structural=20 feature vulnerable to cryptographic attacks. This is why it is = widely=20 considered wise to pick EC2N groups over fields of prime = size.=20 See http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc= -groups-03.txt for=20 more discussion of the problems with groups three and = four
 
Comment 2a: No=20 Diffie-Hellman group in the IKEv2 draft is sufficient for=20 AES.
Commonly cited=20 values for key exchanges
       &nb= sp;      =20 Symmetric   |  EC2N   =20 |  MODP
   (AES)   &nbs= p;    =20 128        |  283  =20     | =20 3072
   (AES)       = ; =20 192        | =20 409       |  = 7680
   (AES)=20        =20 256        | =20 571       |  = 15360
 
The = largest modp=20 group cited is 1536 bits, and the largest EC2N group is = 185
 
It = seems to me that=20 there should be some MUST and SHOULD implement pre-defined groups that = support=20 the mandatory to be implemented AES. More over, groups in section 8.3 = and 8.4=20 probably should be changed to MAY implement from SHOULD, and group five = in 8.5=20 should be a SHOULD or MAY group, but not a MUST = group.
 
Comment 3: No=20 reference to AES in bibliography
AES = is mandatory,=20 but there is no pointer to a description of it.
 
Comment 4: Shouldn't=20 ECDSA be included among authentication methods (7.3.2, Transform Type = 3)? This=20 is essentially DSS (method 2) done with either an EC2N group or a ECP = group=20 rather than an MODP group. If Diffie-Hellman groups include EC2N and = ECP groups,=20 it seems logical to me that DSS should include them. See http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-aut= h-ecdsa-02.txt.
 
Comment 5: In=20 appendix A, in the description class for Diffie-Hellman groups, while a = "complete" generator two is not needed, it is insufficient to have = simply the=20 definition of a curve and the x coordinate. There are still two = possibilities=20 given an x coordinate and a curve -- but all it takes is a single bit = to=20 determine which of the two to use. And actually, which y coordinate = (generator=20 two) only matters for ECDSA, but not for a Diffie-Hellman exchange = (the x=20 coordinate, used for the secret value, will be the same regardless of = the y=20 coordinate chosen).
 
A=20 question:  Why no pre-defined ECP groups = (section 8)?=20 Generally=20 speaking, EC2N groups are considered faster in hardware than ECP, = but ECP=20 is much easier to program into software (and some = claim faster in=20 software than EC2N) and understand by more novice crypto = programmers=20 (even most more seasoned programmers).
 
A = request for=20 clarification: AES (as defined in the FIPS draft) comes in three = flavors -- 128=20 bit keys, 192 bit keys, and 256 bit keys. IKEv2 only says AES is=20 mandatory. I would suggest that if it is meant that all 3 key = sizes must be=20 supported, then say so. And actually I would suggest only 128 bit keys = be=20 mandatory, and that 192 bit and 256 bit keys may be supported. I = believe=20 that would be consistent with http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-= cbc-02.txt.
 

Mark = Winstead

Senior=20 Mathematician

NetOctave, Inc.

P.O. Box = 14824

RTP, NC = 27709

919.463.9903 x328

mark.winstead@netoctave.com<= /A>
 
------_=_NextPart_001_01C17789.0C22AE0A-- From owner-ipsec@lists.tislabs.com Tue Nov 27 14:07:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARM7S800926; Tue, 27 Nov 2001 14:07:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04413 Tue, 27 Nov 2001 16:17:21 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE0118845D@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: ipsec@lists.tislabs.com Subject: new ID: Date: Tue, 27 Nov 2001 21:26:20 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1778A.28112910" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1778A.28112910 Content-Type: text/plain We have produced a draft discussing the issues of supporting dynamic routing for IPsec VPNs. Although the draft targets the PPVPN WG, we would like to get feedbacks from this list as well. All comments/suggestions are appreciated. Routing Support in CE-based IPsec VPNs http://www.ietf.org/internet-drafts/draft-wang-cevpn-routing-00.txt Summary The PPVPN WG currently supports three types of VPNs: Provider Provisioned Network Based Layer 3 VPNs, Provider Provisioned Layer 2 VPNs and Provider Provisioned CE-based VPNs. This draft discusses the issue of supporting routing for CE-based IPsec VPN. ------_=_NextPart_001_01C1778A.28112910 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
 We have produced a draft discussing the = issues of=20 supporting dynamic routing for
IPsec VPNs. Although the draft targets the=20 PPVPN WG, we would like to get feedbacks=20 from 
this list as well. All = comments/suggestions are=20 appreciated. 
 
 Routing Support in CE-based = IPsec=20 VPNs
http://www.ietf.org/internet-drafts/draft-wang-cevpn-routing-00.txt=
 
  Summary=20
   
   The PPVPN WG currently supports = three=20 types of VPNs: Provider
   Provisioned Network Based = Layer 3 VPNs,=20 Provider Provisioned Layer 2
   VPNs and Provider = Provisioned=20 CE-based VPNs. This draft discusses
   the issue of = supporting=20 routing for CE-based IPsec VPN. 
   =20
------_=_NextPart_001_01C1778A.28112910-- From owner-ipsec@lists.tislabs.com Tue Nov 27 15:03:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARN3s803031; Tue, 27 Nov 2001 15:03:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04643 Tue, 27 Nov 2001 17:10:17 -0500 (EST) Message-Id: <200111272219.RAA13596@bcn.East.Sun.COM> Date: Tue, 27 Nov 2001 17:19:45 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: SOI: selector exclusion lists/ranges To: mat@cisco.com, rcharlet@redcreek.com Cc: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 02r80w52XR59kPhUejfN7w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IKEv2 spec does both of your wishes :-). See sections 2.9 and 7.13. Radia From: Ricky Charlet Michael Thomas wrote: > Thus I think we should have a requirement which > states: > > "The protocol MUST have the ability to express > port ranges for flow selectors, as well as have > the ability to selectively enumerate ports which > fall outside of the flow selector." > > Mike Ooh, ooh, ooh!! And lists (not restricted to ranges) of subnets bound to a single SA too please! From owner-ipsec@lists.tislabs.com Tue Nov 27 15:17:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARNHl803510; Tue, 27 Nov 2001 15:17:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04699 Tue, 27 Nov 2001 17:31:50 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15364.5735.592837.504062@thomasm-u1.cisco.com> Date: Tue, 27 Nov 2001 14:40:39 -0800 (PST) To: Dan Harkins Cc: Michael Thomas , ipsec list Subject: Re: SOI: selector exclusion lists/ranges In-Reply-To: <200111271333.fARDX3U01382@fatty.lounge.org> References: <15363.62186.160914.487198@thomasm-u1.cisco.com> <200111271333.fARDX3U01382@fatty.lounge.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Again, I'm pleased as punch if they're part of the proposed protocols. I just want them to also be reflected in the requirements so that we all agree what are features vs. misfeatures, etc. Mike Dan Harkins writes: > The Traffic Selector Payload consists of a list of Traffic Selector > Substructures each of which have start-port and end-port entries. > So you can specify ports 1-78 and 80-1023 if you wanted to protect > all ports less than 1024 except 79. > > They can't represent things that fall outside of a selector since > they are designed to represent the selector itself. But I think they > can do what you want. Check out section 7.13 in the IKEv2 draft. > > Note that while IKEv2 can express this an RFC2401-compliant IPsec > implementation could not have a selector like this for IKEv2 to > represent. The restriction in RFC2401 was because of a limitation in > RFC2408 though so hopefully a rev of RFC2401 will include port ranges. > > Dan. > > On Tue, 27 Nov 2001 12:09:14 PST you wrote > > > > Thus I think we should have a requirement which > > states: > > > > "The protocol MUST have the ability to express > > port ranges for flow selectors, as well as have > > the ability to selectively enumerate ports which > > fall outside of the flow selector." > > > > Mike From owner-ipsec@lists.tislabs.com Tue Nov 27 15:59:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fARNxa804810; Tue, 27 Nov 2001 15:59:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04798 Tue, 27 Nov 2001 18:17:22 -0500 (EST) Date: Tue, 27 Nov 2001 15:26:15 -0800 (PST) From: Jan Vilhuber To: "Steven M. Bellovin" cc: Ricky Charlet , Michael Thomas , ipsec list Subject: Re: SOI: selector exclusion lists/ranges In-Reply-To: <20011127210706.21F037B55@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Nov 2001, Steven M. Bellovin wrote: > In message <3C03FC66.74EEEA37@redcreek.com>, Ricky Charlet writes: > >Michael Thomas wrote: > >> Thus I think we should have a requirement which > >> states: > >> > >> "The protocol MUST have the ability to express > >> port ranges for flow selectors, as well as have > >> the ability to selectively enumerate ports which > >> fall outside of the flow selector." > >> > >> Mike > > > > > > > > Ooh, ooh, ooh!! And lists (not restricted to ranges) of subnets bound > >to a single SA too please! > > In principle, both make sense. In practice, I'm hearing that a lot of > IPsec interoperability problems are due to different notions of what > has to be supported in SAs. In practice I don't think most of our interop problems stem from SA negotiations, i.e. phase 2. I think phase 1 (and certificate) interoperability is by far the bigger problem. A well defined and flexible ID payload would do wonders.... jan > We should think about simplifying that, > too. (I plan on making some concrete suggestions on that, but I ran > out of time to write anything up before the I-D cut-off.) > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 27 16:02:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS02A804936; Tue, 27 Nov 2001 16:02:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04808 Tue, 27 Nov 2001 18:20:00 -0500 (EST) Date: Tue, 27 Nov 2001 15:28:50 -0800 (PST) From: Jan Vilhuber To: Ricky Charlet cc: Michael Thomas , ipsec list Subject: Re: SOI: selector exclusion lists/ranges In-Reply-To: <3C03FC66.74EEEA37@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually, now that I think about it, the ipsec-sctp draft addresses some of this via the ID_RECURSE (BAD name! Bad name!!) payload. The new SOI Traffic selector payload used in this manner would be a great benefit. jan On Tue, 27 Nov 2001, Ricky Charlet wrote: > Michael Thomas wrote: > > Thus I think we should have a requirement which > > states: > > > > "The protocol MUST have the ability to express > > port ranges for flow selectors, as well as have > > the ability to selectively enumerate ports which > > fall outside of the flow selector." > > > > Mike > > > > Ooh, ooh, ooh!! And lists (not restricted to ranges) of subnets bound > to a single SA too please! > > > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." Benjamin Franklin > > Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 27 16:06:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS06O805053; Tue, 27 Nov 2001 16:06:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04832 Tue, 27 Nov 2001 18:24:01 -0500 (EST) Date: Tue, 27 Nov 2001 15:32:15 -0800 (PST) From: Jan Vilhuber To: Radia Perlman - Boston Center for Networking cc: mat@cisco.com, rcharlet@redcreek.com, ipsec@lists.tislabs.com Subject: Re: SOI: selector exclusion lists/ranges In-Reply-To: <200111272219.RAA13596@bcn.East.Sun.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Nov 2001, Radia Perlman - Boston Center for Networking wrote: > The IKEv2 spec does both of your wishes :-). See sections 2.9 and 7.13. > Oh.. Right. I missed the part that there can be multiple 'Traffic Selector Substructure's. Very useful. If I read and understood it correctly this time, does this make the ID_RECURSE payload (Bad name.. did I already mention that?! ;) obsolete? At least for ikev2... jan > Radia > > > From: Ricky Charlet > > Michael Thomas wrote: > > Thus I think we should have a requirement which > > states: > > > > "The protocol MUST have the ability to express > > port ranges for flow selectors, as well as have > > the ability to selectively enumerate ports which > > fall outside of the flow selector." > > > > Mike > > > > Ooh, ooh, ooh!! And lists (not restricted to ranges) of subnets > bound > to a single SA too please! > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 27 16:06:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS06R805069; Tue, 27 Nov 2001 16:06:27 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04792 Tue, 27 Nov 2001 18:15:16 -0500 (EST) Date: Tue, 27 Nov 2001 15:24:14 -0800 (PST) From: Jan Vilhuber To: Michael Thomas , srisuresh@yahoo.com cc: ipsec list Subject: Re: SOI: selector exclusion lists/ranges In-Reply-To: <15363.62186.160914.487198@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A while ago P. Srisuresh and I proposed a new ID payload. We're still trying to find a home for this draft (draft-srisuresh-ike-policy-extensions-01.txt, which has expired). It has two features: - A more cisco-acl-like syntax in the ID payload to better "express yourself". - A mechanism by which you can dynamically add and remove policy from an SA, which is useful for things like voice traffic or even simple ftp, where you want to add certain ports (or IP addresses if you have need for this) to the SA which the application dynamically allocates. The consensus by the Chairs was that this was changing IKE, and therefore shouldn't be discussed (I think). If there's interest, we can revive the draft or use bits and pieces of it to incorporate into ikev2. I think Pyda is trying to the ipsp (policy) route with this. jan On Tue, 27 Nov 2001, Michael Thomas wrote: > > A while back I think we had a discussion about > IKE's inability to express port ranges for > selectors. I have an admittedly parochial desire > for this feature because I'd like to have the > ability to protect all traffic to a node except > where I'm protecting things at application layer, > ala SRTP. Currently, the only way to do that would > be to enumerate every port that you want > protected; with 65k ports, that's a bit hard to > swallow. In reality, I really don't think this > ability is all that unique when you think beyond > IKE/IPsec as being a VPN establishment mechanism; > other things are surely in this situation. Indeed, > this may be one way to fix the current implicit > meaning of an IKE selector which is "everything > but port 500". Since KINK will also have a well > known port for key management, this would give the > implementation an unambiguous way to express > whether it wants other key management protocols > inside or outside of the selector. > > Thus I think we should have a requirement which > states: > > "The protocol MUST have the ability to express > port ranges for flow selectors, as well as have > the ability to selectively enumerate ports which > fall outside of the flow selector." > > Mike > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 27 16:25:44 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS0Ph805805; Tue, 27 Nov 2001 16:25:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04898 Tue, 27 Nov 2001 18:39:24 -0500 (EST) Message-Id: <200111272348.SAA13952@bcn.East.Sun.COM> Date: Tue, 27 Nov 2001 18:48:53 -0500 (EST) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: SOI: selector exclusion lists/ranges To: ipsec@lists.tislabs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: AKJjWxoeEdge/N6SP3ywnQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, IKEv2 makes the SCTP ID_RECURSE thing unnecessary. Radia From: Jan Vilhuber > Oh.. Right. I missed the part that there can be multiple 'Traffic Selector Substructure's. Very useful. If I read and understood it correctly this time, does this make the ID_RECURSE payload (Bad name.. did I already mention that?! ;) obsolete? At least for ikev2... jan From owner-ipsec@lists.tislabs.com Tue Nov 27 16:37:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS0bu806226; Tue, 27 Nov 2001 16:37:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04975 Tue, 27 Nov 2001 18:54:26 -0500 (EST) Date: Tue, 27 Nov 2001 16:03:23 -0800 (PST) From: Jan Vilhuber To: "Angelos D. Keromytis" cc: Radia Perlman - Boston Center for Networking , mat@cisco.com, rcharlet@redcreek.com, ipsec@lists.tislabs.com Subject: Re: SOI: selector exclusion lists/ranges In-Reply-To: <200111272336.fARNaXEH020283@coredump.cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Nov 2001, Angelos D. Keromytis wrote: > > In message , Jan > Vilhuber writes: > > > >If I read and understood it correctly this time, does this make the > >ID_RECURSE payload (Bad name.. did I already mention that?! ;) obsolete? At > >least for ikev2... > > I think it does. > -Angelos > > PS. I must be missing something: why is ID_RECURSE a bad name ? > As stated by someone else, recursion implies, well.. recursion :) Meaning you should be able to use an ID_RECURSE within an ID_RECURSE (to an arbitrary depth). Obviously we don't want this. However the draft states (correctly, I would think): "ID_RECURSE IDs cannot appear inside ID_RECURSE ID payloads.". Therefore, it's NOT recursive. What it is, is a LIST of ID payloads. So ID_LIST would be a much better name. Or ID_OF_IDS ;) jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ipsec@lists.tislabs.com Tue Nov 27 17:11:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS1BM807419; Tue, 27 Nov 2001 17:11:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05069 Tue, 27 Nov 2001 19:27:06 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Steven M. Bellovin" , "Paul Hoffman / VPNC" Cc: References: <20011126200935.19BDE7B55@berkshire.research.att.com> Subject: Re: SOI: identity protection and DOS Date: Tue, 27 Nov 2001 19:36:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 00:36:06.0654 (UTC) FILETIME=[AAC629E0:01C177A4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The very reason to certify a public key is that if the key is not 'public' enough than it is subject to MIM attack. Self-signed cert is subject to MIM attack unless... then why we need public/private key. --- David ----- Original Message ----- From: "Steven M. Bellovin" To: "Paul Hoffman / VPNC" Cc: Sent: Monday, November 26, 2001 3:09 PM Subject: Re: SOI: identity protection and DOS > In message , Paul Hoffman / VPNC writes > : > >At 9:20 AM -0800 11/26/01, Michael Thomas wrote: > >> If you allow for pre-shared keys, then it clearly > >> requires an extra message or two. Which is why we > >> should determine what the actual requirement is > >> re pre-shared keys. If it's a requirement, then > >> we need to confront the time/protection tradeoff. > >> If it's not a requirement, this mostly vanishes. > > > >Positive traits of IKEv1 pre-shared keys: > >a) easy for each party to set up > >b) not susceptible to CRL time lag or CA key compromise > >c) fewer exponentiations on each side for IPsec key setup > > > >Negative traits of IKEv1 pre-shared keys: > >d) hard to scale > >e) unless identity protection is not needed, the initiator must be at > >known IP address, and there must be only one pre-shared key at that > >address > >f) out-of-band swapping of the key must be done privately > > > >If what is most important is (a) and (b), and the problem of (d) is > >not important, both the JFK and IKEv2 implementations can be > >trivially set up for this by allowing one or both sides to use > >self-signed certificates, where the other side has trusted the public > >key in the certificate using some out-of-band mechanism. In JFK and > >IKEv2 using this method, you don't get advantage (c), but you don't > >have disadvantage (e) or (f). > > Or even IKEv1 -- and that's precisely the point. Using certificates > does *not* require existence of a PKI, or even a pki. (That's the > great lesson of ssh, btw -- it's very easy to deploy something based on > exchanging public keys, without dragging any central authority into the > picture.) You do have the exponentiations; what that buys you (apart > from simplicity of the protocol) is protection of authentication > material in event of peer compromise. That is, I can hand Alice and > Bob the same public key for me. If Bob is compromised, that does not > allow the attacker to impersonate me when talking to Alice. To do that > with pre-shared symmetric keys, I'd have to have a separate key for > each correspondent, and (depending on just how those keys were > employed) I might have to worry about MITM attacks. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > > From owner-ipsec@lists.tislabs.com Tue Nov 27 17:11:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS1BP807433; Tue, 27 Nov 2001 17:11:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05063 Tue, 27 Nov 2001 19:26:27 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14> To: ipsec@lists.tislabs.com, saag@mit.edu Subject: IP Storage and IPsec encapsulation Date: Tue, 27 Nov 2001 19:25:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Picking up a baseball bat and carefully drawing a bead on the hornet's nest ... Over in the IP Storage (ips) WG, we're picking up a subset of IPsec (primarily ESP and IKE) to provide security for our protocols (TCP/IP encapsulations of SCSI and Fibre Channel - iSCSI, FCIP, and iFCP). This approach is being used in order to avoid putting out new protocol standards that require things like DES and AH (comments in favor of DES and/or AH should be sent to /dev/null ;-) ). >From a protocol specification standpoint, the IPS WG is not prepared to require Integrated or Bump In The Stack implementations of IPsec. In other words, the WG does not want to foreclose the ability to take an IP Storage protocol implementation without IPsec, hook it up directly to a security gateway IPsec implementation and obtain a result from the combination that complies with the security requirements of the IPS protocol specification. The protocol on the link between the IP Storage implementation and its security gateway would NOT be compliant because it would lack required security functionality (this latter point was explained at length by the IESG in the London plenary). Since IP Storage implementations could be based on host or security gateway implementations of IPsec, the appropriate thing to do in the IP Storage drafts appears to be to REQUIRE tunnel mode as the encapsulation mode that must be present for interoperability because it is the common mode required by both classes of IPsec implementations. OTOH, I've heard concerns that tunnel mode may not provide a suitable bias towards end-to-end security - it's not that difficult to terminate an IPsec tunnel someplace other than the far end of the communication session running through it. OTOOH, this concern strikes me as a policy issue - if some node other than the far end can terminate the IPsec tunnel, that node must have the keying material required to set up the tunnel mode SA in the first place. In turn that reflects a conscious security policy decision by the administrator who configured that material into that intermediate node and got exactly what s/he asked for. This policy aspect is unavoidable, as the only way to remove this option (tunnel mode to a gateway not at the far end) from the admin's hands is to forbid tunnel mode, which seems like a really bad idea. I'm looking for comments, advice, and insight on this issue (which mode to REQUIRE) in the hope of resolving it in Salt Lake City in a fashion that won't come back to cause problems in IETF Last Call. For more information on IPS Security, see draft-ietf-ips-security-06.txt (-05 if -06 hasn't hit the servers yet). Thanks, --David (IPS WG co-chair) --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Nov 27 17:18:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS1IM807623; Tue, 27 Nov 2001 17:18:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05185 Tue, 27 Nov 2001 19:37:50 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: , "Paul Hoffman / VPNC" References: <003501c176c6$aa5fece0$1e72788a@andrewk3.ca.newbridge.com> Subject: Re: SOI: identity protection and DOS Date: Tue, 27 Nov 2001 19:47:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028E_01C1777C.56B16180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 00:46:51.0664 (UTC) FILETIME=[2B3AE100:01C177A6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_028E_01C1777C.56B16180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: "Paul Hoffman / VPNC" To: Sent: Monday, November 26, 2001 5:40 PM Subject: RE: SOI: identity protection and DOS > At 5:06 PM -0500 11/26/01, Andrew Krywaniuk wrote: > > > Positive traits of IKEv1 pre-shared keys: > >> a) easy for each party to set up > >> b) not susceptible to CRL time lag or CA key compromise > >> c) fewer exponentiations on each side for IPsec key setup > >> > >> Negative traits of IKEv1 pre-shared keys: > >> d) hard to scale > >> e) unless identity protection is not needed, the initiator must be = at > >> known IP address, and there must be only one pre-shared key at = that > >> address > > > f) out-of-band swapping of the key must be done privately > > > > > >Some comments on this: > > > >(e) is only due to a flaw in IKEv1, and is unrelated to the use of = preshared > >keys in general. >=20 > Yup. Some people think that identity protection is absolutely needed > in every circumstance, but most people would agree that identity > protection isn't worth preventing pre-shared secrets from working > with mobile users. >=20 > >(f) is not really valid because you need an out-of-band mechanism = either > >way. >=20 > Not true. You only need a authenticated transport for the public key > hashes: you don't have to keep them private. >=20 > >(d) is the real reason for not using preshared keys. >=20 > ...for some people. In many environments, scaling is not an an issue. > It is easy to argue that setting up simple CA and keeping its key I suppose the CA's public key never change. :-) Otherwise, the CA's new public key(s) has to pass on the phone too. > secret and issuing CRLs and so on for a 5-gateway WAN is more > difficult that passing around five preshared secrets on the phone. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 ------=_NextPart_000_028E_01C1777C.56B16180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From: "Paul Hoffman / VPNC" = <paul.hoffman@vpnc.org>
To: <ipsec@lists.tislabs.com>
Sent: Monday, November 26, 2001 5:40=20 PM
Subject: RE: SOI: identity protection = and=20 DOS

> At 5:06 PM -0500 11/26/01, Andrew = Krywaniuk=20 wrote:
> >  > Positive traits of IKEv1 pre-shared = keys:
>=20 >>  a) easy for each party to set up
> >>  = b) not=20 susceptible to CRL time lag or CA key compromise
> >>  = c) fewer=20 exponentiations on each side for IPsec key setup
> = >>
>=20 >>  Negative traits of IKEv1 pre-shared keys:
> = >> =20 d) hard to scale
> >>  e) unless identity protection is = not=20 needed, the initiator must be at
> >>  known IP = address, and=20 there must be only one pre-shared key at that
> >> =20 address
> >  > f) out-of-band swapping of the key must = be done=20 privately
> >
> >
> >Some comments on = this:
>=20 >
> >(e) is only due to a flaw in IKEv1, and is unrelated to = the use=20 of preshared
> >keys in general.
>
> Yup. Some = people=20 think that identity protection is absolutely needed
> in every=20 circumstance, but most people would agree that identity
> = protection isn't=20 worth preventing pre-shared secrets from working
> with mobile=20 users.
>
> >(f) is not really valid because you need an=20 out-of-band mechanism either
> >way.
>
> Not true. = You=20 only need a authenticated transport for the public key
> hashes: = you don't=20 have to keep them private.
>
> >(d) is the real reason = for not=20 using preshared keys.
>
> ...for some people. In many = environments,=20 scaling is not an an issue.
> It is easy to argue that setting up = simple=20 CA and keeping its key
I suppose the CA's = public key never=20 change. :-)
Otherwise, the CA's new = public key(s)=20 has to pass on the phone too.

> secret and issuing CRLs and so = on for a=20 5-gateway WAN is more
> difficult that passing around five = preshared=20 secrets on the phone.
>
> --Paul Hoffman, Director
> = --VPN=20 Consortium
>
------=_NextPart_000_028E_01C1777C.56B16180-- From owner-ipsec@lists.tislabs.com Tue Nov 27 17:18:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS1Ia807645; Tue, 27 Nov 2001 17:18:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05078 Tue, 27 Nov 2001 19:30:13 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: "david chen" Cc: "Paul Hoffman / VPNC" , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2001 19:39:42 -0500 Message-Id: <20011128003942.7DA0E7B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , "david chen" writes: >The very reason to certify a public key is that > if the key is not 'public' enough than it is subject to MIM attack. > >Self-signed cert is subject to MIM attack unless... >then why we need public/private key. You misunderstand. I'm suggesting that whatever secure channel could be used to share a symmetric key could be used to share a public key. If you can't trust that channel, you can't use pre-shared secrets, either. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Tue Nov 27 17:32:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS1Wt808228; Tue, 27 Nov 2001 17:32:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05247 Tue, 27 Nov 2001 19:49:01 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Sara Bitan" , "Derek Atkins" Cc: "Michael Thomas" , "Henry Spencer" , "ipsec list" References: <15362.31215.577809.622607@thomasm-u1.cisco.com> <004501c176bf$a3763a30$ec4c5ac2@commagine.net> Subject: Re: SOI: identity protection and DOS Date: Tue, 27 Nov 2001 19:58:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 00:58:02.0877 (UTC) FILETIME=[BB4DDAD0:01C177A7] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If pre-shared RSA public keys does not "expire" and never change for an identity then it is better; Otherwise, "managing pre-shared RSA public keys" will using private channel as managing pre-shared private keys or the cert and CA... --- David ----- Origina l Message ----- From: "Derek Atkins" To: "Sara Bitan" Cc: "Michael Thomas" ; "Henry Spencer" ; "ipsec list" Sent: Monday, November 26, 2001 9:05 PM Subject: Re: SOI: identity protection and DOS > Sara, > > Sara Bitan writes: > > > I think pre-shared keys authentication is a requirement, and it doesn't > > necessary imply huge overhead. There are several good (and popular) > > Do you mean pre-shared secret-key or pre-shared public-key? I happen > to agree with Steve that pre-shared public-key is sufficient (and > probably superior) to pre-shared secret-key authentication. In other > words, we pre-share RSA Public Keys. No certificates are necessarily > required. As was pointed out, see SSH for an example of how this > works. > > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > From owner-ipsec@lists.tislabs.com Tue Nov 27 17:34:02 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS1Y1808288; Tue, 27 Nov 2001 17:34:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA05275 Tue, 27 Nov 2001 19:53:32 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Hugo Krawczyk" , "Sara Bitan" Cc: "Michael Thomas" , "Henry Spencer" , "ipsec list" References: Subject: Re: SOI: identity protection and DOS Date: Tue, 27 Nov 2001 20:03:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 01:02:30.0574 (UTC) FILETIME=[5ADD2CE0:01C177A8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 0 check, blind trust. :-) --- David ----- Original Message ----- From: "Hugo Krawczyk" To: "Sara Bitan" Cc: "Michael Thomas" ; "Henry Spencer" ; "ipsec list" Sent: Tuesday, November 27, 2001 12:16 PM Subject: Re: SOI: identity protection and DOS > > I think that this observation by Sara is important: > > > > > An insecure certificates deployment will be much more harmful than a > > *correct* and useful pre-shared key authentication mode." > > For those that cite SSH as an example: much of the success of SSL > and SSH is based on the permissiveness with which people USE public > keys and certificates in these protocols (who reads certificate-related > pop-up warnings in https? how many consciously check a PK in a first > SSH handshake?) > > We want IPsec to succeed but not to "imitate" the above SSL and SSH > usage weaknesses. > > > Hugo > > > > > > On Mon, 26 Nov 2001, Sara Bitan wrote: > > > > Pre-shared keys do not require extra messages. > > The P-SIGMA protocol requires just three messages, like SIGMA. > > > > I think pre-shared keys authentication is a requirement, and it doesn't > > necessary imply huge overhead. There are several good (and popular) > > protocols out there that supply shared keys to two parties. > > I know that in the real world certificates are not as popular and widely > > used as we would like them to be. An insecure certificates deployment > will > > be much more harmful that a *correct* and useful pre-shared key > > authentication mode. > > > > Sara > > > > > From owner-ipsec@lists.tislabs.com Tue Nov 27 17:41:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS1fB808475; Tue, 27 Nov 2001 17:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05309 Tue, 27 Nov 2001 20:00:10 -0500 (EST) Message-Id: <200111280109.KAA03196@sucaba.isl.ntt.co.jp> To: ipsec@lists.tislabs.com cc: Shiho Moriai , Yiqun Lisa Yin , Satomi Okazaki Subject: The Use of Camellia with IPsec Date: Wed, 28 Nov 2001 10:09:24 JST From: Shiho MORIAI Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, We submitted the following I-D, which was announced in this mailing list on Mon, 19 Nov 2001 08:29:02 -0500: > Title : The Camellia Cipher Algorithm and Its Use with IPsec > Authors : S. Moriai, Y. L. Yin, S. Okazaki > Filename : draft-ietf-ipsec-ciph-camellia-00.txt > > Abstract : > This document describes the use of the Camellia block cipher > algorithm in Cipher Block Chaining Mode, with an explicit IV, as a > confidentiality mechanism within the context of the IPsec > Encapsulating Security Payload (ESP). The reason why we submitted this I-D as a working group draft is to find people interested in including the Camellia cipher in your IPsec implementation. Camellia is a 128-bit block cipher and supports 128-, 192-, and 256-bit key lengths, i.e. the same interface specifications as the AES. A reference code is available on the Camellia home page: http://info.isl.ntt.co.jp/camellia/ and we are planning to offer another optimized reference code. As we wrote in the I-D, Camellia was jointly developed by NTT and Mitsubishi Electric Corporation in 2000. Camellia was designed to have suitability for both software and hardware implementations and to cover all possible encryption applications that range from low-end smart cards to high-speed network systems. The most distinguished feature is its small hardware design. It can be implemented using only 8.12K gates using a 0.18um CMOS ASIC library [Camellia], which enables low power consumption hardware. It perfectly meets one of the current IPsec market requirements. ``AES should be more than sufficient,'' some people say. However, it would be preferable to have another option as an alternative to the AES. We believe that Camellia will be a good backup algorithm. Camellia has been submitted to several standardization bodies such as ISO (ISO/IEC 18033) and IETF (TLS working group) and it is under consideration. It has also been submitted to several cryptographic techniques evaluation projects such as NESSIE and CRYPTREC, and it has been scrutinized by worldwide cryptographic experts. In particular, the NESSIE project plans to develop by the end of 2002 a strong portfolio of crypto algorithms and intends to input these algorithms to standardization bodies such as ISO, IETF, and IEEE. In September 2001, the project announced its selection of the algorithms for the 2nd phase of the project. Camellia is one of the three 128-bit block cipher finalists selected out of 8 candidates. Since Camellia is becoming popular and a "standard" cipher in Japan, I was asked by some people to obtain IDs so that they can include it in their IPsec implementation. We would be very happy if you have interest in Camellia and grant us some time at the upcoming Salt Lake City IETF meeting. Comments and questions are welcome. Please address them to this mailing list. [Camellia] Aoki, K, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. Nakajima, and T. Tokita, "Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms,'' September, 2001, http://info.isl.ntt.co.jp/camellia/CRYPTREC/2001/01eeval.pdf. From owner-ipsec@lists.tislabs.com Tue Nov 27 18:00:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS20Q809006; Tue, 27 Nov 2001 18:00:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05397 Tue, 27 Nov 2001 20:13:48 -0500 (EST) To: "Steven M. Bellovin" Cc: "david chen" , "Paul Hoffman / VPNC" , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: <20011128003942.7DA0E7B55@berkshire.research.att.com> From: Derek Atkins Date: 27 Nov 2001 20:23:13 -0500 In-Reply-To: "Steven M. Bellovin"'s message of "Tue, 27 Nov 2001 19:39:42 -0500" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" writes: > You misunderstand. I'm suggesting that whatever secure channel could > be used to share a symmetric key could be used to share a public key. > If you can't trust that channel, you can't use pre-shared secrets, > either. To play devil's advocate, you can (relatively-) easily share a secret via voice and telephone. Sharing a public key via telephone is much more challenging. OTOH, one could send the public key via email and then vocally exchange a hash of the key, so I suppose it's six or one-half dozen.... > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 27 18:04:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS249809129; Tue, 27 Nov 2001 18:04:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05476 Tue, 27 Nov 2001 20:19:52 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: to-smb From: "Steven M. Bellovin" To: Derek Atkins Cc: "david chen" , "Paul Hoffman / VPNC" , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 27 Nov 2001 20:29:20 -0500 Message-Id: <20011128012921.F0F457B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Derek Atkins writes: >"Steven M. Bellovin" writes: > >> You misunderstand. I'm suggesting that whatever secure channel could >> be used to share a symmetric key could be used to share a public key. >> If you can't trust that channel, you can't use pre-shared secrets, >> either. > >To play devil's advocate, you can (relatively-) easily share a >secret via voice and telephone. Sharing a public key via telephone >is much more challenging. > >OTOH, one could send the public key via email and then vocally >exchange a hash of the key, so I suppose it's six or one-half >dozen.... Bingo. (And we'll leave out the question of whether or not the phone is secure enough -- an eavesdropper could profit by learning a preshared secret, but not by learning a key hash.) The real question, though, is not whether or not preshared keys are useful -- they are, in some situations, though not as often as many people think -- but what is the best *security engineering* tradeoff. I feel quite strongly that complicating our key exchange protocol to enable their use is a bad idea, especially since they have other disadvantages, as has been noted before. From owner-ipsec@lists.tislabs.com Tue Nov 27 18:44:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS2iW810809; Tue, 27 Nov 2001 18:44:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA05574 Tue, 27 Nov 2001 20:51:55 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Alex Alten'" , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Tue, 27 Nov 2001 20:58:19 -0500 Message-ID: <002c01c177b0$280218a0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3.0.3.32.20011127092421.00f70cd0@mail> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Your argument is silly. Visa and ATM transactions aren't secure. There are multiple cases where large credit card databases have been compromised (often when an online merchant's website is hacked). I concur with a point someone else made recently, which is that the only reason I use Visa is that they are willing to cover the cost of fraud (by passing it on to the merchants, who pass it on to all customers, not just credit card users). Small-scale fraud is just the cost of doing business. Visa's main defense is that repeat offenders will be caught by statistical analysis. Do I use ATMs? Yes. Are they safer than keeping my money in a shoebox in my bedroom? Yes. Do I really feel that my money is secure? No. There's a reason why I have a daily withdrawal limit, despite the fact that it can be inconvenient at times. The prospect of electronic money is scary enough. Electronic money protected by DES keys does not bode well for the future. It's funny that you should bring up the issue of PSK vs. PK signatures in the context of banking. In the future, when I make a purchase or a deposit, I certainly hope there will be non-repudiation of the transaction. And that goes doubly for transactions between large banks. I don't claim to understand what checks and balances are preventing financial institutions in the Caymen islands from "inventing" money, but the use of PK signatures couldn't hurt in the context of forensic accounting. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > Sent: Tuesday, November 27, 2001 12:24 PM > To: Hugo Krawczyk; IPsec WG > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > At 01:34 AM 11/27/2001 +0200, Hugo Krawczyk wrote: > >Everyone agrees that public key is the ONLY way to a scalable > >Internet-wide protocol. No question about it. In particular, > >any key-exchange protocol for IPsec MUST provide a PK-based exchange. > > > > No. I STRONGLY disagree. I'll give a counter example. The banking > ATM network uses DES keys. It has scaled, in practice, world wide. > > And BTW, it's security & trust model is excellent. Have you > ever heard > of a major compromise, say on the scale of 25,000 card #'s > being stolen > (like with Visa?). Certainly nobody distrusts it because it uses > symmetric keys for authentication. In fact I'm certain YOU trust it > at least a couple a times a month. :-) > > - Alex > > > > -- > > Alex Alten > Alten@Home.Com > > From owner-ipsec@lists.tislabs.com Tue Nov 27 19:13:51 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS3Dp812194; Tue, 27 Nov 2001 19:13:51 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05758 Tue, 27 Nov 2001 21:32:48 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Hoffman / VPNC'" , Subject: RE: SOI: identity protection and DOS Date: Tue, 27 Nov 2001 21:39:15 -0500 Message-ID: <002d01c177b5$dfcc2b10$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >(e) is only due to a flaw in IKEv1, and is unrelated to the > use of preshared > >keys in general. > > Yup. Some people think that identity protection is absolutely needed > in every circumstance, but most people would agree that identity > protection isn't worth preventing pre-shared secrets from working > with mobile users. Well, my point was more that there isn't a conflict between preshared keys and identity protection (of the passive variety). If the PSK & PKsig SKEYID derivations in IKEv1 had been the same (as they could have been), this argument would have never come up. As some may recall, Hugo originally argued that the PKsig authentication method was inadequately secure because its strength was based solely on the strength of the DH algorithm. The SKEYID for PSK was based on the DH value + a secret value. Therefore, the decision to define the SKEYID this way was merely a design tradeoff of identity protection for increased security. As we noted in draft-improveike (and elsewhere), this tradeoff was not necessary since an alternate SKEYID derivation could have given us both properties. > >(f) is not really valid because you need an out-of-band > mechanism either > >way. > > Not true. You only need a authenticated transport for the public key > hashes: you don't have to keep them private. I thought about this, but the distinction is mostly moot because there aren't that many circumstances where you can get authentication without secrecy. Maybe if you phoned the person and you thought the phone might be tapped but you could recognize their voice... Other popular key distribution techniques, such as e-mail, finger, websites, voice-mail from an administrator are unlikely to have that property where they are (meaningfully) authenticated but not secret. > >(d) is the real reason for not using preshared keys. > > ...for some people. In many environments, scaling is not an an issue. > It is easy to argue that setting up simple CA and keeping its key > secret and issuing CRLs and so on for a 5-gateway WAN is more > difficult that passing around five preshared secrets on the phone. Actually, I forgot to mention the point that PK crypto only scales well when you have a CA. Sharing your self-signed cert with 500 people is no easier than sharing 500 different preshared keys. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC > Sent: Monday, November 26, 2001 5:40 PM > To: ipsec@lists.tislabs.com > Subject: RE: SOI: identity protection and DOS > > > At 5:06 PM -0500 11/26/01, Andrew Krywaniuk wrote: > > > Positive traits of IKEv1 pre-shared keys: > >> a) easy for each party to set up > >> b) not susceptible to CRL time lag or CA key compromise > >> c) fewer exponentiations on each side for IPsec key setup > >> > >> Negative traits of IKEv1 pre-shared keys: > >> d) hard to scale > >> e) unless identity protection is not needed, the > initiator must be at > >> known IP address, and there must be only one pre-shared > key at that > >> address > > > f) out-of-band swapping of the key must be done privately > > > > > >Some comments on this: > > > >(e) is only due to a flaw in IKEv1, and is unrelated to the > use of preshared > >keys in general. > > Yup. Some people think that identity protection is absolutely needed > in every circumstance, but most people would agree that identity > protection isn't worth preventing pre-shared secrets from working > with mobile users. > > >(f) is not really valid because you need an out-of-band > mechanism either > >way. > > Not true. You only need a authenticated transport for the public key > hashes: you don't have to keep them private. > > >(d) is the real reason for not using preshared keys. > > ...for some people. In many environments, scaling is not an an issue. > It is easy to argue that setting up simple CA and keeping its key > secret and issuing CRLs and so on for a 5-gateway WAN is more > difficult that passing around five preshared secrets on the phone. > > --Paul Hoffman, Director > --VPN Consortium > From owner-ipsec@lists.tislabs.com Tue Nov 27 19:38:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS3cl814650; Tue, 27 Nov 2001 19:38:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05858 Tue, 27 Nov 2001 21:55:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Steven M. Bellovin" Cc: "david chen" , "Paul Hoffman / VPNC" , Subject: Re: SOI: identity protection and DOS References: <20011128003942.7DA0E7B55@berkshire.research.att.com> From: "Derek Atkins" Date: 27 Nov 2001 20:23:13 -0500 In-Reply-To: "Steven M. Bellovin"'s message of "Tue, 27 Nov 2001 19:39:42 -0500" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 28 Nov 2001 02:25:55.0703 (UTC) FILETIME=[02274070:01C177B4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Steven M. Bellovin" writes: > You misunderstand. I'm suggesting that whatever secure channel could > be used to share a symmetric key could be used to share a public key. > If you can't trust that channel, you can't use pre-shared secrets, > either. To play devil's advocate, you can (relatively-) easily share a secret via voice and telephone. Sharing a public key via telephone is much more challenging. OTOH, one could send the public key via email and then vocally exchange a hash of the key, so I suppose it's six or one-half dozen.... > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 27 19:38:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS3cv814681; Tue, 27 Nov 2001 19:38:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA05859 Tue, 27 Nov 2001 21:55:22 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <200111280109.KAA03196@sucaba.isl.ntt.co.jp> To: Cc: "Shiho Moriai" , "Yiqun Lisa Yin" , "Satomi Okazaki" Subject: The Use of Camellia with IPsec Date: Wed, 28 Nov 2001 10:09:24 JST From: "Shiho MORIAI" X-OriginalArrivalTime: 28 Nov 2001 02:02:16.0687 (UTC) FILETIME=[B45A97F0:01C177B0] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, We submitted the following I-D, which was announced in this mailing list on Mon, 19 Nov 2001 08:29:02 -0500: > Title : The Camellia Cipher Algorithm and Its Use with IPsec > Authors : S. Moriai, Y. L. Yin, S. Okazaki > Filename : draft-ietf-ipsec-ciph-camellia-00.txt > > Abstract : > This document describes the use of the Camellia block cipher > algorithm in Cipher Block Chaining Mode, with an explicit IV, as a > confidentiality mechanism within the context of the IPsec > Encapsulating Security Payload (ESP). The reason why we submitted this I-D as a working group draft is to find people interested in including the Camellia cipher in your IPsec implementation. Camellia is a 128-bit block cipher and supports 128-, 192-, and 256-bit key lengths, i.e. the same interface specifications as the AES. A reference code is available on the Camellia home page: http://info.isl.ntt.co.jp/camellia/ and we are planning to offer another optimized reference code. As we wrote in the I-D, Camellia was jointly developed by NTT and Mitsubishi Electric Corporation in 2000. Camellia was designed to have suitability for both software and hardware implementations and to cover all possible encryption applications that range from low-end smart cards to high-speed network systems. The most distinguished feature is its small hardware design. It can be implemented using only 8.12K gates using a 0.18um CMOS ASIC library [Camellia], which enables low power consumption hardware. It perfectly meets one of the current IPsec market requirements. ``AES should be more than sufficient,'' some people say. However, it would be preferable to have another option as an alternative to the AES. We believe that Camellia will be a good backup algorithm. Camellia has been submitted to several standardization bodies such as ISO (ISO/IEC 18033) and IETF (TLS working group) and it is under consideration. It has also been submitted to several cryptographic techniques evaluation projects such as NESSIE and CRYPTREC, and it has been scrutinized by worldwide cryptographic experts. In particular, the NESSIE project plans to develop by the end of 2002 a strong portfolio of crypto algorithms and intends to input these algorithms to standardization bodies such as ISO, IETF, and IEEE. In September 2001, the project announced its selection of the algorithms for the 2nd phase of the project. Camellia is one of the three 128-bit block cipher finalists selected out of 8 candidates. Since Camellia is becoming popular and a "standard" cipher in Japan, I was asked by some people to obtain IDs so that they can include it in their IPsec implementation. We would be very happy if you have interest in Camellia and grant us some time at the upcoming Salt Lake City IETF meeting. Comments and questions are welcome. Please address them to this mailing list. [Camellia] Aoki, K, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, J. Nakajima, and T. Tokita, "Camellia: A 128-Bit Block Cipher Suitable for Multiple Platforms,'' September, 2001, http://info.isl.ntt.co.jp/camellia/CRYPTREC/2001/01eeval.pdf. From owner-ipsec@lists.tislabs.com Tue Nov 27 19:55:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS3tA816055; Tue, 27 Nov 2001 19:55:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA05902 Tue, 27 Nov 2001 22:13:37 -0500 (EST) Date: Tue, 27 Nov 2001 19:24:01 -0800 (PST) From: Srinivasa Addepalli To: Black_David@emc.com cc: ipsec@lists.tislabs.com, saag@mit.edu Subject: Re: IP Storage and IPsec encapsulation In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi David, It seems to me that this is policy and deployment issue. It seems that you have following scenario: StorageClient---Router1-----(Internet)------Router2-----StorageSrvr StorageClient and StorageSrvr terminate iSCSI connection. If end-to-end security is needed, then both client and server should be IPSEC enabled. In this particular case, these are IPSEC hosts and as per IPSEC standard, a host MUST support both transport and tunnel modes. If end-to-end security is not needed, then Router1 and router2 can be IPSEC enabled. In this case, tunnel mode is required in Router1 and Router2. Alternatively, IPSEC session can be between StorageClient and router2 OR Router1 to StorageServer. In these two cases, tunnel mode is required. If IPS group likes to allow only end-to-end security and avoid any admin mistakes, then transport mode can be made MUST. But I am not sure whether somebody would like to do that. Srini On Tue, 27 Nov 2001 Black_David@emc.com wrote: > Picking up a baseball bat and carefully drawing a bead on > the hornet's nest ... > > Over in the IP Storage (ips) WG, we're picking up a subset > of IPsec (primarily ESP and IKE) to provide security for > our protocols (TCP/IP encapsulations of SCSI and Fibre > Channel - iSCSI, FCIP, and iFCP). This approach is being > used in order to avoid putting out new protocol standards > that require things like DES and AH (comments in favor > of DES and/or AH should be sent to /dev/null ;-) ). > > >From a protocol specification standpoint, the IPS WG is > not prepared to require Integrated or Bump In The > Stack implementations of IPsec. In other words, the > WG does not want to foreclose the ability to take an IP > Storage protocol implementation without IPsec, hook it up > directly to a security gateway IPsec implementation and > obtain a result from the combination that complies with > the security requirements of the IPS protocol specification. > The protocol on the link between the IP Storage implementation > and its security gateway would NOT be compliant because > it would lack required security functionality (this latter > point was explained at length by the IESG in the London > plenary). > > Since IP Storage implementations could be based on host or > security gateway implementations of IPsec, the appropriate > thing to do in the IP Storage drafts appears to be to > REQUIRE tunnel mode as the encapsulation mode that > must be present for interoperability because it is the > common mode required by both classes of IPsec implementations. > OTOH, I've heard concerns that tunnel mode may not provide > a suitable bias towards end-to-end security - it's not that > difficult to terminate an IPsec tunnel someplace other than > the far end of the communication session running through it. > OTOOH, this concern strikes me as a policy issue - if some > node other than the far end can terminate the IPsec tunnel, > that node must have the keying material required to set up > the tunnel mode SA in the first place. In turn that > reflects a conscious security policy decision by the > administrator who configured that material into that > intermediate node and got exactly what s/he asked for. > This policy aspect is unavoidable, as the only way to > remove this option (tunnel mode to a gateway not at > the far end) from the admin's hands is to forbid > tunnel mode, which seems like a really bad idea. > > I'm looking for comments, advice, and insight on this > issue (which mode to REQUIRE) in the hope of resolving it > in Salt Lake City in a fashion that won't come back to > cause problems in IETF Last Call. For more information > on IPS Security, see draft-ietf-ips-security-06.txt (-05 > if -06 hasn't hit the servers yet). > > Thanks, > --David (IPS WG co-chair) > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > -- Srinivasa Rao Addepalli Intoto Inc. 3160, De La Cruz Blvd #100 Santa Clara, CA USA Ph: 408-844-0480 x317 From owner-ipsec@lists.tislabs.com Tue Nov 27 21:23:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS5Ng822134; Tue, 27 Nov 2001 21:23:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06074 Tue, 27 Nov 2001 23:27:23 -0500 (EST) To: Cc: "'Paul Hoffman / VPNC'" , Subject: Re: SOI: identity protection and DOS References: <002d01c177b5$dfcc2b10$1e72788a@andrewk3.ca.newbridge.com> From: Derek Atkins Date: 27 Nov 2001 23:36:55 -0500 In-Reply-To: "Andrew Krywaniuk"'s message of "Tue, 27 Nov 2001 21:39:15 -0500" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Andrew Krywaniuk" writes: > Actually, I forgot to mention the point that PK crypto only scales well when > you have a CA. Sharing your self-signed cert with 500 people is no easier > than sharing 500 different preshared keys. Actually, that's not true. If you have a full mesh of 500 people sharing keys, then with shared secrets you have 500^2 == 250,000 shared keys (assuming each pair share a unique key). OTOH with public keys (preshared or otherwise) you only need a total of 500 keys in the system. How the public keys are verified (either by CA validation or by pre-sharing them and validating by hand) is irrelevant to this particular discussion. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 27 21:53:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS5r1823547; Tue, 27 Nov 2001 21:53:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA06206 Wed, 28 Nov 2001 00:06:47 -0500 (EST) Message-ID: <000a01c177cb$5c762e80$9865fea9@TRLSHUKLA1> From: "Jayant Shukla" To: Subject: Re: LAST CALL: NAT TRAVERSAL DRAFTS Date: Tue, 27 Nov 2001 21:13:04 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C17788.4DD707C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C17788.4DD707C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These drafts infringe on our pending patents, specifically the part = about transport mode ESP encapsulation.=20 BTW, the original ESP-UDP proposal does not infringe on our IP. The = modifications=20 that were made after the San Diego meeting (where we presented our proposal) are the problem. regards, Jayant ------=_NextPart_000_0007_01C17788.4DD707C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
These drafts infringe on our pending = patents,=20 specifically the part about transport = mode
ESP encapsulation.
 
BTW, the original ESP-UDP proposal = does not=20 infringe on our IP. The modifications =
that were made after the San Diego = meeting (where=20 we presented
our proposal) are the = problem.
 
regards,
Jayant
 
------=_NextPart_000_0007_01C17788.4DD707C0-- From owner-ipsec@lists.tislabs.com Tue Nov 27 23:33:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS7Xw805339; Tue, 27 Nov 2001 23:33:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06349 Wed, 28 Nov 2001 01:41:03 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: Cc: "'Paul Hoffman / VPNC'" , Subject: Re: SOI: identity protection and DOS References: <002d01c177b5$dfcc2b10$1e72788a@andrewk3.ca.newbridge.com> From: "Derek Atkins" Date: 27 Nov 2001 23:36:55 -0500 In-Reply-To: "Andrew Krywaniuk"'s message of "Tue, 27 Nov 2001 21:39:15 -0500" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 28 Nov 2001 05:45:39.0203 (UTC) FILETIME=[E8E03D30:01C177CF] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Andrew Krywaniuk" writes: > Actually, I forgot to mention the point that PK crypto only scales well when > you have a CA. Sharing your self-signed cert with 500 people is no easier > than sharing 500 different preshared keys. Actually, that's not true. If you have a full mesh of 500 people sharing keys, then with shared secrets you have 500^2 == 250,000 shared keys (assuming each pair share a unique key). OTOH with public keys (preshared or otherwise) you only need a total of 500 keys in the system. How the public keys are verified (either by CA validation or by pre-sharing them and validating by hand) is irrelevant to this particular discussion. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Tue Nov 27 23:34:12 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS7YB805361; Tue, 27 Nov 2001 23:34:11 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA06361 Wed, 28 Nov 2001 01:48:08 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Steven M. Bellovin" Cc: "Paul Hoffman / VPNC" , References: <20011128003942.7DA0E7B55@berkshire.research.att.com> Subject: Re: SOI: identity protection and DOS Date: Wed, 28 Nov 2001 01:46:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 06:45:34.0835 (UTC) FILETIME=[480A2430:01C177D8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I try to say that if self-signed certs depend on the out-of-band 'secured channel' that is used the same as pre-shared key for its key management, then why not just use pre-shared key? and save the trouble for public/private keys. Don't see the advantage of using 'self-cert' over 'pre-shared' in this case. --- David ----- Original Message ----- From: "Steven M. Bellovin" To: "david chen" Cc: "Paul Hoffman / VPNC" ; Sent: Tuesday, November 27, 2001 7:39 PM Subject: Re: SOI: identity protection and DOS > In message , "david chen" writes: > >The very reason to certify a public key is that > > if the key is not 'public' enough than it is subject to MIM attack. > > > >Self-signed cert is subject to MIM attack unless... > >then why we need public/private key. > > You misunderstand. I'm suggesting that whatever secure channel could > be used to share a symmetric key could be used to share a public key. > If you can't trust that channel, you can't use pre-shared secrets, > either. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > > From owner-ipsec@lists.tislabs.com Wed Nov 28 00:44:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS8iM815157; Wed, 28 Nov 2001 00:44:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA06576 Wed, 28 Nov 2001 02:49:06 -0500 (EST) Date: Wed, 28 Nov 2001 05:02:33 -0500 From: Richard Guy Briggs To: david chen Cc: "Steven M. Bellovin" , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS Message-ID: <20011128050233.M29742@grendel.conscoop.ottawa.on.ca> References: <20011128003942.7DA0E7B55@berkshire.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ietf_davidchen@hotmail.com on Wed, Nov 28, 2001 at 01:46:07AM -0500 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Nov 28, 2001 at 01:46:07AM -0500, david chen wrote: > I try to say that > if self-signed certs depend on the out-of-band 'secured channel' that > is used the same as pre-shared key for its key management, > then why not just use pre-shared key? and save the trouble for > public/private keys. > > Don't see the advantage of using 'self-cert' over 'pre-shared' in this case. For pre-shared keys, your secure channel *must* be private. For self-cert, your secure channel to verify the key does not depend on privacy for security. This is the whole point of PK. This seems fairly obvious to me. ...or am I missing something? > --- David > > > ----- Original Message ----- > From: "Steven M. Bellovin" > To: "david chen" > Cc: "Paul Hoffman / VPNC" ; > Sent: Tuesday, November 27, 2001 7:39 PM > Subject: Re: SOI: identity protection and DOS > > > > In message , "david chen" writes: > > >The very reason to certify a public key is that > > > if the key is not 'public' enough than it is subject to MIM attack. > > > > > >Self-signed cert is subject to MIM attack unless... > > >then why we need public/private key. > > > > You misunderstand. I'm suggesting that whatever secure channel could > > be used to share a symmetric key could be used to share a public key. > > If you can't trust that channel, you can't use pre-shared secrets, > > either. > > > > --Steve Bellovin, http://www.research.att.com/~smb > > Full text of "Firewalls" book now at http://www.wilyhacker.com > > > > > > slainte mhath, RGB -- Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada -- \@ @ No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- _______GTVS6#790__(*)_______(*)(*)_______ From owner-ipsec@lists.tislabs.com Wed Nov 28 04:20:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASCKL807770; Wed, 28 Nov 2001 04:20:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07039 Wed, 28 Nov 2001 06:23:03 -0500 (EST) Date: Wed, 28 Nov 2001 13:32:43 +0200 (Israel Standard Time) From: Arne Ansper To: Derek Atkins cc: Subject: Re: SOI: identity protection and DOS In-Reply-To: Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > To play devil's advocate, you can (relatively-) easily share a > secret via voice and telephone. Sharing a public key via telephone > is much more challenging. > > OTOH, one could send the public key via email and then vocally > exchange a hash of the key, so I suppose it's six or one-half > dozen.... even better: exchange the hash via phone and send the key during protocol. why it's better? if we have systems that use shared secrets for authentication and procedures for exchanging those keys we can keep those systems and simply replace "shared secret" with "hash of the public key". (i'm talking from managemental perspective of course). "shared secret" and "hash of the public key" look very much the same when we are talking about secure shared secrets (long enough and random enough). this way we have a kind of upgrade path for those systems that are currently using shared secrets for authentication and would like to swich over to new key exchange protocol. arne From owner-ipsec@lists.tislabs.com Wed Nov 28 04:23:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASCNt808008; Wed, 28 Nov 2001 04:23:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA07097 Wed, 28 Nov 2001 06:37:50 -0500 (EST) Date: Wed, 28 Nov 2001 13:47:58 +0200 (Israel Standard Time) From: Arne Ansper To: Richard Guy Briggs cc: david chen , "Steven M. Bellovin" , Paul Hoffman / VPNC , Subject: Re: SOI: identity protection and DOS In-Reply-To: <20011128050233.M29742@grendel.conscoop.ottawa.on.ca> Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For pre-shared keys, your secure channel *must* be private. For > self-cert, your secure channel to verify the key does not depend on > privacy for security. This is the whole point of PK. > > This seems fairly obvious to me. ...or am I missing something? in addition to that: if you backup the configuration of your IPsec enabled device and you are using shared secrets you must ensure that nowbody has a chance to read the backup. if you are using public keys that are authenticated using preshared information you must only make sure that the backup is tamperproof or perhaps even tamper evidence is sufficient. if you are keeping your private key in smartcard or HSM then even the system administrator (who backups the system) cannot copy it. you cannot do it with shared secrets. in practice you must ensure the availability and confidentiality at the same time and without spending too much. if look at the complete system (not just the security properites of the key exchange protocol) it's much easier to achieve this goal when you are using public keys for authentication. arne From owner-ipsec@lists.tislabs.com Wed Nov 28 06:01:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASE1M815185; Wed, 28 Nov 2001 06:01:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07299 Wed, 28 Nov 2001 08:11:59 -0500 (EST) Date: Wed, 28 Nov 2001 08:20:51 -0500 (EST) From: Henry Spencer To: david chen cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 28 Nov 2001, david chen wrote: > I try to say that > if self-signed certs depend on the out-of-band 'secured channel' that > is used the same as pre-shared key for its key management, > then why not just use pre-shared key? and save the trouble for > public/private keys. > Don't see the advantage of using 'self-cert' over 'pre-shared' in this case. At least three advantages: 1) Self-certs need not be kept secret to be usable. So the channel used to verify them must be authenticated but need not be private, they need not be stored in secure storage, etc. 2) No requirement to have a separate self-cert for each connection; one per host suffices. 3) Uses much the same mechanism as PKI certificates, so there is no need to have a different variant of the protocol (different analysis and verification, different code, etc.) for them. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 28 06:43:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASEhx817536; Wed, 28 Nov 2001 06:43:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07437 Wed, 28 Nov 2001 08:58:38 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Henry Spencer Cc: david chen , ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Nov 2001 09:08:07 -0500 Message-Id: <20011128140807.B75E27B55@berkshire.research.att.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Henry Spe ncer writes: >On Wed, 28 Nov 2001, david chen wrote: >> I try to say that >> if self-signed certs depend on the out-of-band 'secured channel' that >> is used the same as pre-shared key for its key management, >> then why not just use pre-shared key? and save the trouble for >> public/private keys. >> Don't see the advantage of using 'self-cert' over 'pre-shared' in this case. > >At least three advantages: > >1) Self-certs need not be kept secret to be usable. So the channel used >to verify them must be authenticated but need not be private, they need >not be stored in secure storage, etc. > >2) No requirement to have a separate self-cert for each connection; one >per host suffices. > >3) Uses much the same mechanism as PKI certificates, so there is no need >to have a different variant of the protocol (different analysis and >verification, different code, etc.) for them. 4) We don't need a key exchange protocol capable of coping with both certificates and shared secrets. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ipsec@lists.tislabs.com Wed Nov 28 06:51:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASEpK817753; Wed, 28 Nov 2001 06:51:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07520 Wed, 28 Nov 2001 09:06:39 -0500 (EST) Message-Id: <200111272336.fARNaXEH020283@coredump.cs.columbia.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Jan Vilhuber Cc: Radia Perlman - Boston Center for Networking , mat@cisco.com, rcharlet@redcreek.com, ipsec@lists.tislabs.com Subject: Re: SOI: selector exclusion lists/ranges In-reply-to: Your message of "Tue, 27 Nov 2001 15:32:15 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 Nov 2001 18:36:33 -0500 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message , Jan Vilhuber writes: > >If I read and understood it correctly this time, does this make the >ID_RECURSE payload (Bad name.. did I already mention that?! ;) obsolete? At >least for ikev2... I think it does. -Angelos PS. I must be missing something: why is ID_RECURSE a bad name ? From owner-ipsec@lists.tislabs.com Wed Nov 28 06:54:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASEsD817869; Wed, 28 Nov 2001 06:54:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07514 Wed, 28 Nov 2001 09:06:37 -0500 (EST) Message-Id: <200111271333.fARDX3U01382@fatty.lounge.org> To: Michael Thomas Cc: ipsec list Subject: Re: SOI: selector exclusion lists/ranges In-Reply-To: Your message of "Tue, 27 Nov 2001 12:09:14 PST." <15363.62186.160914.487198@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1379.1006867983.1@tibernian.com> Date: Tue, 27 Nov 2001 05:33:03 -0800 From: Dan Harkins Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The Traffic Selector Payload consists of a list of Traffic Selector Substructures each of which have start-port and end-port entries. So you can specify ports 1-78 and 80-1023 if you wanted to protect all ports less than 1024 except 79. They can't represent things that fall outside of a selector since they are designed to represent the selector itself. But I think they can do what you want. Check out section 7.13 in the IKEv2 draft. Note that while IKEv2 can express this an RFC2401-compliant IPsec implementation could not have a selector like this for IKEv2 to represent. The restriction in RFC2401 was because of a limitation in RFC2408 though so hopefully a rev of RFC2401 will include port ranges. Dan. On Tue, 27 Nov 2001 12:09:14 PST you wrote > > Thus I think we should have a requirement which > states: > > "The protocol MUST have the ability to express > port ranges for flow selectors, as well as have > the ability to selectively enumerate ports which > fall outside of the flow selector." > > Mike From owner-ipsec@lists.tislabs.com Wed Nov 28 06:57:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASEvj817983; Wed, 28 Nov 2001 06:57:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07557 Wed, 28 Nov 2001 09:12:46 -0500 (EST) Date: Wed, 28 Nov 2001 09:21:46 -0500 (EST) From: Henry Spencer To: "Steven M. Bellovin" cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS In-Reply-To: <20011128140807.B75E27B55@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 28 Nov 2001, Steven M. Bellovin wrote: > >3) Uses much the same mechanism as PKI certificates, so there is no need > >to have a different variant of the protocol (different analysis and > >verification, different code, etc.) for them. > > 4) We don't need a key exchange protocol capable of coping with both > certificates and shared secrets. I believe that's essentially the same as my #3, phrased differently. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Nov 28 07:05:06 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASF55818184; Wed, 28 Nov 2001 07:05:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA07582 Wed, 28 Nov 2001 09:18:58 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15364.62563.431622.258994@mail.dev.equallogic.com> Date: Wed, 28 Nov 2001 09:27:47 -0500 (EST) From: Paul Koning To: andrew.krywaniuk@alcatel.com Cc: ipsec@lists.tislabs.com Subject: RE: SOI: identity protection and DOS References: <002d01c177b5$dfcc2b10$1e72788a@andrewk3.ca.newbridge.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Andrew" == Andrew Krywaniuk writes: >> ... >> Not true. You only need a authenticated transport for the public >> key hashes: you don't have to keep them private. Andrew> I thought about this, but the distinction is mostly moot Andrew> because there aren't that many circumstances where you can Andrew> get authentication without secrecy. Maybe if you phoned the Andrew> person and you thought the phone might be tapped but you Andrew> could recognize their voice... Other popular key distribution Andrew> techniques, such as e-mail, finger, websites, voice-mail from Andrew> an administrator are unlikely to have that property where Andrew> they are (meaningfully) authenticated but not secret. You left out a well established public key distribution scheme that fits the description: the PGP Web of Trust. There is even a spec for the use of PGP keys with IKE. I remember at least one implementation (don't know how many more there are). If people are interested in a scheme that doesn't require the out of band channel to have privacy (as shared secrets do), allows for self-signed keys but isn't limited to them, and doesn't have the insistence on centralization that the X.509 style CA schemes have, wider implementation of that spec would be an option to consider. paul From owner-ipsec@lists.tislabs.com Wed Nov 28 08:38:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASGcK828745; Wed, 28 Nov 2001 08:38:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA07897 Wed, 28 Nov 2001 10:33:34 -0500 (EST) Date: Wed, 28 Nov 2001 08:25:07 -0700 From: Joel Snyder Subject: Gee, shared secrets suck (was: Re: SOI: identity protection and DOS) To: ipsec@lists.tislabs.com Cc: Arne Ansper , Richard Guy Briggs , david chen , "Steven M. Bellovin" , Paul Hoffman / VPNC Message-id: <3C0501D3.314FE58A@opus1.com> Organization: Opus One MIME-version: 1.0 X-Mailer: Mozilla 4.78C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > in addition to that: if you backup the configuration of your IPsec enabled > device and you are using shared secrets you must ensure that nowbody has a > chance to read the backup. if you are using public keys that are > authenticated using preshared information you must only make sure that the > backup is tamperproof or perhaps even tamper evidence is sufficient. Why is that? Is it because you have somehow forgotten to also backup the private key part of the public/private key pair? Sure, as long as you don't store the private key anywhere in your backups, then you don't have to worry about it being stolen/lost/compromised---whether it's what we think of as a 'pre-shared secret' or 'uncertified private/public key pair.' But none of this matters. No one is arguing why authentication methods using public keys or digital certificates are better for authentication and security than pre-shared secrets. The fact is, however, that end users of these products have overwhelmingly voted with their implementations to use pre-shared secrets for site-to-site authentication (and, if you consider SecurID as a 'preshared secret,' also for remote access). Creators of these products have done an abyssmal job of enabling either interoperability, security, and manageability using anything longer than an easily rattled-off string. If you want to be sure that no one uses IKEv2 in real networks, then force them to transfer a 1024-bit (or longer) value, or even the 128-bit hash of that value. Everyone agrees that PSS have defects compared to other authentication methods. You protocol geeks have to pull your heads out of the packets and look at how people have actually implemented the protocol management system and how end users have actually implemented VPNs. You must have something akin to the simplicity and shortness of PSS to ensure that people will be able to at least prototype these systems in their networks. When they go the long haul and build huge VPNs---if they ever choose to do that---then other authentication methods, such as digital certificates, will be welcome additions to the protocol. But every large VPN installation starts out as a small VPN installation, and 99% of small VPN installations start with pre-shared secrets. jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 +1 520 324 0494 x101 (voice) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One Electronic mail is always the best way to contact me. From owner-ipsec@lists.tislabs.com Wed Nov 28 08:54:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASGsa829406; Wed, 28 Nov 2001 08:54:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA07956 Wed, 28 Nov 2001 11:08:01 -0500 (EST) Message-ID: <000001c17827$bcd66770$9865fea9@TRLSHUKLA1> From: "Jayant Shukla" To: Subject: Re: LAST CALL: NAT TRAVERSAL DRAFTS Date: Tue, 27 Nov 2001 21:13:04 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C17788.4DD707C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C17788.4DD707C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These drafts infringe on our pending patents, specifically the part = about transport mode ESP encapsulation.=20 BTW, the original ESP-UDP proposal does not infringe on our IP. The = modifications=20 that were made after the San Diego meeting (where we presented our proposal) are the problem. regards, Jayant ------=_NextPart_000_0007_01C17788.4DD707C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
These drafts infringe on our pending = patents,=20 specifically the part about transport = mode
ESP encapsulation.
 
BTW, the original ESP-UDP proposal = does not=20 infringe on our IP. The modifications =
that were made after the San Diego = meeting (where=20 we presented
our proposal) are the = problem.
 
regards,
Jayant
 
------=_NextPart_000_0007_01C17788.4DD707C0-- From owner-ipsec@lists.tislabs.com Wed Nov 28 09:48:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASHmw803373; Wed, 28 Nov 2001 09:48:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08094 Wed, 28 Nov 2001 11:56:07 -0500 (EST) Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869890@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Steven M. Bellovin'" , alexey.vyskubov@nokia.com Cc: ipsec@lists.tislabs.com Subject: RE: Just Fast Keying (JFK) draft Date: Wed, 28 Nov 2001 09:05:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1782E.F31E9120" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1782E.F31E9120 Content-Type: text/plain; charset="iso-8859-1" I am somewhat disappointed that there appears to have been almost no substantive discussion of JFK on the list. This may indicate that the protocol is secure, or it may indicate that nobody has been bothered to read it - which given the effort put into previous flames over the subject of keying would be somewhat disappointing. In the hope of engendering some debate on the matter I have been examining the algorithm, in particular comparing it to my XML Key Agreement Service Specification available in pdf form from http://www.xmltrustcenter.org/research/xkass/index.htm, the IETF draft format will be available sometime today or tommorow, I would recomend people read the pdf which has the benefit of subscripts and diagrams. The main differences between JFK and XKASS are: JFK requires 2 round trips JFK provides a certain level of DoS protection JFK allows the initiator to avoid disclosure of its identity to 3rd parties JFK requires the initiator to perform 2 signature verifications, 1 creation, 1 DH exponent the responder to perform 1 signature verification, 1 online creation, 1 signature that can be performed offline, one DH exponent. JFK does not assume that the initiator has knowledge of the public key of the responder at the start of the protocol. XKASS also supports an encryption mode which does not support PFS XKASS requires 1 round trip XKASS requires the initiator to perform 1 signature creation, 1 verification, 1 DH exponent the responder to perform 1 signature creation, 1 verification, 1 DH exponent XKASS assumes that the initiator has access to the public key of the responder at the start of the protocol. The main difference is in the design of the first round trip which has the purpose of defending against a limited set of DoS scenarios and to partially conceal the identity of the requestor. The question then is whether the scenarios in question are realistic and whether the defenses are effective in practice. On the question of concealling the identity of the initiator I am skeptical. As with the case of Chaum's digital cash it is likely that the identity of the participants can be deduced from the IP addresses alone so the cryptographic concealment of my identity at the message level does not excite me greatly. Even my AT&T roadrunner IP address that is issued on a 15 minute (!) lease has never changed in 6 months of service but wait for Friday when they turn off @home) The threat model for denail of service implicit in the paper is as follows: 1) The DoS attacker sends an IP packet with a correct source address. 2) The DoS attacker sends an IP packet with a fictitious source address. In case (1) the DoS attacker has the ability to respond to messages sent by the target but the target has the ability to respond to the attack by selectively blacklisting keying requests from the source. In Case (2) the DoS attacker cannot complete the second phase of the JFK exchange and thus cannot cause the responder to perform expensive CPU operations. This suggests that the DoS protection does serve a usefull purpose in the context of the IPSEC exchange. The question is whether the defense justifies the second round trip. If it was agreed that the issue of identity concealment was bogus it would be possible to create a combined JFK/XKASS type exchange that would execute in one round trip or two at the option of the responder. The responder would only require the second round trip in the case that it had actually detected a DoS attack. This particular implementation might have the problem of introducing more complexity to the protocol than is desirable in IPSEC for the sake of saving one round trip in a crypto-intensive protocol - although the complexity would not be very great. In the context of SOAP exchanges however the ability to save a round trip is likely to be considerably more important, particularly since it is more likely that the key exchange servers will be dedicated machines that do nothing but key exchange and have the cryptographic hardware to support it. If I have time before the IETF meeting I will try to apply the security methodology introduced in the XKASS paper to the JFK scheme. In particular I would like to be sure that the shared secret is in fact securely bound to all the context information of the exchange that might be of importance. In XKASS I took a possibly excessive approach, the established shared key has dependencies on practically every security parameter in the protocol. I remain keen on the idea of binding to the credentials of the parties however, this provides a pretty robust defense against credential substitution attacks in which a party has more than one certificate for the same key. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Steven M. Bellovin [mailto:smb@research.att.com] > Sent: Tuesday, November 20, 2001 9:26 AM > To: alexey.vyskubov@nokia.com > Cc: ipsec@lists.tislabs.com > Subject: Re: Just Fast Keying (JFK) draft > > > In message > <20011120124450.GA18085@terrapin.research.nokia.com>, Alexey Vyskubo > v writes: > >Hello, > > > >On Wed, Nov 14, 2001 at 11:52:10PM +0200, Angelos D. Keromytis wrote: > >> Without further ado, here's the link to the just-submitted I-D: > >> > >> > http://www.cs.columbia.edu/~angelos/Papers/draft-keromytis-jfk-00.txt > > > >Is it available still? > > I'll let Angelos figure out what happened to his copy; however, the > official version of the draft is now available from the IETF, > but using > a different name -- it's an official IPsec WG draft. Anyway, you can > retrieve it at > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-jfk-00.txt > > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com ------_=_NextPart_000_01C1782E.F31E9120 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1782E.F31E9120-- From owner-ipsec@lists.tislabs.com Wed Nov 28 09:49:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASHnZ803486; Wed, 28 Nov 2001 09:49:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08070 Wed, 28 Nov 2001 11:51:25 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Joel Snyder" , Cc: "Arne Ansper" , "Richard Guy Briggs" , "Steven M. Bellovin" , "Paul Hoffman / VPNC" References: <3C0501D3.314FE58A@opus1.com> Subject: Re: Gee, shared secrets suck (was: Re: SOI: identity protection and DOS) Date: Wed, 28 Nov 2001 12:01:06 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C17804.5C4347C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 17:00:26.0238 (UTC) FILETIME=[2D0781E0:01C1782E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C17804.5C4347C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: "Joel Snyder" To: Cc: "Arne Ansper" ; "Richard Guy Briggs" = ; "david chen" ; = "Steven M. Bellovin" ; "Paul Hoffman / VPNC" = Sent: Wednesday, November 28, 2001 10:25 AM Subject: Gee, shared secrets suck (was: Re: SOI: identity protection and = DOS) > > in addition to that: if you backup the configuration of your IPsec = enabled > > device and you are using shared secrets you must ensure that = nowbody has a > > chance to read the backup. if you are using public keys that are > > authenticated using preshared information you must only make sure = that the > > backup is tamperproof or perhaps even tamper evidence is = sufficient. >=20 > Why is that? Is it because you have somehow forgotten to also backup > the private key part of the public/private key pair? Sure, as long = as > you don't store the private key anywhere in your backups, then you = don't > have to worry about it being stolen/lost/compromised---whether it's = what I suppose most of people do not lost their wallet or forget their = password, or ...my dog chew the 'smart' card. Hence, no need to add/change the public/private keys. Or, it just the wary around in the real life? > we think of as a 'pre-shared secret' or 'uncertified private/public = key pair.' >=20 >=20 > But none of this matters. No one is arguing why authentication = methods > using public keys or digital certificates are better for = authentication > and security than pre-shared secrets. >=20 > The fact is, however, that end users of these products have > overwhelmingly voted with their implementations to use pre-shared > secrets for site-to-site authentication (and, if you consider SecurID = as > a 'preshared secret,' also for remote access). Creators of these > products have done an abyssmal job of enabling either = interoperability, > security, and manageability using anything longer than an easily > rattled-off string. >=20 > If you want to be sure that no one uses IKEv2 in real networks, then > force them to transfer a 1024-bit (or longer) value, or even the = 128-bit > hash of that value. >=20 > Everyone agrees that PSS have defects compared to other authentication > methods. You protocol geeks have to pull your heads out of the = packets > and look at how people have actually implemented the protocol = management > system and how end users have actually implemented VPNs. You must = have > something akin to the simplicity and shortness of PSS to ensure that > people will be able to at least prototype these systems in their > networks. >=20 > When they go the long haul and build huge VPNs---if they ever choose = to > do that---then other authentication methods, such as digital > certificates, will be welcome additions to the protocol. But every > large VPN installation starts out as a small VPN installation, and 99% > of small VPN installations start with pre-shared secrets. >=20 > jms >=20 > -- > Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 > +1 520 324 0494 x101 (voice) +1 520 324 0495 (FAX) > jms@Opus1.COM http://www.opus1.com/jms Opus One > Electronic mail is always the best way to contact me. >=20 >=20 ------=_NextPart_000_001D_01C17804.5C4347C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From: "Joel Snyder" <Joel.Snyder@Opus1.COM>
To: <ipsec@lists.tislabs.com>
Cc: "Arne Ansper" <arne@ats.cyber.ee>; = "Richard Guy=20 Briggs" <rgb@conscoop.ottawa.on.ca>; "david=20 chen" <ietf_davidchen@hotmail.com>;=20 "Steven M. Bellovin" <smb@research.att.com>;=20 "Paul Hoffman / VPNC" <paul.hoffman@vpnc.org>
Sent: Wednesday, November 28, 2001 = 10:25=20 AM
Subject: Gee, shared secrets suck (was: = Re: SOI:=20 identity protection and DOS)

>   > in addition to that: = if you backup=20 the configuration of your IPsec enabled
>  > device and = you are=20 using shared secrets you must ensure that nowbody has a
> =  >=20 chance to read the backup. if you are using public keys that are
> =  > authenticated using preshared information you must only make = sure=20 that the
>  > backup is tamperproof or perhaps even tamper = evidence is sufficient.
>
> Why is that?  Is it = because you=20 have somehow forgotten to also backup
> the private key part of = the=20 public/private key pair?   Sure, as long as
> you don't = store=20 the private key anywhere in your backups, then you don't
> have to = worry=20 about it being stolen/lost/compromised---whether it's what
I suppose most of = people do not lost=20 their wallet or forget their password, or
...my dog chew the = 'smart'=20 card.
Hence, no need to = add/change the=20 public/private keys.
Or, it just the wary = around in the=20 real life?

> we think of as a 'pre-shared = secret' or=20 'uncertified private/public key pair.'
>
>
> But = none of=20 this matters.  No one is arguing why authentication methods
> = using=20 public keys or digital certificates are better for = authentication
> and=20 security than pre-shared secrets.
>
> The fact is, however, = that=20 end users of these products have
> overwhelmingly voted with their = implementations to use pre-shared
> secrets for site-to-site=20 authentication (and, if you consider SecurID as
> a 'preshared = secret,'=20 also for remote access).  Creators of these
> products have = done an=20 abyssmal job of enabling either interoperability,
> security, and=20 manageability using anything longer than an easily
> rattled-off=20 string.
>
> If you want to be sure that no one uses IKEv2 = in real=20 networks, then
> force them to transfer a 1024-bit (or longer) = value, or=20 even the 128-bit
> hash of that value.
>
> Everyone = agrees=20 that PSS have defects compared to other authentication
> = methods. =20 You protocol geeks have to pull your heads out of the packets
> = and look=20 at how people have actually implemented the protocol management
> = system=20 and how end users have actually implemented VPNs.  You must = have
>=20 something akin to the simplicity and shortness of PSS to ensure = that
>=20 people will be able to at least prototype these systems in their
> = networks.
>
> When they go the long haul and build huge = VPNs---if=20 they ever choose to
> do that---then other authentication methods, = such as=20 digital
> certificates, will be welcome additions to the = protocol. =20 But every
> large VPN installation starts out as a small VPN = installation,=20 and 99%
> of small VPN installations start with pre-shared=20 secrets.
>
> jms
>
> --
> Joel M Snyder, = 1404=20 East Lind Road, Tucson, AZ, 85719
> +1 520 324 0494 x101=20 (voice)    +1 520 324 0495 (FAX)
> jms@Opus1.COM   =20 http://www.opus1.com/jms    Opus One
> Electronic mail is always = the best=20 way to contact me.
>
>
------=_NextPart_000_001D_01C17804.5C4347C0-- From owner-ipsec@lists.tislabs.com Wed Nov 28 09:55:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASHtg804319; Wed, 28 Nov 2001 09:55:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08127 Wed, 28 Nov 2001 12:04:57 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Richard Guy Briggs" Cc: "Steven M. Bellovin" , "Paul Hoffman / VPNC" , References: <20011128003942.7DA0E7B55@berkshire.research.att.com> <20011128050233.M29742@grendel.conscoop.ottawa.on.ca> Subject: Re: SOI: identity protection and DOS Date: Wed, 28 Nov 2001 12:14:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 17:13:58.0686 (UTC) FILETIME=[11493BE0:01C17830] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The 'private channel' is a vague term need to more elaborate. When we closelylook at these 'secure channel' it is a functional equivalent version of the IPSec with different media and so forth. (such as 'FACE to FACE' is based on the our eye-balls to verify the authentication when we trust the peer's face and the hands are our reliable primitive media to pass keys around, or the vocal exchange of password through the air (less secure)...) Immediately, we see the need to 'encrypt' (or functional equivalent) the channel for pre-shareed key passing around. Clearly, the RSA public keys do not need this. However, it will require peer mutual authentication/autherization (so is the pre-shared key). ----- Original Message ----- From: "Richard Guy Briggs" To: "david chen" Cc: "Steven M. Bellovin" ; "Paul Hoffman / VPNC" ; Sent: Wednesday, November 28, 2001 5:02 AM Subject: Re: SOI: identity protection and DOS > On Wed, Nov 28, 2001 at 01:46:07AM -0500, david chen wrote: > > I try to say that > > if self-signed certs depend on the out-of-band 'secured channel' that > > is used the same as pre-shared key for its key management, > > then why not just use pre-shared key? and save the trouble for > > public/private keys. > > > > Don't see the advantage of using 'self-cert' over 'pre-shared' in this case. > > For pre-shared keys, your secure channel *must* be private. For > self-cert, your secure channel to verify the key does not depend on > privacy for security. This is the whole point of PK. > > This seems fairly obvious to me. ...or am I missing something? > > > --- David > > > > > > ----- Original Message ----- > > From: "Steven M. Bellovin" > > To: "david chen" > > Cc: "Paul Hoffman / VPNC" ; > > Sent: Tuesday, November 27, 2001 7:39 PM > > Subject: Re: SOI: identity protection and DOS > > > > > > > In message , "david chen" writes: > > > >The very reason to certify a public key is that > > > > if the key is not 'public' enough than it is subject to MIM attack. > > > > > > > >Self-signed cert is subject to MIM attack unless... > > > >then why we need public/private key. > > > > > > You misunderstand. I'm suggesting that whatever secure channel could > > > be used to share a symmetric key could be used to share a public key. > > > If you can't trust that channel, you can't use pre-shared secrets, > > > either. > > > > > > --Steve Bellovin, http://www.research.att.com/~smb > > > Full text of "Firewalls" book now at http://www.wilyhacker.com > > > > > > > > > > > slainte mhath, RGB > > -- > Richard Guy Briggs -- ~\ Auto-Free Ottawa! Canada > -- \@ @ > No Internet Wiretapping! -- _\\/\%___\\/\% Vote! -- > _______GTVS6#790__(*)_______(*)(*)_______ > From owner-ipsec@lists.tislabs.com Wed Nov 28 10:26:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASIQH808101; Wed, 28 Nov 2001 10:26:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08220 Wed, 28 Nov 2001 12:36:31 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Henry Spencer" Cc: References: Subject: Re: SOI: identity protection and DOS Date: Wed, 28 Nov 2001 12:46:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 17:45:31.0952 (UTC) FILETIME=[79C2B300:01C17834] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Agree, However, the self-cert does not use PKInfrastructure to authenticate the public key in the cert; What is used to authenticate the public key is the same requirement as that of pre-shared key. The only difference is the self-cert (or any cert) does *not* (it is still argued in this thread for id protection) requiring an encrypted distribution channel. In the point of 'id protection', the self-cert (or any cert) requires some encryption but not public key in the cert. If 'id protection' is true, we see the self-serve still require some form of encrypted secure channel between peers. --- David ----- Original Message ----- From: "Henry Spencer" To: "david chen" Cc: Sent: Wednesday, November 28, 2001 8:20 AM Subject: Re: SOI: identity protection and DOS > On Wed, 28 Nov 2001, david chen wrote: > > I try to say that > > if self-signed certs depend on the out-of-band 'secured channel' that > > is used the same as pre-shared key for its key management, > > then why not just use pre-shared key? and save the trouble for > > public/private keys. > > Don't see the advantage of using 'self-cert' over 'pre-shared' in this case. > > At least three advantages: > > 1) Self-certs need not be kept secret to be usable. So the channel used > to verify them must be authenticated but need not be private, they need > not be stored in secure storage, etc. > > 2) No requirement to have a separate self-cert for each connection; one > per host suffices. > > 3) Uses much the same mechanism as PKI certificates, so there is no need > to have a different variant of the protocol (different analysis and > verification, different code, etc.) for them. > > Henry Spencer > henry@spsystems.net > > From owner-ipsec@lists.tislabs.com Wed Nov 28 10:38:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASIch808698; Wed, 28 Nov 2001 10:38:43 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA08256 Wed, 28 Nov 2001 12:46:34 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Steven M. Bellovin" , "Henry Spencer" Cc: References: <20011128140807.B75E27B55@berkshire.research.att.com> Subject: Re: SOI: identity protection and DOS Date: Wed, 28 Nov 2001 12:56:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 17:55:34.0662 (UTC) FILETIME=[E100F260:01C17835] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If PKInferstructure consumes lost of resources and still need 'self-cert' that rely on out-of-band distribution channel that is the same as that of the 'pre-shared' key, than take out cert and PKI will skim much more :-) --- David ----- Original Message ----- From: "Steven M. Bellovin" To: "Henry Spencer" Cc: "david chen" ; Sent: Wednesday, November 28, 2001 9:08 AM Subject: Re: SOI: identity protection and DOS > In message , Henry Spe > ncer writes: > >On Wed, 28 Nov 2001, david chen wrote: > >> I try to say that > >> if self-signed certs depend on the out-of-band 'secured channel' that > >> is used the same as pre-shared key for its key management, > >> then why not just use pre-shared key? and save the trouble for > >> public/private keys. > >> Don't see the advantage of using 'self-cert' over 'pre-shared' in this case. > > > >At least three advantages: > > > >1) Self-certs need not be kept secret to be usable. So the channel used > >to verify them must be authenticated but need not be private, they need > >not be stored in secure storage, etc. > > > >2) No requirement to have a separate self-cert for each connection; one > >per host suffices. > > > >3) Uses much the same mechanism as PKI certificates, so there is no need > >to have a different variant of the protocol (different analysis and > >verification, different code, etc.) for them. > > > 4) We don't need a key exchange protocol capable of coping with both > certificates and shared secrets. > > --Steve Bellovin, http://www.research.att.com/~smb > Full text of "Firewalls" book now at http://www.wilyhacker.com > > > From owner-ipsec@lists.tislabs.com Wed Nov 28 10:52:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASIqQ809677; Wed, 28 Nov 2001 10:52:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08305 Wed, 28 Nov 2001 13:02:24 -0500 (EST) Date: Wed, 28 Nov 2001 12:10:36 -0600 (CST) From: Tylor Allison X-X-Sender: To: Ricky Charlet cc: IPsec WG Subject: Re: On shared keys In-Reply-To: <3C03EB45.607B57D5@redcreek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 27 Nov 2001, Ricky Charlet wrote: > But, I would like to make the point (as others have) that a PSK > authentication system which can easily interact with popular back-end > authentication servers and will not tie the peers down to > pre-configured, known IP addresses would be a highly usable and popular > protocol as it would conviently address a great need. IMHO, such an > authentication method is in more demand than a PK authentication method > even though the PK authentication could scale larger. > > Next generation IKEers have all set about the goals of reducing > complexity and setup cost. But I would also request (and here starts a > new war) that the authors of IKE replacement protocols also consider > taking on the goals set forth in the ipsra WG > (draft-ietf-ipsra-reqmts-04.txt) but with the ability to 'change IKE'. > > I think that we should do a PSK authentication method because it would > be useful. I agree with you Ricky ... IMO, if we leave out PSK authentication from SOI, then we are not addressing the needs of the marketplace. First, as others have pointed out, for site-to-site VPNs, PSK seems to be the de-facto standard. Why? Because they are simple to setup/manage and they work (interoperable implementations). Can the new SOI standard be used to accommodate these users? To me there seems to be a conflict between requirements of SOI to scale, but yet be simple to use in single site-to-site setups. I'm not sure if a single SOI authentication mechanism can be found which will meet both of these requirements. And back to Ricky's point of merging the IPSRA work into SOI; modifying IKE to accommodate remote access requirements. This really isn't a new war, and its too frustrating for me to get into in depth. It's clear that there is a large market out there which has invested in PSK or token-based authentication. It's clear that whatever we come up with better take this into account. The real question is how to make it all work together. I'll contend that the easiest way to do this is to address the remote access requirements within IKE/SOI. Others say that separate protocols should be used as "building blocks" to achieve this. I can't help seeing these separate protocols as workarounds for deficiencies in the original design of IKE, and adding complexity to the overall solution we are presenting to our customers. If we're given the chance to start again (maybe that's really not true), why not attempt to reconcile with the new IPSRA requirements in SOI? I'd hate to see us make the same mistakes twice. ===================================================================== = Tylor Allison Secure Computing Corporation ========= = phone: 651.628.1554 e-mail: allison@securecomputing.com ========= ===================================================================== From owner-ipsec@lists.tislabs.com Wed Nov 28 11:11:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASJBs810337; Wed, 28 Nov 2001 11:11:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08358 Wed, 28 Nov 2001 13:20:14 -0500 (EST) Message-Id: <5.1.0.14.0.20011128111855.00a52040@pop.theworld.com> X-Sender: dpj@pop.theworld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 13:10:07 -0500 To: ipsec@lists.tislabs.com From: David Jablon Subject: Re: Gee, shared secrets suck (was: Re: SOI: identity protection and DOS) Cc: Joel Snyder In-Reply-To: <3C0501D3.314FE58A@opus1.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is a longstanding tradition in crypto protocol discussions to assume that pre-shared secrets, public/private keys, or compared hashes of these objects are all of high cryptographic strength and quality. Unfortunately, this sometimes means turning a blind eye to the fact that the people using these systems desperately want to input, output, and compare relatively small values. Some might even dare say it encourages deployment of systems that don't adequately handle human participants, whether by allowing people to choose insufficiently-random keys, or by relying on passive authentication steps (e.g. comparing hash values) that people conveniently ignore. In any case, don't be surprised if someone tells you that such problems are "out of scope" of this discussion. At 08:25 AM 11/28/01 -0700, Joel Snyder wrote: >[...] The fact is, however, that end users of these products have >overwhelmingly voted with their implementations to use pre-shared >secrets for site-to-site authentication (and, if you consider SecurID as >a 'preshared secret,' also for remote access). Creators of these >products have done an abyssmal job of enabling either interoperability, >security, and manageability using anything longer than an easily >rattled-off string. > >If you want to be sure that no one uses IKEv2 in real networks, then >force them to transfer a 1024-bit (or longer) value, or even the 128-bit >hash of that value. > >Everyone agrees that PSS have defects compared to other authentication >methods. You protocol geeks have to pull your heads out of the packets >and look at how people have actually implemented the protocol management >system and how end users have actually implemented VPNs. You must have >something akin to the simplicity and shortness of PSS to ensure that >people will be able to at least prototype these systems in their >networks. There are other protocols that can either amplify a short, simple PSS into a large PSS suitable for IKE, or that can use a short, simple PSS to securely retrieve public & private credentials. For examples, see the discussions in the SACRED working group. But I would think that "ease of use and deployment" should be the stated goal, rather than "ease of prototyping". >When they go the long haul and build huge VPNs---if they ever choose to >do that---then other authentication methods, such as digital >certificates, will be welcome additions to the protocol. But every >large VPN installation starts out as a small VPN installation, and 99% >of small VPN installations start with pre-shared secrets. > >jms > >-- >Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 >+1 520 324 0494 x101 (voice) +1 520 324 0495 (FAX) >jms@Opus1.COM http://www.opus1.com/jms Opus One >Electronic mail is always the best way to contact me. -- dpj From owner-ipsec@lists.tislabs.com Wed Nov 28 11:12:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASJCI810362; Wed, 28 Nov 2001 11:12:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08378 Wed, 28 Nov 2001 13:25:10 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: , "Derek Atkins" Cc: "'Paul Hoffman / VPNC'" , References: <002d01c177b5$dfcc2b10$1e72788a@andrewk3.ca.newbridge.com> Subject: Re: SOI: identity protection and DOS Date: Wed, 28 Nov 2001 13:34:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 18:34:11.0686 (UTC) FILETIME=[460EC060:01C1783B] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The 'pre-shared key' will need 500^2 for a full mesh of the 500 device if the 'pre-shared key' is symetric keys. However, the 'preshared public key' (self-cert is an example) is a different story. --- David ----- Original Message ----- From: "Derek Atkins" To: Cc: "'Paul Hoffman / VPNC'" ; Sent: Tuesday, November 27, 2001 11:36 PM Subject: Re: SOI: identity protection and DOS > "Andrew Krywaniuk" writes: > > > Actually, I forgot to mention the point that PK crypto only scales well when > > you have a CA. Sharing your self-signed cert with 500 people is no easier > > than sharing 500 different preshared keys. > > Actually, that's not true. If you have a full mesh of 500 people > sharing keys, then with shared secrets you have 500^2 == 250,000 > shared keys (assuming each pair share a unique key). OTOH with public > keys (preshared or otherwise) you only need a total of 500 keys in the > system. > > How the public keys are verified (either by CA validation or by > pre-sharing them and validating by hand) is irrelevant to this > particular discussion. > > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available > > From owner-ipsec@lists.tislabs.com Wed Nov 28 12:58:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASKwg816496; Wed, 28 Nov 2001 12:58:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08674 Wed, 28 Nov 2001 14:57:16 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15365.17335.676574.595714@mail.dev.equallogic.com> Date: Wed, 28 Nov 2001 15:06:15 -0500 (EST) From: Paul Koning To: ietf_davidchen@hotmail.com Cc: ipsec@lists.tislabs.com Subject: Re: SOI: identity protection and DOS References: X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "david" == david chen writes: david> Agree, However, the self-cert does not use PKInfrastructure to david> authenticate the public key in the cert; What is used to david> authenticate the public key is the same requirement as that of david> pre-shared key. The only difference is the self-cert (or any david> cert) does *not* (it is still argued in this thread for id david> protection) requiring an encrypted distribution channel. david> In the point of 'id protection', the self-cert (or any cert) david> requires some encryption but not public key in the cert. If david> 'id protection' is true, we see the self-serve still require david> some form of encrypted secure channel between peers. There are three cases to consider; for each, you can ask whether for that case there is a requirement for integrity, and a requirement for confidentiality. 1. Initial distribution of keying material (bootstrapping). 2. Storage of the keying material. 3. Use of the keying material for IKE or similar session-key establishment protocol. (Here, "confidentiality" can mean a mechanism that proves possession of a secret without disclosing it, not necessarily sending the secret itself in encrypted form.) For preshared secret, the answers are: 1. needs confidentiality and integrity 2. ditto 3. ditto For self-signed certs, the answers are: 1. need integrity 2. ditto 3. ditto. If you want "id protection", you also want confidentiality in this step (only). The point to remember is that the term indicates whether you disclose identity as part of session key establishment. For "regular" certs (signed by a CA) the answers for the cert are: 1. none 2. none 3. none but for the CA key they are the same as for self-signed certs, since CA keys are self-signed. Note that a lot of people are treating the channel through which they downloaded their current browser as a channel with integrity, since that's the channel that distributes the most commonly used SA keys (for https)... So id protection imposes a requirement on IKE or equivalent, not to disclose the identity from the cert, if a cert is used. But it doesn't change the fact that the earlier steps are easier with certs than with preshared keys, for example backups are not such a concern. paul From owner-ipsec@lists.tislabs.com Wed Nov 28 12:58:43 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASKwg816495; Wed, 28 Nov 2001 12:58:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08747 Wed, 28 Nov 2001 15:11:15 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Just Fast Keying (JFK) draft Date: 28 Nov 2001 20:19:47 GMT Organization: University of California, Berkeley Lines: 12 Distribution: isaac Message-ID: <9u3gt3$982$1@abraham.cs.berkeley.edu> References: <2F3EC696EAEED311BB2D009027C3F4F405869890@vhqpostal.verisign.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1006978787 9474 128.32.45.153 (28 Nov 2001 20:19:47 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 28 Nov 2001 20:19:47 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: >I am somewhat disappointed that there appears to have been almost no >substantive discussion of JFK on the list. This may indicate that the >protocol is secure, or it may indicate that nobody has been bothered to read >it - which given the effort put into previous flames over the subject of >keying would be somewhat disappointing. I took a look at JFK, and while I haven't had time to do any deep analysis, I think it looks great from what I've seen so far. IKE has always scared me with its complexity, so I am warmly supportive of simplification efforts in this area. Perhaps the lack of discussion means that noone has any complaints about JFK yet...? From owner-ipsec@lists.tislabs.com Wed Nov 28 13:16:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASLGj817336; Wed, 28 Nov 2001 13:16:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08818 Wed, 28 Nov 2001 15:27:30 -0500 (EST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15365.19111.840356.297735@thomasm-u1.cisco.com> Date: Wed, 28 Nov 2001 12:35:51 -0800 (PST) To: Black_David@emc.com Cc: ipsec@lists.tislabs.com, saag@mit.edu Subject: IP Storage and IPsec encapsulation In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14> References: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Let me see if I understand this: you don't want to preclude the use of security gateways. Fine, that's impossible to do anyway. You say that a host which doesn't implement some TBD profile of IPsec wouldn't be compliant with the draft. Fine, nothing that affects either intermediate security gateways or the choice of tunnel or transport mode. Since this is a host-host application layer protocol, that pretty much implies that you'd want to use transport mode, since you end up with the same IP src/dst addresses if you used tunnel mode, which sounds gratuitously redundant. Now, if you wanted colocate your IP storage box with a security gateway so that you can attach it to another security gateway -- possibly in a non-compliant arrangement -- you might want to have a tunnel. However, there is nothing to prevent such a box to still be compliant since you can always place IPsec protected packets (transport) into an IPsec tunnel. This doesn't require anything new as it's just a standard feature of RFC 2401. Thus -- and I'm sorry this is rather circuitous -- I really don't see what tunnel mode is buying over transport mode here, other than adding extra overhead and making things more confusing. Mike Black_David@emc.com writes: > Picking up a baseball bat and carefully drawing a bead on > the hornet's nest ... > > Over in the IP Storage (ips) WG, we're picking up a subset > of IPsec (primarily ESP and IKE) to provide security for > our protocols (TCP/IP encapsulations of SCSI and Fibre > Channel - iSCSI, FCIP, and iFCP). This approach is being > used in order to avoid putting out new protocol standards > that require things like DES and AH (comments in favor > of DES and/or AH should be sent to /dev/null ;-) ). > > >From a protocol specification standpoint, the IPS WG is > not prepared to require Integrated or Bump In The > Stack implementations of IPsec. In other words, the > WG does not want to foreclose the ability to take an IP > Storage protocol implementation without IPsec, hook it up > directly to a security gateway IPsec implementation and > obtain a result from the combination that complies with > the security requirements of the IPS protocol specification. > The protocol on the link between the IP Storage implementation > and its security gateway would NOT be compliant because > it would lack required security functionality (this latter > point was explained at length by the IESG in the London > plenary). > > Since IP Storage implementations could be based on host or > security gateway implementations of IPsec, the appropriate > thing to do in the IP Storage drafts appears to be to > REQUIRE tunnel mode as the encapsulation mode that > must be present for interoperability because it is the > common mode required by both classes of IPsec implementations. > OTOH, I've heard concerns that tunnel mode may not provide > a suitable bias towards end-to-end security - it's not that > difficult to terminate an IPsec tunnel someplace other than > the far end of the communication session running through it. > OTOOH, this concern strikes me as a policy issue - if some > node other than the far end can terminate the IPsec tunnel, > that node must have the keying material required to set up > the tunnel mode SA in the first place. In turn that > reflects a conscious security policy decision by the > administrator who configured that material into that > intermediate node and got exactly what s/he asked for. > This policy aspect is unavoidable, as the only way to > remove this option (tunnel mode to a gateway not at > the far end) from the admin's hands is to forbid > tunnel mode, which seems like a really bad idea. > > I'm looking for comments, advice, and insight on this > issue (which mode to REQUIRE) in the hope of resolving it > in Salt Lake City in a fashion that won't come back to > cause problems in IETF Last Call. For more information > on IPS Security, see draft-ietf-ips-security-06.txt (-05 > if -06 hasn't hit the servers yet). > > Thanks, > --David (IPS WG co-chair) > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- From owner-ipsec@lists.tislabs.com Wed Nov 28 13:29:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASLTS817666; Wed, 28 Nov 2001 13:29:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08843 Wed, 28 Nov 2001 15:41:31 -0500 (EST) Message-Id: <3.0.3.32.20011128125358.00ef4878@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 28 Nov 2001 12:53:58 -0800 To: , "'IPsec WG'" From: Alex Alten Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) In-Reply-To: <002c01c177b0$280218a0$1e72788a@andrewk3.ca.newbridge.com> References: <3.0.3.32.20011127092421.00f70cd0@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You have completely missed my point, and incorrectly lumped Visa and ATM security systems together. My point is that for over 20 years hundred's of millions of people have been using *DES* to get cash out of ATM machines. This is a very large scale system, the number of Internet hosts is an order of magnitude smaller. As far as I know there has never been a major compromise of this system, where lots of money was stolen from thousands of accounts. - Alex At 08:58 PM 11/27/2001 -0500, Andrew Krywaniuk wrote: >Your argument is silly. > >Visa and ATM transactions aren't secure. There are multiple cases where >large credit card databases have been compromised (often when an online >merchant's website is hacked). ... > > >> -----Original Message----- >> From: owner-ipsec@lists.tislabs.com >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten >> Sent: Tuesday, November 27, 2001 12:24 PM >> To: Hugo Krawczyk; IPsec WG >> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) >> >> >> At 01:34 AM 11/27/2001 +0200, Hugo Krawczyk wrote: >> >Everyone agrees that public key is the ONLY way to a scalable >> >Internet-wide protocol. No question about it. In particular, >> >any key-exchange protocol for IPsec MUST provide a PK-based exchange. >> > >> >> No. I STRONGLY disagree. I'll give a counter example. The banking >> ATM network uses DES keys. It has scaled, in practice, world wide. >> >> And BTW, it's security & trust model is excellent. Have you >> ever heard >> of a major compromise, say on the scale of 25,000 card #'s >> being stolen >> (like with Visa?). Certainly nobody distrusts it because it uses >> symmetric keys for authentication. In fact I'm certain YOU trust it >> at least a couple a times a month. :-) >> -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Wed Nov 28 13:50:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASLoG818662; Wed, 28 Nov 2001 13:50:17 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08909 Wed, 28 Nov 2001 15:58:49 -0500 (EST) Date: Wed, 28 Nov 2001 23:08:35 +0200 (IST) From: Hugo Krawczyk To: Charlie_Kaufman@iris.com cc: IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Charlie, find several responses below. > On Mon, 26 Nov 2001, Hugo Krawczyk wrote: > > > I'd like to address one fundamental issue > > related to the cryptographic soundness of the current design. > > Namely, the protocol does not achieve a strong cryptographic binding > > between the exchanged DH key and the party identities (an essential > security > > requirement put forth by the STS paper [DVW]). > > > > This can be indirectly achieved in IKEv2 via ESP if one MANDATES > > strong integrity in ESP (otherwise integrity is optional in ESP), > > but even then a truly sound key exchange protocol should not rely on > > external mechanisms to provide the most essential security properties > > (in contrast, using ESP for id protection is perectly reasonable). > > You're quite right; the spec should say that an integrity protection > algorithm is mandatory (and it sort of does in Appendix B, but it should > be more prominent and mentioned in the Security Considerations section). > As I already explained in quite a lengthy response to Dan on this same issue, I do NOT see these "clarifications" as a replacement for good, robust and provable protocol design. For all the reasons I mentioned in that note you have to include the prf under the signature, and use ESP only for identity encryption. > > > > > The solution to this problem is quite simple: put back the prf (or HASH) > > computation under the signature; a detailed specification can be found in > > > my recent SIGMA proposal [SIGMA]. > > > > This is certainly an alternative. As specified, the concatenation of the > first two messages is signed, which had a certain elegance and ease of > specification. But including additional fields under the hash would not > be difficult. I believe that for the protection of Phase 2, it is necessary > to make the integrity protection mandatory anyway. And I believe that if > the integrity protection in ESP turns out to be inadequate, having a fix > that works only for key management is of little value. How strongly do you > feel that it's important? ESP specifications are defined to secure raw data, not functioning as an authentication mechansim in a key exchange protocol. In your current specification you are not using ESP for the purpose it was specified and then you are not ensuring the security of the protocol and are taking unnecessary risks. The reason that I agree with ESP for identity protection is that in this case the required functionality is the same as defined for ESP: the raw data being protected is the identities (and signature). > > I prefer specifying the fields to be concatenated and signed rather than > the HMAC construction because of the complexity of specifying signing an I am all for simplicity and elegance, but not at the expense of essential security. And the design I propose is not less simple or elegant (and has a proof of security). It even saves communication and latency. > HMAC with DSS when DSS specifies that you must sign the SHA-1 of something. > But this is only a specification challenge, not an implementation > challenge, > so if there is a good security reason to use the HMAC construction, we > could do that too. This is a misunderstanding. The prf (or HMAC) under the signature does NOT replace the hashing done by the signature scheme. In the case of DSS the initiator will compute SIG_I as DSS_I(SHA-1(HASH_I). (Here DSS_I means DSS using I's private key). Same if you were using RSA under some hash-based standard format. If this is not clear please let me know (this may well deserve a clarification in the specifications). > > > Moreover, I would recommend integrating the SIGMA protocol to the current > > IKEv2 specification framework. This would have the effect of providing > full > > cryptographic security AND improving performance by reducing the number > of > > messages and the latency of SA activation. Given the IKEv2 draft, > specifying > > SIGMA in this context requires minimal work. > > I agree it would be straightforward. SIGMA proposes several protocols with > different properties. I am reluctant to have options, since they limit > interoperability. Is there one that you believe would be workable as *the* > protocol that has advantages over the current proposal? I, too, am RELUCTANT to have options. (This does not mean that no option is admissible -- e.g. you have optional stuff in your protocol too. The issue is to minimize options without sacrificing basic requirements and without penalizing the whole protocol because of functionality that is not always required: e.g., DH in phase 2 or Dos protection in phase 1.) My proposal is simple: replace your Phase 1 protocol with SIGMA-0 (sec 2.1 of my draft). In the cases that DoS protection is activated by the responder this becomes the protocol SIGMA depicted in sec 2.2 (In other words, SIGMA is just the expansion of SIGMA-0 to the case that DoS protection has been activated.) The only optional payload that I have and you dont is OIDi in the first message, something that can be very useful in helping the responder to make policy decisions immediately after receiving the first message from I. From my real-life experience with IPsec this is a USEFUL thing to have. The other difference is that I left unspecified the piggy-backing of IPsec "traffic selectors". Your solution using the TS payload fits perfectly well in SIGMA. As for pre-shared mode: I present that in my draft as a basis for discussion. However, discussing this is "out of scope" now since we are far from any consensus in the need to have such a mode. My intention with this description was to show how that pre-shared mode can be made "identical" to signature mode. Note that SIGMA-0 is EXACTLY P-SIGMA where on top of HASH you apply a signature. Anyway, this is subject for further discussion at some other time. > > > In addition, the SIGMA protocol would allow to have, in addition to the > > main PK-based protocol, a single mode that simultaneously supports > > Phase 2 functionality AND provides support for pre-shared keys. > > I agree that support for pre-shared keys would be a useful alternative, but > I think the mechanism for it requires more thought. IKEv1 main mode has > the problem (and SIGMA duplicates it to some degree) that identities are P-SIGMA does not have this problem. You can have a pointer to the key via OIDi, or you can decouple SKEYSEED_e from SKEYID. In the latter case you give up on active protection of I's identity and you pay with (at least) one extra message. > hidden on the wire but the protocol can't complete if the two ends don't > know the identities of the peers by some out of band mechanism (like based > on IP addresses). This fails in the common case of a mobile user connecting > in via IPsec to a corporate firewall. We decided not to muddy the debate > over > a single simple-every-implementation-interoperates-with-every-other > proposal for IKEv2, but if the other issues seem stable we could start > discussing this. agreed. > > > As I said in my note, I believe (and hope that you agree) that > > A TRULY SOUND KEY EXCHANGE PROTOCOL SHOULD NOT RELY ON > > EXTERNAL MECHANISMS TO PROVIDE ITS MOST ESSENTIAL SECURITY PROPERTIES > > > > In particular, the protocol MUST DEFINE ITS OWN AUTHENTICATION > MECHANISMS. > > I disagree. I believe protocols should not unnecessarily invent new > authentication mechanisms any more than they should invent new > cryptographic > algorithms. If there is an existing one that is suitable, it's better to I am not inventing new cryptographic algorithms. I am designing a secure protocol with EXISTING mechanisms. But I need to have full control of how these mechanisms are defined to be able to ensure the protocol's security. > use it than to do something a little different because it simplifies > analysis. It does not just simplify analysis. It enables it. Do not underestimate analysis for these protocols. They are immensely subtle! This approach also makes the protocol secure and robust to "environment changes". And the most important thing: you get these fundamental benefits with some performance improvement bonus too :) It is not my fault that the need for these mechansims is so un-intuitive. But I can show you in the analysis where each of these "little details" become essential. People seem to think: "what's the big deal of changing this or other detail" Well, these are the details that move you from being secure to insecure (or viceversa) > > But I agree that assumptions about those protocols must be made explicit, > so that changes in those protocols later a less likely to introduce > weaknesses. By specifying that we use the ESP Integrity Protection > mechanisms, we're assuming that ESP has no weak Integrity Protection > algorithms (which it currently doesn't, but could in the future). I'd > be willing to narrow the reference to specific ESP options (e.g. HMAC MD5 > and HMAC SHA1), or even a single one. That would prohibit later > introduction of weaker algorithms in the future, while still making > it syntactically obvious how we would migrate to a stronger one > (e.g. HMAC SHA2). As I said, we can agree to keep ESP for identity protection only (and then have specific algorithms as must-to-implement). > > ---------- > > But I believe all of what appears to be disagreement is largely > theoretical. > If IKEv2 includes some additional fields under the signature as you > propose, > the basic security properties are guaranteed even without depending on the > strength of the Integrity Protection algorithm, and that change seems both > easy and conservative. > > Will you be at the upcoming IETF? This conversation might be easier over > a whiteboard or a napkin. I am sure that all disgreements will disappear over a napkin. I will make an effort to come to the meeting but I am not sure yet. It is a long trip and in class time... In one way or another I hope we will keep making progress towards convergence of our proposals. Hugo > > --Charlie > > This footnote confirms that either (1) this email message has been swept by > Baltimore MIMEsweeper for Content Security threats, including computer > viruses, (2) this email message was sent by a virus that appends this > footnote, or (3) (most likely) the sender of this message is trying to > raise awareness of how foolish it would be to place any confidence in > footnotes like this. > > From owner-ipsec@lists.tislabs.com Wed Nov 28 13:51:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASLp0818692; Wed, 28 Nov 2001 13:51:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08895 Wed, 28 Nov 2001 15:56:58 -0500 (EST) Reply-To: From: "Andrew Krywaniuk" To: "'Paul Koning'" Cc: Subject: RE: SOI: identity protection and DOS Date: Wed, 28 Nov 2001 16:02:17 -0500 Message-ID: <003701c1784f$f73ec4c0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <15364.62563.431622.258994@mail.dev.equallogic.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This might sound like I am splitting hairs, but my point was to examine situations where you can get authentication but not secrecy. With a PGP web of trust, secrecy isn't a requirement, but it's easy enough to set up an SA once you already assume authentication, so PGP doesn't actually facilitate key exchange in a public environment any more than a preshared secret with a trusted intermediary would. The other point is that when you exchange a public key through a trusted intermediary, you are trusting them not to substitute a different public key so they can impersonate you. If you exchange a shared secret through a trusted intermediary, you are again trusting them not to remember the key so they can impersonate you. Maybe you could argue that in some practical situations the risks are smaller in the PK case, but the situations are still basically analagous. In cases where the web of trust extends more than 1 or 2 intermediaries, I would argue that the peer is not "meaningfully" authenticated. Andrew ------------------------------------------- There are no rules, only regulations. Luckily, history has shown that with time, hard work, and lots of love, anyone can be a technocrat. > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning > Sent: Wednesday, November 28, 2001 9:28 AM > To: andrew.krywaniuk@alcatel.com > Cc: ipsec@lists.tislabs.com > Subject: RE: SOI: identity protection and DOS > > > >>>>> "Andrew" == Andrew Krywaniuk > writes: > >> ... > >> Not true. You only need a authenticated transport for the public > >> key hashes: you don't have to keep them private. > > Andrew> I thought about this, but the distinction is mostly moot > Andrew> because there aren't that many circumstances where you can > Andrew> get authentication without secrecy. Maybe if you phoned the > Andrew> person and you thought the phone might be tapped but you > Andrew> could recognize their voice... Other popular key distribution > Andrew> techniques, such as e-mail, finger, websites, voice-mail from > Andrew> an administrator are unlikely to have that property where > Andrew> they are (meaningfully) authenticated but not secret. > > You left out a well established public key distribution scheme that > fits the description: the PGP Web of Trust. > > There is even a spec for the use of PGP keys with IKE. I remember at > least one implementation (don't know how many more there are). If > people are interested in a scheme that doesn't require the out of band > channel to have privacy (as shared secrets do), allows for self-signed > keys but isn't limited to them, and doesn't have the insistence on > centralization that the X.509 style CA schemes have, wider > implementation of that spec would be an option to consider. > > paul > > From owner-ipsec@lists.tislabs.com Wed Nov 28 14:00:17 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASM0G818942; Wed, 28 Nov 2001 14:00:16 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08949 Wed, 28 Nov 2001 16:11:05 -0500 (EST) Date: Wed, 28 Nov 2001 23:20:47 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: IPsec WG Subject: RE: SOI: identity protection and DOS In-Reply-To: <002d01c177b5$dfcc2b10$1e72788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Andrew, see below for a clarification... On Tue, 27 Nov 2001, Andrew Krywaniuk wrote: > > >(e) is only due to a flaw in IKEv1, and is unrelated to the > > use of preshared > > >keys in general. > > > > Yup. Some people think that identity protection is absolutely needed > > in every circumstance, but most people would agree that identity > > protection isn't worth preventing pre-shared secrets from working > > with mobile users. > > Well, my point was more that there isn't a conflict between preshared keys > and identity protection (of the passive variety). If the PSK & PKsig SKEYID > derivations in IKEv1 had been the same (as they could have been), this > argument would have never come up. > > As some may recall, Hugo originally argued that the PKsig authentication > method was inadequately secure because its strength was based solely on the > strength of the DH algorithm. The SKEYID for PSK was based on the DH value + > a secret value. Therefore, the decision to define the SKEYID this way was > merely a design tradeoff of identity protection for increased security. As > we noted in draft-improveike (and elsewhere), this tradeoff was not > necessary since an alternate SKEYID derivation could have given us both > properties. I never said that the sig mode of IKE was inadequately secure. I did mention the advantage of pre-shared mode against possible break of a DH group in the future. The fact that pre-shared mode is (much) better in this sense does not mean that people should consider the sig mode "inadequately secure". Moreover, I already said many times, and "implemented" this idea in my P-SIGMA proposal, that the problem of having to rely on the IP address for identifying the shared-key is easily solvable through an ID payload of type ID_KEY_ID (this was also the motivation to introduce this type several years ago). In P-SIGMA this is done via the OIDi field. Using this you get PFS and protection against active attacks for BOTH peers (which is impossible to achieve under any signature mode). Actually, even in IKE as it is now, where the OID mechanism is missing, one could have used the cookies in the header to identify shared keys in the keys database. Any idea, why people did not do that? Hugo From owner-ipsec@lists.tislabs.com Wed Nov 28 14:16:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMGv819443; Wed, 28 Nov 2001 14:16:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09005 Wed, 28 Nov 2001 16:28:57 -0500 (EST) Mime-Version: 1.0 X-Sender: karen.seo@po1.bbn.com Message-Id: Date: Wed, 28 Nov 2001 16:42:15 -0500 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Correction -- ESP draft Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, My apologies... already an inconsistency/error has been spotted. On Page 4, paragraph 4, first sentence: "An implementation MAY offer confidentiality independent of all other services...." On Page 5, paragraph 2, first bullet: "-- confidentiality-only (SHOULD be supported)" On Page 33, section 7, first bullet: "Confidentiality-only service -- now a SHOULD, not a MUST All 3 sentences should use "MAY". Karen From owner-ipsec@lists.tislabs.com Wed Nov 28 14:32:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMWM820825; Wed, 28 Nov 2001 14:32:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09054 Wed, 28 Nov 2001 16:47:35 -0500 (EST) X-Authentication-Warning: archmage.austin.ibm.com: mikecyr owned process doing -bs Date: Wed, 28 Nov 2001 15:57:03 -0600 (CST) From: Michael Cyr To: ipsec@lists.tislabs.com Subject: Re: CBC makes Implementations too Slow. In-Reply-To: <20011031005533.B51867C01@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > CBC mode requires > feedback, which makes it impossible to pipeline encryptions; you can't > encrypt plaintext block P[n+1] until you have the ciphertext from > encrypting P[n]. I know this discussion was a while ago, but I have a question related to the problem. First, let me say that I'm new to the list, and still somewhat new to IPsec in general, so I hope you'll forgive any ignorance on my part. Would it be a complete violation of the protocol to use random data for the IV data instead of a portion of the ciphertext of the previous block? I know this violates the spirit of cipher block _chaining_, but it would seem to address the concern that CBC was meant to fix, which is to ensure that if the same cleartext is encrypted twice, it doesn't produce the same ciphertext. Anyone have a definitive answer on this? Thanks, ---------------------------------------------------------------------- Michael Cyr | Phone 512-838-2943 |mikecyr@austin.ibm.com .. Email AIX IP Security | Tie-Line 678-2943 | Austin, TX | FAX 512-838-3509 |------------------------------- From owner-ipsec@lists.tislabs.com Wed Nov 28 14:46:52 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMkp821930; Wed, 28 Nov 2001 14:46:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA09089 Wed, 28 Nov 2001 16:58:15 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Paul Koning" Cc: References: <15365.17335.676574.595714@mail.dev.equallogic.com> Subject: Re: SOI: identity protection and DOS Date: Wed, 28 Nov 2001 17:07:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Nov 2001 22:07:16.0294 (UTC) FILETIME=[0A471E60:01C17859] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The out-of-band channel is used before bootstrap. I infer that both self-singed cert and pre-shared key using this channel with the same requirement. I am comparing the usings between public key in the self-cert and pre-shared key. You seems agree that the self-signed cert need encryption (well, except public key) for the sake of 'id protection'. Hence, you will agree that both using of these require authentication and encryption for the distribution (out-of-band) channel. Also, if you agree to encrypt cert for 'id protection' while transmission then the storage of cert will require encryption. Using self-signed CA cert is subject to MIM attack, it will have "chain reaction" (...) if the attack is successful. (assuming no out-of-band secured channel is used and the CA's public key expired from time to time,...) --- David PS. Regular cert or self-signed cert requires integrity check on the cert itself for tampering proof. ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Wednesday, November 28, 2001 3:06 PM Subject: Re: SOI: identity protection and DOS > >>>>> "david" == david chen writes: > > david> Agree, However, the self-cert does not use PKInfrastructure to > david> authenticate the public key in the cert; What is used to > david> authenticate the public key is the same requirement as that of > david> pre-shared key. The only difference is the self-cert (or any > david> cert) does *not* (it is still argued in this thread for id > david> protection) requiring an encrypted distribution channel. > > david> In the point of 'id protection', the self-cert (or any cert) > david> requires some encryption but not public key in the cert. If > david> 'id protection' is true, we see the self-serve still require > david> some form of encrypted secure channel between peers. > > There are three cases to consider; for each, you can ask whether for > that case there is a requirement for integrity, and a requirement for > confidentiality. > > 1. Initial distribution of keying material (bootstrapping). > 2. Storage of the keying material. > 3. Use of the keying material for IKE or similar session-key > establishment protocol. (Here, "confidentiality" can mean a > mechanism that proves possession of a secret without disclosing it, > not necessarily sending the secret itself in encrypted form.) > > For preshared secret, the answers are: > 1. needs confidentiality and integrity > 2. ditto > 3. ditto > > For self-signed certs, the answers are: > 1. need integrity > 2. ditto > 3. ditto. If you want "id protection", you also want confidentiality > in this step (only). The point to remember is that the term > indicates whether you disclose identity as part of session key > establishment. > > For "regular" certs (signed by a CA) the answers for the cert are: > 1. none > 2. none > 3. none > > but for the CA key they are the same as for self-signed certs, since > CA keys are self-signed. Note that a lot of people are treating the > channel through which they downloaded their current browser as a > channel with integrity, since that's the channel that distributes the > most commonly used SA keys (for https)... > > So id protection imposes a requirement on IKE or equivalent, not to > disclose the identity from the cert, if a cert is used. But it > doesn't change the fact that the earlier steps are easier with certs > than with preshared keys, for example backups are not such a concern. > > paul > > From owner-ipsec@lists.tislabs.com Wed Nov 28 14:51:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMpM822047; Wed, 28 Nov 2001 14:51:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09138 Wed, 28 Nov 2001 17:07:56 -0500 (EST) Message-ID: <29B5A21C13C8D51190F900805F65B4EC39EFC8@rndex50.ottawa.mitel.com> From: "Dilkie, Lee" To: "'Alex Alten'" , andrew.krywaniuk@alcatel.com, "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Wed, 28 Nov 2001 17:16:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex, With all due respect, I think the ATM network is a great example of why PSK (symmetric kind) security is an expensive and non scalable solution. First of all, the banks do take security seriously and implement the DES security for ATM's the way we suggest for PSK, but no-body does. Every ATM is loaded with x months of DES keys by two security guards. Each guard holds one half of a master key that is used to unlock the sets of keys to be loaded into the ATM. You call this a simple and scalable solution? I don't think so. It's expensive as heck, but fortunately for the banks, we get to foot the bill. And I disagree that internet hosts are an order of magnitude smaller in deployment. Consider the current situation with SSL-based web transactions. If you consider the number of endpoints, both servers and browsers, participating in a trusted, secured transaction I think you'll find that those numbers are vastly larger than the number of ATMs in the world. The certificate-based trust model is far easier and much more managable to deploy than any shared secret scheme. (I'd sure consider it expensive to have two burly security guards show up at my front door to load 4 months of DES keys into my browser) Personally, I'd like to see the end of all PSK in IPSec and go to a certificate-based PK trust model. Which is why I really liked the JFK proposal. To those that would like raw public keys, I say this. It's not hard to wrap a PK in a self-signed certificate and it buys you a lot. Moving up to a CA chain buys you that much more. And finally, as for the compromises of credit card numbers and the like... Not one of those was due to a flaw in security protocols. They were a result of implementation errors in applications. Unfortunately (or maybe fortunately) IPSec does not take on that responsibility. Lee Dilkie Mitel Networks 350 Legget Drive Kanata, ON, Canada K2K 2W7 Phone: 1-613-592-5660 "It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day." - Homer Simpson (from "The Simpsons") > -----Original Message----- > From: Alex Alten [mailto:Alten@home.com] > Sent: Wednesday, November 28, 2001 3:54 PM > To: andrew.krywaniuk@alcatel.com; 'IPsec WG' > Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > > > > You have completely missed my point, and incorrectly lumped > Visa and ATM > security systems together. > > My point is that for over 20 years hundred's of millions of > people have > been using *DES* to get cash out of ATM machines. This is a > very large > scale system, the number of Internet hosts is an order of > magnitude smaller. > As far as I know there has never been a major compromise of > this system, > where lots of money was stolen from thousands of accounts. > > - Alex > > > At 08:58 PM 11/27/2001 -0500, Andrew Krywaniuk wrote: > >Your argument is silly. > > > >Visa and ATM transactions aren't secure. There are multiple > cases where > >large credit card databases have been compromised (often > when an online > >merchant's website is hacked). > ... > > > > > >> -----Original Message----- > >> From: owner-ipsec@lists.tislabs.com > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > >> Sent: Tuesday, November 27, 2001 12:24 PM > >> To: Hugo Krawczyk; IPsec WG > >> Subject: Re: On shared keys (was RE: SOI: identity > protection and DOS) > >> > >> > >> At 01:34 AM 11/27/2001 +0200, Hugo Krawczyk wrote: > >> >Everyone agrees that public key is the ONLY way to a scalable > >> >Internet-wide protocol. No question about it. In particular, > >> >any key-exchange protocol for IPsec MUST provide a > PK-based exchange. > >> > > >> > >> No. I STRONGLY disagree. I'll give a counter example. > The banking > >> ATM network uses DES keys. It has scaled, in practice, world wide. > >> > >> And BTW, it's security & trust model is excellent. Have you > >> ever heard > >> of a major compromise, say on the scale of 25,000 card #'s > >> being stolen > >> (like with Visa?). Certainly nobody distrusts it because it uses > >> symmetric keys for authentication. In fact I'm certain > YOU trust it > >> at least a couple a times a month. :-) > >> > > -- > > Alex Alten > Alten@Home.Com > From owner-ipsec@lists.tislabs.com Wed Nov 28 14:53:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMrq822097; Wed, 28 Nov 2001 14:53:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09095 Wed, 28 Nov 2001 17:02:09 -0500 (EST) To: Alex Alten Cc: , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <3.0.3.32.20011127092421.00f70cd0@mail> <3.0.3.32.20011128125358.00ef4878@mail> From: Derek Atkins Date: 28 Nov 2001 17:11:28 -0500 In-Reply-To: Alex Alten's message of "Wed, 28 Nov 2001 12:53:58 -0800" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten writes: > You have completely missed my point, and incorrectly lumped Visa and ATM > security systems together. > > My point is that for over 20 years hundred's of millions of people have > been using *DES* to get cash out of ATM machines. This is a very large > scale system, the number of Internet hosts is an order of magnitude smaller. > As far as I know there has never been a major compromise of this system, > where lots of money was stolen from thousands of accounts. Unfortunately this last statement is not (completely) true. There have been compromises of the system. The reason there hasn't been much money stolen is that there are out-of-band checks and balances and fraud detection to keep that from happening. The fact that more fraud doesn't happen is due to the out-of-band additional check in place at banking institutions, rather than the fact that 'DES is ok'. The whole ATM system is flawed in a few major ways; using 1-DES is only the tip of the iceburg. Global Static keys is the main issue. > - Alex -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 28 14:55:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMtW822152; Wed, 28 Nov 2001 14:55:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09124 Wed, 28 Nov 2001 17:07:12 -0500 (EST) To: Hugo Krawczyk Cc: Charlie_Kaufman@iris.com, IPsec WG Subject: Re: IKEv2 and SIGMA References: From: Derek Atkins Date: 28 Nov 2001 17:16:25 -0500 In-Reply-To: Hugo Krawczyk's message of "Wed, 28 Nov 2001 23:08:35 +0200 (IST)" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > ESP specifications are defined to secure raw data, not functioning > as an authentication mechansim in a key exchange protocol. Actually, Hugo, if you step back and view "a key exchange protocol" as "raw data", then ESP works perfectly well. Keep in mind that this is not ESP in the standard sense. Rather, this is using the ESP packet format with the key-exchange-protocol Security Association. If you believe that the ESP packet format and transforms are secure, then why not use them in other places, too? This discussion is extremely similar to the one we had in KINK in London regarding the re-use of IKE Phase-II Quick-Mode to negotiate the IPsec SA parameters. The point is to reuse the data formats and as much of the state machine as possible, but using it in a different context. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 28 15:02:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASN2u822304; Wed, 28 Nov 2001 15:02:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09117 Wed, 28 Nov 2001 17:05:58 -0500 (EST) Message-ID: <3C0561F4.6070508@kolumbus.fi> Date: Thu, 29 Nov 2001 00:15:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Tylor Allison Cc: Ricky Charlet , IPsec WG Subject: Re: On shared keys References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tylor wrote: > And back to Ricky's point of merging the IPSRA work into SOI; modifying IKE > to accommodate remote access requirements. This really isn't a new war, and > its too frustrating for me to get into in depth. It's clear that there is > a large market out there which has invested in PSK or token-based > authentication. It's clear that whatever we come up with better take this > into account. The real question is how to make it all work together. > I'll contend that the easiest way to do this is to address the remote > access requirements within IKE/SOI. Others say that separate protocols should > be used as "building blocks" to achieve this. I can't help seeing these > separate protocols as workarounds for deficiencies in the original design > of IKE, and adding complexity to the overall solution we are presenting to > our customers. If we're given the chance to start again (maybe that's > really not true), why not attempt to reconcile with the new IPSRA > requirements in SOI? I'd hate to see us make the same mistakes twice. The separation of essential functions to "building blocks" maybe useful in terms of making it easier to prove security. But it also adds RTTs for low-bandiwdth high-delay users, making all this not so good for folks accessing through cellular networks. Yes you may only have to do it now and then, but still. Seems like awful lot of complexity, if real application is in any case through some sort of shared secrets. Jari From owner-ipsec@lists.tislabs.com Wed Nov 28 15:23:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASNNw823050; Wed, 28 Nov 2001 15:23:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09289 Wed, 28 Nov 2001 17:36:20 -0500 (EST) Message-ID: <3C0568EB.855FE279@mitel.com> Date: Wed, 28 Nov 2001 17:44:59 -0500 From: Dave Perks Organization: Mitel Networks X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Re: CBC makes Implementations too Slow. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Michael Cyr wrote: > > On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > > > CBC mode requires > > feedback, which makes it impossible to pipeline encryptions; you can't > > encrypt plaintext block P[n+1] until you have the ciphertext from > > encrypting P[n]. > > I know this discussion was a while ago, but I have a question related to > the problem. First, let me say that I'm new to the list, and still > somewhat new to IPsec in general, so I hope you'll forgive any ignorance > on my part. > > Would it be a complete violation of the protocol to use random data for > the IV data instead of a portion of the ciphertext of the previous > block? I know this violates the spirit of cipher block _chaining_, but > it would seem to address the concern that CBC was meant to fix, which is > to ensure that if the same cleartext is encrypted twice, it doesn't > produce the same ciphertext. Anyone have a definitive answer on this? Yes. There can be many cipher blocks in a single packet. The IV is xored with the first plaintext block in the packet and encrypted to produce the first cipher block, which in turn is xored with the second plaintext block and encrypted to produce second ciphertext block, and so on. The packet's IV can be random or can be carried over from a previous packet. Using a random IV for each cipher block instead of each packet would double the size of the packet. There is nothing to stop you from encrypting multiple packets, each with its own IV, simultaneously. This does nothing to address the latency that a single packet experiences, which is (roughly) the latency to encrypt a single block times the number of blocks in the packet. From owner-ipsec@lists.tislabs.com Wed Nov 28 15:33:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASNXJ823243; Wed, 28 Nov 2001 15:33:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09381 Wed, 28 Nov 2001 17:49:01 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14> To: mat@cisco.com Cc: ipsec@lists.tislabs.com, saag@mit.edu Subject: RE: IP Storage and IPsec encapsulation Date: Wed, 28 Nov 2001 17:47:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Since this is a host-host application layer > protocol, that pretty much implies that you'd want > to use transport mode, since you end up with the > same IP src/dst addresses if you used tunnel mode, > which sounds gratuitously redundant. The configuration of interest is: |--------------------------| |---------------| | IP Storage without IPsec |----| IPsec gateway |--> |--------------------------| |---------------| Where the link between the two boxes is not attached to anything else. The only IPsec implementation on this end of the connection is in the gateway, and the only link in the above diagram that complies with the protocol requirements is the link on the right hand side of the gateway. The gateway does not implement transport mode, hence the interest in tunnel mode. > Thus -- and I'm sorry this is rather circuitous -- > I really don't see what tunnel mode is buying over > transport mode here, other than adding extra > overhead and making things more confusing. It's buying the above implementation approach in which IPsec does not have to be implemented on the IP Storage box in the diagram. If IPsec were implemented on the IP Storage box, then one wouldn't need the gateway for protocol compliance (although it might be present for other reasons), and if both ends of the connection implemented IPsec in that fashion, then transport mode would be the more efficient choice for the end-to-end SA (but that's a policy decision, and negotiable via IKE). Please note the two "if"s in the previous sentence; the IPS WG is currently reluctant to impose them as requirements on all implementations. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, November 28, 2001 3:36 PM > To: Black_David@emc.com > Cc: ipsec@lists.tislabs.com; saag@mit.edu > Subject: IP Storage and IPsec encapsulation > > > > Let me see if I understand this: you don't want to > preclude the use of security gateways. Fine, > that's impossible to do anyway. You say that a > host which doesn't implement some TBD profile of > IPsec wouldn't be compliant with the draft. Fine, > nothing that affects either intermediate security > gateways or the choice of tunnel or transport > mode. Since this is a host-host application layer > protocol, that pretty much implies that you'd want > to use transport mode, since you end up with the > same IP src/dst addresses if you used tunnel mode, > which sounds gratuitously redundant. > > Now, if you wanted colocate your IP storage box > with a security gateway so that you can attach it > to another security gateway -- possibly in a > non-compliant arrangement -- you might want to > have a tunnel. However, there is nothing to > prevent such a box to still be compliant since you > can always place IPsec protected packets > (transport) into an IPsec tunnel. This doesn't > require anything new as it's just a standard > feature of RFC 2401. > > Thus -- and I'm sorry this is rather circuitous -- > I really don't see what tunnel mode is buying over > transport mode here, other than adding extra > overhead and making things more confusing. > > Mike > > Black_David@emc.com writes: > > Picking up a baseball bat and carefully drawing a bead on > > the hornet's nest ... > > > > Over in the IP Storage (ips) WG, we're picking up a subset > > of IPsec (primarily ESP and IKE) to provide security for > > our protocols (TCP/IP encapsulations of SCSI and Fibre > > Channel - iSCSI, FCIP, and iFCP). This approach is being > > used in order to avoid putting out new protocol standards > > that require things like DES and AH (comments in favor > > of DES and/or AH should be sent to /dev/null ;-) ). > > > > >From a protocol specification standpoint, the IPS WG is > > not prepared to require Integrated or Bump In The > > Stack implementations of IPsec. In other words, the > > WG does not want to foreclose the ability to take an IP > > Storage protocol implementation without IPsec, hook it up > > directly to a security gateway IPsec implementation and > > obtain a result from the combination that complies with > > the security requirements of the IPS protocol specification. > > The protocol on the link between the IP Storage implementation > > and its security gateway would NOT be compliant because > > it would lack required security functionality (this latter > > point was explained at length by the IESG in the London > > plenary). > > > > Since IP Storage implementations could be based on host or > > security gateway implementations of IPsec, the appropriate > > thing to do in the IP Storage drafts appears to be to > > REQUIRE tunnel mode as the encapsulation mode that > > must be present for interoperability because it is the > > common mode required by both classes of IPsec implementations. > > OTOH, I've heard concerns that tunnel mode may not provide > > a suitable bias towards end-to-end security - it's not that > > difficult to terminate an IPsec tunnel someplace other than > > the far end of the communication session running through it. > > OTOOH, this concern strikes me as a policy issue - if some > > node other than the far end can terminate the IPsec tunnel, > > that node must have the keying material required to set up > > the tunnel mode SA in the first place. In turn that > > reflects a conscious security policy decision by the > > administrator who configured that material into that > > intermediate node and got exactly what s/he asked for. > > This policy aspect is unavoidable, as the only way to > > remove this option (tunnel mode to a gateway not at > > the far end) from the admin's hands is to forbid > > tunnel mode, which seems like a really bad idea. > > > > I'm looking for comments, advice, and insight on this > > issue (which mode to REQUIRE) in the hope of resolving it > > in Salt Lake City in a fashion that won't come back to > > cause problems in IETF Last Call. For more information > > on IPS Security, see draft-ietf-ips-security-06.txt (-05 > > if -06 hasn't hit the servers yet). > > > > Thanks, > > --David (IPS WG co-chair) > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > From owner-ipsec@lists.tislabs.com Wed Nov 28 15:50:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASNok824453; Wed, 28 Nov 2001 15:50:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09445 Wed, 28 Nov 2001 18:08:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Alex Alten" Cc: , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <3.0.3.32.20011127092421.00f70cd0@mail> <3.0.3.32.20011128125358.00ef4878@mail> From: "Derek Atkins" Date: 28 Nov 2001 17:11:28 -0500 In-Reply-To: Alex Alten's message of "Wed, 28 Nov 2001 12:53:58 -0800" Message-ID: Lines: 32 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 28 Nov 2001 23:17:53.0421 (UTC) FILETIME=[E7CD63D0:01C17862] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten writes: > You have completely missed my point, and incorrectly lumped Visa and ATM > security systems together. > > My point is that for over 20 years hundred's of millions of people have > been using *DES* to get cash out of ATM machines. This is a very large > scale system, the number of Internet hosts is an order of magnitude smaller. > As far as I know there has never been a major compromise of this system, > where lots of money was stolen from thousands of accounts. Unfortunately this last statement is not (completely) true. There have been compromises of the system. The reason there hasn't been much money stolen is that there are out-of-band checks and balances and fraud detection to keep that from happening. The fact that more fraud doesn't happen is due to the out-of-band additional check in place at banking institutions, rather than the fact that 'DES is ok'. The whole ATM system is flawed in a few major ways; using 1-DES is only the tip of the iceburg. Global Static keys is the main issue. > - Alex -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 28 15:52:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASNqq824506; Wed, 28 Nov 2001 15:52:52 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09455 Wed, 28 Nov 2001 18:10:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Hugo Krawczyk" Cc: , "IPsec WG" Subject: Re: IKEv2 and SIGMA References: From: "Derek Atkins" Date: 28 Nov 2001 17:16:25 -0500 In-Reply-To: Hugo Krawczyk's message of "Wed, 28 Nov 2001 23:08:35 +0200 (IST)" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 28 Nov 2001 23:19:46.0921 (UTC) FILETIME=[2B741D90:01C17863] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk writes: > ESP specifications are defined to secure raw data, not functioning > as an authentication mechansim in a key exchange protocol. Actually, Hugo, if you step back and view "a key exchange protocol" as "raw data", then ESP works perfectly well. Keep in mind that this is not ESP in the standard sense. Rather, this is using the ESP packet format with the key-exchange-protocol Security Association. If you believe that the ESP packet format and transforms are secure, then why not use them in other places, too? This discussion is extremely similar to the one we had in KINK in London regarding the re-use of IKE Phase-II Quick-Mode to negotiate the IPsec SA parameters. The point is to reuse the data formats and as much of the state machine as possible, but using it in a different context. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 28 15:56:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASNuk824954; Wed, 28 Nov 2001 15:56:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09492 Wed, 28 Nov 2001 18:17:20 -0500 (EST) Message-Id: <3.0.3.32.20011128152948.00ef4878@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 28 Nov 2001 15:29:48 -0800 To: Derek Atkins From: Alex Alten Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cc: , "'IPsec WG'" In-Reply-To: References: <3.0.3.32.20011127092421.00f70cd0@mail> <3.0.3.32.20011128125358.00ef4878@mail> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:11 PM 11/28/2001 -0500, Derek Atkins wrote: >Alex Alten writes: > >> You have completely missed my point, and incorrectly lumped Visa and ATM >> security systems together. >> >> My point is that for over 20 years hundred's of millions of people have >> been using *DES* to get cash out of ATM machines. This is a very large >> scale system, the number of Internet hosts is an order of magnitude smaller. >> As far as I know there has never been a major compromise of this system, >> where lots of money was stolen from thousands of accounts. > >Unfortunately this last statement is not (completely) true. There >have been compromises of the system. The reason there hasn't been >much money stolen is that there are out-of-band checks and balances >and fraud detection to keep that from happening. > >The fact that more fraud doesn't happen is due to the out-of-band >additional check in place at banking institutions, rather than the >fact that 'DES is ok'. > >The whole ATM system is flawed in a few major ways; using 1-DES is >only the tip of the iceburg. Global Static keys is the main issue. > Given that this is a 25 year old design I think that using 1-DES as a problem is not a fair statement. I personally know one of the original designers of the ATM system and have spoken with him about various aspects of the security design. Your statement of Global Static keys is the first time I've ever heard about it. Maybe you could explain what you mean by these? In particular does this so-called "flaw" allow anyone, either inside or outside the system, to get thousands of PIN and account number pairs? This is what I mean by a major compromise. BTW, I'm sure VISA has tons of additional checks at various member banks, etc., and yet that didn't stop some Russian hackers from getting tens of thousands of card numbers from across the Internet. That is a major compromise of the system and whomever designed their security should be ashamed of it. - Alex -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Wed Nov 28 16:24:41 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT0Of826609; Wed, 28 Nov 2001 16:24:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09553 Wed, 28 Nov 2001 18:41:19 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 28 Nov 2001 18:46:50 -0500 To: Michael Cyr From: Stephen Kent Subject: Re: CBC makes Implementations too Slow. Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:57 PM -0600 11/28/01, Michael Cyr wrote: >On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > >> CBC mode requires >> feedback, which makes it impossible to pipeline encryptions; you can't >> encrypt plaintext block P[n+1] until you have the ciphertext from >> encrypting P[n]. > >I know this discussion was a while ago, but I have a question related to >the problem. First, let me say that I'm new to the list, and still >somewhat new to IPsec in general, so I hope you'll forgive any ignorance >on my part. > >Would it be a complete violation of the protocol to use random data for >the IV data instead of a portion of the ciphertext of the previous >block? I know this violates the spirit of cipher block _chaining_, but >it would seem to address the concern that CBC was meant to fix, which is >to ensure that if the same cleartext is encrypted twice, it doesn't >produce the same ciphertext. Anyone have a definitive answer on this? > >Thanks, > >---------------------------------------------------------------------- >Michael Cyr | Phone 512-838-2943 |mikecyr@austin.ibm.com .. Email >AIX IP Security | Tie-Line 678-2943 | >Austin, TX | FAX 512-838-3509 |------------------------------- Michael, It's OK to generate a new random or pseudo-random IV for each packet. The suggestion of using a residual ciphertext from a previously encrypted packet should not be taken as a requirement, and might even be viewed as less than ideal from a strict crypto protocol perspective. If you use a separate IV for each block, that would be a different mode entirely, and, unless the IV sequence is deterministic, the overhead would be unacceptable. I suggest you stick to standard modes. Steve From owner-ipsec@lists.tislabs.com Wed Nov 28 16:26:54 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT0Qs826648; Wed, 28 Nov 2001 16:26:54 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09568 Wed, 28 Nov 2001 18:45:34 -0500 (EST) From: "Joseph D. Harwood" To: "Michael Cyr" , Subject: RE: CBC makes Implementations too Slow. Date: Wed, 28 Nov 2001 15:11:22 -0800 Message-ID: <000301c17861$ff0eb7c0$c7d0fea9@vesta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You would have to send all of the random data you're using as IV along with the encrypted packet (amount of data transmitted = 2x amount of packet data). The advantage of using the previous encrypted block as IV is that only the IV for the first block has to be sent (amount of data transmitted = amount of packet data + 1 block). Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Michael Cyr > Sent: Wednesday, November 28, 2001 1:57 PM > To: ipsec@lists.tislabs.com > Subject: Re: CBC makes Implementations too Slow. > > > On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > > > CBC mode requires > > feedback, which makes it impossible to pipeline encryptions; you can't > > encrypt plaintext block P[n+1] until you have the ciphertext from > > encrypting P[n]. > > I know this discussion was a while ago, but I have a question related to > the problem. First, let me say that I'm new to the list, and still > somewhat new to IPsec in general, so I hope you'll forgive any ignorance > on my part. > > Would it be a complete violation of the protocol to use random data for > the IV data instead of a portion of the ciphertext of the previous > block? I know this violates the spirit of cipher block _chaining_, but > it would seem to address the concern that CBC was meant to fix, which is > to ensure that if the same cleartext is encrypted twice, it doesn't > produce the same ciphertext. Anyone have a definitive answer on this? > > Thanks, > > ---------------------------------------------------------------------- > Michael Cyr | Phone 512-838-2943 |mikecyr@austin.ibm.com .. Email > AIX IP Security | Tie-Line 678-2943 | > Austin, TX | FAX 512-838-3509 |------------------------------- > From owner-ipsec@lists.tislabs.com Wed Nov 28 16:34:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT0Yt826841; Wed, 28 Nov 2001 16:34:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09621 Wed, 28 Nov 2001 18:54:05 -0500 (EST) X-Authentication-Warning: archmage.austin.ibm.com: mikecyr owned process doing -bs Date: Wed, 28 Nov 2001 18:03:35 -0600 (CST) From: Michael Cyr To: ipsec@lists.tislabs.com Subject: Re: CBC makes Implementations too Slow. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 28 Nov 2001, Stephen Kent wrote: > It's OK to generate a new random or pseudo-random IV for each packet. > The suggestion of using a residual ciphertext from a previously > encrypted packet should not be taken as a requirement, and might even > be viewed as less than ideal from a strict crypto protocol > perspective. If you use a separate IV for each block, that would be a > different mode entirely, and, unless the IV sequence is > deterministic, the overhead would be unacceptable. I suggest you > stick to standard modes. This is exactly what I need, thank you. My problem was that I was confusing block vs. packet. What I really wanted to know was whether it was required that the IV data that was specified in the packet header (and used for the first block in the packet) come from the ciphertext of the previous packet. I understand now that it is not. ---------------------------------------------------------------------- Michael Cyr | Phone 512-838-2943 |mikecyr@austin.ibm.com .. Email AIX IP Security | Tie-Line 678-2943 | Austin, TX | FAX 512-838-3509 |------------------------------- From owner-ipsec@lists.tislabs.com Wed Nov 28 17:43:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT1h5828354; Wed, 28 Nov 2001 17:43:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09808 Wed, 28 Nov 2001 19:51:04 -0500 (EST) From: daw@mozart.cs.berkeley.edu Date: Wed, 28 Nov 2001 17:02:11 -0800 (PST) Message-Id: <200111290102.fAT125g74647@mail6.ambernetworks.com> X-KINE-FWD: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From owner-ipsec@lists.tislabs.com Wed Nov 28 14:37:11 2001 Return-Path: Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail6.ambernetworks.com (8.11.3/8.11.3) with ESMTP id fASMb2g71892 for ; Wed, 28 Nov 2001 14:37:10 -0800 (PST) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA08747 Wed, 28 Nov 2001 15:11:15 -0500 (EST) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Just Fast Keying (JFK) draft Date: 28 Nov 2001 20:19:47 GMT Organization: University of California, Berkeley Lines: 12 Distribution: isaac Message-ID: <9u3gt3$982$1@abraham.cs.berkeley.edu> References: <2F3EC696EAEED311BB2D009027C3F4F405869890@vhqpostal.verisign.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1006978787 9474 128.32.45.153 (28 Nov 2001 20:19:47 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 28 Nov 2001 20:19:47 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hallam-Baker, Phillip wrote: >I am somewhat disappointed that there appears to have been almost no >substantive discussion of JFK on the list. This may indicate that the >protocol is secure, or it may indicate that nobody has been bothered to read >it - which given the effort put into previous flames over the subject of >keying would be somewhat disappointing. I took a look at JFK, and while I haven't had time to do any deep analysis, I think it looks great from what I've seen so far. IKE has always scared me with its complexity, so I am warmly supportive of simplification efforts in this area. Perhaps the lack of discussion means that noone has any complaints about JFK yet...? From owner-ipsec@lists.tislabs.com Wed Nov 28 17:43:10 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT1h9828366; Wed, 28 Nov 2001 17:43:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09802 Wed, 28 Nov 2001 19:50:15 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Dilkie, Lee" , "'Alex Alten'" , , "'IPsec WG'" References: <29B5A21C13C8D51190F900805F65B4EC39EFC8@rndex50.ottawa.mitel.com> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Wed, 28 Nov 2001 19:59:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 29 Nov 2001 00:59:17.0538 (UTC) FILETIME=[1237F820:01C17871] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Certificate is great except no one sign the CA's public key. (yes, keeping moving along the 'chain' and reach top) Noone certify the root-CA's public key in a realm. Also, this CA's cert is very valuable for attacker. The self-cert is just a showdow of pre-shared key. (still proving) If the certificate chain ultimately depends on the same mechanism as pre-shared key then just using pre-shared key is sufficient. A raw public key with ID without certificate chain and CA is more simple and efficient. (and no complication of CRL) Only way out of using CA and cert-chain is that Uinted Nation post its public key on major TV network on earth with 24/7 broadcasting and all certifcation of public keys are ultimately based on it. (It will be secure but no civil privacy :-) As far as PGP, it is fuzzy about how secure it is. More like each personal have a relative degree of mutual trust. However, the degree of trust of a group (of people) to a certain person is hard to quantify. (arithmatic average of "trust" in the group, or geometric average of that...) I am lost. :-) --- David ----- Original Message ----- From: "Dilkie, Lee" To: "'Alex Alten'" ; ; "'IPsec WG'" Sent: Wednesday, November 28, 2001 5:16 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > Alex, > > With all due respect, I think the ATM network is a great example of why PSK (symmetric kind) security is an expensive and non scalable solution. > > First of all, the banks do take security seriously and implement the DES security for ATM's the way we suggest for PSK, but no-body does. > > Every ATM is loaded with x months of DES keys by two security guards. Each guard holds one half of a master key that is used to unlock the sets of keys to be loaded into the ATM. You call this a simple and scalable solution? I don't think so. It's expensive as heck, but fortunately for the banks, we get to foot the bill. > > And I disagree that internet hosts are an order of magnitude smaller in deployment. > > Consider the current situation with SSL-based web transactions. If you consider the number of endpoints, both servers and browsers, participating in a trusted, secured transaction I think you'll find that those numbers are vastly larger than the number of ATMs in the world. The certificate-based trust model is far easier and much more managable to deploy than any shared secret scheme. (I'd sure consider it expensive to have two burly security guards show up at my front door to load 4 months of DES keys into my browser) > > Personally, I'd like to see the end of all PSK in IPSec and go to a certificate-based PK trust model. Which is why I really liked the JFK proposal. To those that would like raw public keys, I say this. It's not hard to wrap a PK in a self-signed certificate and it buys you a lot. Moving up to a CA chain buys you that much more. > > And finally, as for the compromises of credit card numbers and the like... Not one of those was due to a flaw in security protocols. They were a result of implementation errors in applications. Unfortunately (or maybe fortunately) IPSec does not take on that responsibility. > > Lee Dilkie > > Mitel Networks > 350 Legget Drive > Kanata, ON, Canada > K2K 2W7 > > Phone: 1-613-592-5660 > > "It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day." > - Homer Simpson (from "The Simpsons") > > > > -----Original Message----- > > From: Alex Alten [mailto:Alten@home.com] > > Sent: Wednesday, November 28, 2001 3:54 PM > > To: andrew.krywaniuk@alcatel.com; 'IPsec WG' > > Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > > > > > > > > You have completely missed my point, and incorrectly lumped > > Visa and ATM > > security systems together. > > > > My point is that for over 20 years hundred's of millions of > > people have > > been using *DES* to get cash out of ATM machines. This is a > > very large > > scale system, the number of Internet hosts is an order of > > magnitude smaller. > > As far as I know there has never been a major compromise of > > this system, > > where lots of money was stolen from thousands of accounts. > > > > - Alex > > > > > > At 08:58 PM 11/27/2001 -0500, Andrew Krywaniuk wrote: > > >Your argument is silly. > > > > > >Visa and ATM transactions aren't secure. There are multiple > > cases where > > >large credit card databases have been compromised (often > > when an online > > >merchant's website is hacked). > > ... > > > > > > > > >> -----Original Message----- > > >> From: owner-ipsec@lists.tislabs.com > > >> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Alex Alten > > >> Sent: Tuesday, November 27, 2001 12:24 PM > > >> To: Hugo Krawczyk; IPsec WG > > >> Subject: Re: On shared keys (was RE: SOI: identity > > protection and DOS) > > >> > > >> > > >> At 01:34 AM 11/27/2001 +0200, Hugo Krawczyk wrote: > > >> >Everyone agrees that public key is the ONLY way to a scalable > > >> >Internet-wide protocol. No question about it. In particular, > > >> >any key-exchange protocol for IPsec MUST provide a > > PK-based exchange. > > >> > > > >> > > >> No. I STRONGLY disagree. I'll give a counter example. > > The banking > > >> ATM network uses DES keys. It has scaled, in practice, world wide. > > >> > > >> And BTW, it's security & trust model is excellent. Have you > > >> ever heard > > >> of a major compromise, say on the scale of 25,000 card #'s > > >> being stolen > > >> (like with Visa?). Certainly nobody distrusts it because it uses > > >> symmetric keys for authentication. In fact I'm certain > > YOU trust it > > >> at least a couple a times a month. :-) > > >> > > > > -- > > > > Alex Alten > > Alten@Home.Com > > > From owner-ipsec@lists.tislabs.com Wed Nov 28 17:49:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT1nP828524; Wed, 28 Nov 2001 17:49:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09856 Wed, 28 Nov 2001 20:05:41 -0500 (EST) Message-ID: <4F48C7B31A8BD311B1D20090279C34B28238A8@clavin> From: Rahul Thakur To: "'ipsec@lists.tislabs.com'" Cc: "'rthakur@hotmail.com'" Subject: IPSec NAT-PT ? Date: Wed, 28 Nov 2001 17:18:56 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can anyone point me to any document/draft which explains interactions if any between IPSec/IPv6 support and NAT-PT. Do IPSec/IPv6 implementations tunnel IPV6 packets over a IPv4 network or vice versa. How does this play with NAT-PT. I guess that would determine the way policies are defined in IPSec. I am trying to estimate how these scenarios are handled. Any pointers or comments would be appreciated. Regards Rahul From owner-ipsec@lists.tislabs.com Wed Nov 28 17:51:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT1pw828602; Wed, 28 Nov 2001 17:51:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09909 Wed, 28 Nov 2001 20:12:03 -0500 (EST) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E02937211@CORPMX14> To: rja@inet.org Cc: ipsec@lists.tislabs.com, saag@mit.edu Subject: RE: [saag] RE: IP Storage and IPsec encapsulation Date: Wed, 28 Nov 2001 20:10:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Aha, found the hornet's nest ... > >The configuration of interest is: > > > >|--------------------------| |---------------| > >| IP Storage without IPsec |----| IPsec gateway |--> > >|--------------------------| |---------------| > > > >Where the link between the two boxes is not attached > >to anything else. The only IPsec implementation on this > >end of the connection is in the gateway, and the only > >link in the above diagram that complies with the protocol > >requirements is the link on the right hand side of the > >gateway. The gateway does not implement transport > >mode, hence the interest in tunnel mode. > > IP Storage really really needs end-to-end security IMNVHO. > > So I think the above is just a bogus implementer being lazy > rather than a valid security architecture. The above can't > provide the kinds of end-to-end security properties that > one needs for IP Storage applications. Could you be specific about what can't be provided, and how requiring transport mode would force/encourage it to be provided? > The IETF went through a similar discussion in the NFS context, > concluding in that case that fine-grained end-to-end security > properties were needed. The above can't even coarsely approximate > what NFS (which has lots of similarities to IP Storage otherwise) > was required to provide to be on the IETF standards-track. NFS is not the best analogy because NFS is an RPC-oriented protocol for which it makes sense to provide security at the granularity of individual RPCs, as a (user) identity can be associated with each RPC. The IP Storage protocols are TCP/IP encapsulations of SCSI and Fibre Channel -- these are session-oriented protocols for which it does not make sense to provide security at a granularity finer than a session as a (machine) identity is associated with each session, but no other finer-grain identities are associated with individual commands/messages/operations/etc. within a session. In the above diagram, a separate phase 2 SA would be required for every TCP connection (i.e., the typical security gateway behavior of running all traffic destined for the same remote gateway through the same tunnel would not be compliant); this is at least session granularity, and potentially finer grain depending on how sessions are formed and how phase 2 SAs are associated with phase 1 SAs. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: RJ Atkinson [mailto:rja@inet.org] > Sent: Wednesday, November 28, 2001 7:44 PM > To: Black_David@emc.com > Cc: ipsec@lists.tislabs.com; saag@mit.edu > Subject: Re: [saag] RE: IP Storage and IPsec encapsulation > > > At 17:47 28/11/01, Black_David@emc.com wrote: > >The configuration of interest is: > > > >|--------------------------| |---------------| > >| IP Storage without IPsec |----| IPsec gateway |--> > >|--------------------------| |---------------| > > > >Where the link between the two boxes is not attached > >to anything else. The only IPsec implementation on this > >end of the connection is in the gateway, and the only > >link in the above diagram that complies with the protocol > >requirements is the link on the right hand side of the > >gateway. The gateway does not implement transport > >mode, hence the interest in tunnel mode. > > IP Storage really really needs end-to-end security IMNVHO. > > So I think the above is just a bogus implementer being lazy > rather than a valid security architecture. The above can't > provide the kinds of end-to-end security properties that > one needs for IP Storage applications. > > The IETF went through a similar discussion in the NFS context, > concluding in that case that fine-grained end-to-end security > properties were needed. The above can't even coarsely approximate > what NFS (which has lots of similarities to IP Storage otherwise) > was required to provide to be on the IETF standards-track. > > Ran > rja@inet.org > > > From owner-ipsec@lists.tislabs.com Wed Nov 28 18:02:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT22L828881; Wed, 28 Nov 2001 18:02:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA09969 Wed, 28 Nov 2001 20:17:28 -0500 (EST) From: "Joseph D. Harwood" To: "Ipsec" Subject: ESP Draft Date: Wed, 28 Nov 2001 17:28:29 -0800 Message-ID: <000a01c17875$26b530c0$c7d0fea9@vesta> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-Loop-Detect: 1 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, A few questions/comments (mostly editorial) regarding the new draft: Page 8, Section 2 - (see Section ?? below) 3.3.2.2? Page 12, Section 2.2.1 - See Section ?? for processing details. 3.3.2.2? Page 14, Section 2.4 - " o For the purpose of ensuring that the bits to be encrypted are a multiple of the algorithm's blocksize (first bullet above), the padding computation applies to the Payload Data exclusive of any IV, but including the ESP trailer fields. If a combined algorithm mode requires transmission of the SPI and Sequence Number to effect integrity, then these data items, and any associated, ICV-equivalent data, are included in the computation of the pad length. (If the ESN option is selected, the high order 32 bits of the ESN also would enter into the computation, if the combined mode algorithm requires their transmission for integrity.)" The reference to SPI and Sequence Number above are for replicated transmission? If so, perhaps this could be mentioned. Page 17, Section 3.1.1 - "Destination options extension header(s) could appear before, after, or both before and after the ESP header depending on the semantics desired" Just a question I've had for a while, is there an advantage to allowing the destination options to come before the ESP header? Page 22, Section 3.3.2.1 - " 2. adds any necessary padding Ï Optional TFC padding and (encryption) Padding" Non-text character. Page 23. Section 3.3.2.2 - " 2. adds any necessary paddingÏincludes optional TFC padding and Padding." Non-text character, and should there be an (encryption) before the Padding? Page 32, Section 5 - "AES in CBC mode" 128/192/256? Page 32, Section 5 - Should 3DES be required for compatibility with existing implementations? Page 32, Section 5 - I saw the IP Storage group is looking at requiring AES in a Counter Mode, any word when NIST will have something on this? Best Regards, Joseph D. Harwood (408) 838-9434 jharwood@vesta-corp.com www.vesta-corp.com From owner-ipsec@lists.tislabs.com Wed Nov 28 20:48:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT4mO802926; Wed, 28 Nov 2001 20:48:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10294 Wed, 28 Nov 2001 22:42:21 -0500 (EST) To: Alex Alten Cc: , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <3.0.3.32.20011127092421.00f70cd0@mail> <3.0.3.32.20011128125358.00ef4878@mail> <3.0.3.32.20011128152948.00ef4878@mail> From: Derek Atkins Date: 28 Nov 2001 22:51:52 -0500 In-Reply-To: Alex Alten's message of "Wed, 28 Nov 2001 15:29:48 -0800" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten writes: > Given that this is a 25 year old design I think that using 1-DES as a problem > is not a fair statement. I personally know one of the original designers You are right that 25 years ago 1-DES was a reasonable design choice. The fact that it hasn't been upgraded in 25 years is most certainly a problem. Considering the effectiveness of Deep Crack, I would hope that the banking industry would be trying to upgrade to at least 3-DES relatively quickly. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Wed Nov 28 22:04:16 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAT64F804559; Wed, 28 Nov 2001 22:04:15 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA10461 Thu, 29 Nov 2001 00:00:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Alex Alten" Cc: , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Illegal-Object: S References: <3.0.3.32.20011127092421.00f70cd0@mail> <3.0.3.32.20011128125358.00ef4878@mail> <3.0.3.32.20011128152948.00ef4878@mail> ^-illegal end of message identification From: "Derek Atkins" Date: 28 Nov 2001 22:51:52 -0500 In-Reply-To: Alex Alten's message of "Wed, 28 Nov 2001 15:29:48 -0800" Message-ID: Lines: 17 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 29 Nov 2001 05:10:15.0187 (UTC) FILETIME=[2146DE30:01C17894] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten writes: > Given that this is a 25 year old design I think that using 1-DES as a problem > is not a fair statement. I personally know one of the original designers You are right that 25 years ago 1-DES was a reasonable design choice. The fact that it hasn't been upgraded in 25 years is most certainly a problem. Considering the effectiveness of Deep Crack, I would hope that the banking industry would be trying to upgrade to at least 3-DES relatively quickly. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Nov 29 03:56:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATBuD815380; Thu, 29 Nov 2001 03:56:13 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA10992 Thu, 29 Nov 2001 06:09:20 -0500 (EST) Date: Thu, 29 Nov 2001 13:18:58 +0200 (IST) From: Hugo Krawczyk To: Derek Atkins cc: Charlie_Kaufman@iris.com, IPsec WG Subject: Re: IKEv2 and SIGMA In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 28 Nov 2001, Derek Atkins wrote: > Hugo Krawczyk writes: > > > ESP specifications are defined to secure raw data, not functioning > > as an authentication mechansim in a key exchange protocol. > > Actually, Hugo, if you step back and view "a key exchange protocol" as > "raw data", then ESP works perfectly well. Keep in mind that this is > not ESP in the standard sense. Rather, this is using the ESP packet > format with the key-exchange-protocol Security Association. Derek, if you step back and view "a key exchange protocol" as "raw data", as you suggest, you will most probably end with an insecure protocol. If you do not understand what I am talking about go over the follwoing three exercises (you may consider this to be of theoretical interst only, yet I ask you to do it): (a) can you explain why the "raw data" of third and fourth message of IKEv2 needs strong integrity protection via ESP given that we already have a strong authentication of this data via the initiator's signature? (b) the JFK protocol does not use the integrity protection of HMAC in addition to the signature. Yet, their protocol is secure. So why I insist so much that IKEv2 adopts the SIGMA design and add the HMAC (or prf) under the signature? (c) If one moves the ID payload from the 3rd message of IKEv2 to the first message; is the protocol with the use of ESP, and with strong integrity, secure? [Please, do not dismiss this last question just because currently IKEv2 does not allow sending the ID in the first message -- I actually would recommend they allow for that, as in OIDi of SIGMA. But this is anyway not the point of my question] If you can answer all these questions then you wil really understand that there is nothing further from security that treating the key exchange information as raw data. It is EACH DETAIL in the way you do authentication, such as what EXACTLY goes under the signature, why is a signature sufficient or insufficient, what goes in plaintext and what goes encrypted, etc that makes the difference between a secure or insecure protocol. One thing is to discuss functionality (yes or not weak DoS protection, yes or not id protection, yes or not shared-mode, etc) where each one has its own subjective (and equally arguable) reasons and taste, and it is another VERY DIFFERENT thing to discuss the core cryptographic design of a key exchange protocol. This should not be done through "rough consensus" but using the mathematical design and analysis tools that we have. Hugo From owner-ipsec@lists.tislabs.com Thu Nov 29 03:56:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATBuK815402; Thu, 29 Nov 2001 03:56:20 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA10967 Thu, 29 Nov 2001 05:56:27 -0500 (EST) Message-Id: <200111291105.GAA20334@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-cbc-03.txt Date: Thu, 29 Nov 2001 06:05:56 -0500 Sender: owner-ipsec@lists.tislabs.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 AES Cipher Algorithms and Their Use With IPsec Author(s) : S. Frankel, S. Kelly, R. Glenn Filename : draft-ietf-ipsec-ciph-aes-cbc-03.txt Pages : 12 Date : 28-Nov-01 This document describes the use of the AES Cipher Algorithm in Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mecha- nism within the context of the IPsec Encapsulating Security Payload (ESP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also 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-ciph-aes-cbc-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011128143553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-cbc-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-cbc-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128143553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Nov 29 06:11:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATEB8824024; Thu, 29 Nov 2001 06:11:09 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11253 Thu, 29 Nov 2001 08:26:17 -0500 (EST) Message-Id: <5.1.0.14.2.20011128194044.009feec0@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 28 Nov 2001 19:43:36 -0500 To: Black_David@emc.com From: RJ Atkinson Subject: Re: [saag] RE: IP Storage and IPsec encapsulation Cc: ipsec@lists.tislabs.com, saag@mit.edu In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 17:47 28/11/01, Black_David@emc.com wrote: >The configuration of interest is: > >|--------------------------| |---------------| >| IP Storage without IPsec |----| IPsec gateway |--> >|--------------------------| |---------------| > >Where the link between the two boxes is not attached >to anything else. The only IPsec implementation on this >end of the connection is in the gateway, and the only >link in the above diagram that complies with the protocol >requirements is the link on the right hand side of the >gateway. The gateway does not implement transport >mode, hence the interest in tunnel mode. IP Storage really really needs end-to-end security IMNVHO. So I think the above is just a bogus implementer being lazy rather than a valid security architecture. The above can't provide the kinds of end-to-end security properties that one needs for IP Storage applications. The IETF went through a similar discussion in the NFS context, concluding in that case that fine-grained end-to-end security properties were needed. The above can't even coarsely approximate what NFS (which has lots of similarities to IP Storage otherwise) was required to provide to be on the IETF standards-track. Ran rja@inet.org From owner-ipsec@lists.tislabs.com Thu Nov 29 06:11:11 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATEBA824038; Thu, 29 Nov 2001 06:11:10 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11265 Thu, 29 Nov 2001 08:28:14 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sva owned process doing -bs Date: Wed, 28 Nov 2001 19:21:52 +0200 (EET) From: "sami.vaarala" X-Sender: sva@localhost.localdomain To: "Hallam-Baker, Phillip" cc: "'Steven M. Bellovin'" , alexey.vyskubov@nokia.com, ipsec@lists.tislabs.com Subject: RE: Just Fast Keying (JFK) draft In-Reply-To: <2F3EC696EAEED311BB2D009027C3F4F405869890@vhqpostal.verisign.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 28 Nov 2001, Hallam-Baker, Phillip wrote: > I am somewhat disappointed that there appears to have been almost no > substantive discussion of JFK on the list. This may indicate that the > protocol is secure, or it may indicate that nobody has been bothered to read > it - which given the effort put into previous flames over the subject of > keying would be somewhat disappointing. I read the draft, and found it very promising. However, it is difficult to compare IKEv1/IKEv2 to JFK at this point, because JFK has not been specified in full detail yet. (I'm referring to implementation complexity, a security comparison should be possible.) To compare fairly, a wire format and a definition of the JFK "sa" payload would be needed. In IKEv2, the SA payload and the traffic selectors are a major cause of complexity, and thus have to be taken into account when comparing the two proposals. -Sami From owner-ipsec@lists.tislabs.com Thu Nov 29 06:11:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATEBR824071; Thu, 29 Nov 2001 06:11:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11241 Thu, 29 Nov 2001 08:24:12 -0500 (EST) From: balenson@tislabs.com Date: Wed, 28 Nov 2001 17:24:05 -0500 (EST) Message-Id: <200111282224.fASMO5K14564@raven.gw.tislabs.com> To: ipsec@tislabs.com Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ipsec@lists.tislabs.com Thu Nov 29 06:11:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATEBV824087; Thu, 29 Nov 2001 06:11:31 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11252 Thu, 29 Nov 2001 08:26:12 -0500 (EST) X-Originating-IP: [64.161.186.193] From: "Rahul Thakur" To: Cc: "Rahul Thakur" Subject: IPSec NAT-PT ? Date: Wed, 28 Nov 2001 17:04:14 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011C_01C1782E.B4FDDF90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 29 Nov 2001 00:58:28.0893 (UTC) FILETIME=[F53954D0:01C17870] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_011C_01C1782E.B4FDDF90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can anyone point me to any document/draft which explains interactions if = any between IPSec/IPv6 support and NAT-PT. Do IPSec/IPv6 implementations tunnel IPV6 packets over a IPv4 network or = vice versa. How does this play with=20 NAT-PT. I guess that would determine the way policies are defined in = IPSec. I am trying to estimate how these scenarios are handled. Any pointers or = comments would be appreciated. Regards Rahul ------=_NextPart_000_011C_01C1782E.B4FDDF90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can anyone point me to any = document/draft which=20 explains interactions if any between IPSec/IPv6 support and NAT-PT. Do IPSec/IPv6 implementations tunnel = IPV6 packets=20 over a IPv4 network or vice versa. How does this play with = NAT-PT. I guess that would determine = the way=20 policies are defined in IPSec. I am trying to estimate how these = scenarios are=20 handled. Any pointers or comments would be appreciated. Regards Rahul ------=_NextPart_000_011C_01C1782E.B4FDDF90-- From owner-ipsec@lists.tislabs.com Thu Nov 29 06:17:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATEH4824538; Thu, 29 Nov 2001 06:17:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11259 Thu, 29 Nov 2001 08:27:13 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sva owned process doing -bs Date: Wed, 28 Nov 2001 18:45:54 +0200 (EET) From: "sami.vaarala" X-Sender: sva@localhost.localdomain To: Tylor Allison cc: Ricky Charlet , IPsec WG Subject: Re: On shared keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 28 Nov 2001, Tylor Allison wrote: > On Tue, 27 Nov 2001, Ricky Charlet wrote: > > I think that we should do a PSK authentication method because it would > > be useful. > > I agree with you Ricky ... IMO, if we leave out PSK authentication from > SOI, then we are not addressing the needs of the marketplace. First, as > others have pointed out, for site-to-site VPNs, PSK seems to be the > de-facto standard. Why? Because they are simple to setup/manage and they > work (interoperable implementations). Can the new SOI standard be used to >[...] In an earlier mail I pointed out another alternative that I think would work for site-to-site setups: let the key exchange protocol support only RSA, and generate RSA keypairs deterministically from the pre-shared secret. In essence, you take the pre-shared secret, create a PRNG out of the secret using a hash function, and then use a determining RSA keypair generator to create the keypair. Both communicating hosts use the same pre-shared secret, and thus end up with the same RSA keypair. Thus, no PSK support in the key exchange, but the same simple administration. -Sami From owner-ipsec@lists.tislabs.com Thu Nov 29 07:29:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATFT0827925; Thu, 29 Nov 2001 07:29:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11770 Thu, 29 Nov 2001 09:28:25 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15366.18464.416439.388616@pkoning.dev.equallogic.com> Date: Thu, 29 Nov 2001 09:37:20 -0500 (EST) From: Paul Koning To: mikecyr@austin.ibm.com CC: ipsec@lists.tislabs.com Subject: Re: CBC makes Implementations too Slow. References: <20011031005533.B51867C01@berkshire.research.att.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Michael" == Michael Cyr writes: Michael> On Tue, 30 Oct 2001, Steven M. Bellovin wrote: >> CBC mode requires feedback, which makes it impossible to pipeline >> encryptions; you can't encrypt plaintext block P[n+1] until you >> have the ciphertext from encrypting P[n]. Michael> I know this discussion was a while ago, but I have a Michael> question related to the problem. First, let me say that I'm Michael> new to the list, and still somewhat new to IPsec in general, Michael> so I hope you'll forgive any ignorance on my part. Michael> Would it be a complete violation of the protocol to use Michael> random data for the IV data instead of a portion of the Michael> ciphertext of the previous block? I know this violates the Michael> spirit of cipher block _chaining_, but it would seem to Michael> address the concern that CBC was meant to fix, which is to Michael> ensure that if the same cleartext is encrypted twice, it Michael> doesn't produce the same ciphertext. Anyone have a Michael> definitive answer on this? My reading of the spec is that this is perfectly legal. The one thing you're not supposed to do is to use a low entropy IV value, such as a packet counter. That doesn't fix the performance problem for a single packet, though. You can do each packet independently if you use a random IV, but each plaintext block *within* the packet is still dependent on the previous block. On the other hand, using independent IVs per packet provides a useful gain if you have a number of packets pending (for the same SA) -- you can then encrypt them in parallel. In high load cases you will almost certainly have multiple packets waiting to be processed, so this should indeed give you a significant performance gain. paul From owner-ipsec@lists.tislabs.com Thu Nov 29 07:35:32 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATFZW828780; Thu, 29 Nov 2001 07:35:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11796 Thu, 29 Nov 2001 09:36:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15366.18952.179856.705104@pkoning.dev.equallogic.com> Date: Thu, 29 Nov 2001 09:45:28 -0500 (EST) From: Paul Koning To: warlord@mit.edu CC: ipsec@lists.tislabs.com Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <3.0.3.32.20011127092421.00f70cd0@mail> <3.0.3.32.20011128125358.00ef4878@mail> <3.0.3.32.20011128152948.00ef4878@mail> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Derek" == Derek Atkins writes: Derek> Alex Alten writes: >> Given that this is a 25 year old design I think that using 1-DES >> as a problem is not a fair statement. I personally know one of >> the original designers Derek> You are right that 25 years ago 1-DES was a reasonable design Derek> choice. The fact that it hasn't been upgraded in 25 years is Derek> most certainly a problem. Considering the effectiveness of Derek> Deep Crack, I would hope that the banking industry would be Derek> trying to upgrade to at least 3-DES relatively quickly. Also, the original paper describing the viability of a Deep Crack attack was published just about that long ago (Diffie & Hellman, 1977). Come to think of it, the DES FIPS came out in 1977, so presumably its use in banking isn't quite 25 years old. paul From owner-ipsec@lists.tislabs.com Thu Nov 29 08:55:14 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATGtE804984; Thu, 29 Nov 2001 08:55:14 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12043 Thu, 29 Nov 2001 11:10:44 -0500 (EST) Message-ID: <29B5A21C13C8D51190F900805F65B4EC39EFD0@rndex50.ottawa.mitel.com> From: "Dilkie, Lee" To: "'Paul Koning'" , mikecyr@austin.ibm.com Cc: ipsec@lists.tislabs.com Subject: RE: CBC makes Implementations too Slow. Date: Thu, 29 Nov 2001 10:53:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm not sure if using a packet counter for an IV is bad. It's just that you can't wrap. It's important that the same key/IV combination not get reused. I don't believe that the requirement for a random IV is necessary. The reason I point this out is that the secure RTP spec uses an implicit IV (to save on transmitting extra data) which is based on information in the RTP header (and really is just a packet counter under the covers). Lee Dilkie Mitel Networks 350 Legget Drive Kanata, ON, Canada K2K 2W7 Phone: 1-613-592-5660 "It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day." - Homer Simpson (from "The Simpsons") > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, November 29, 2001 9:37 AM > To: mikecyr@austin.ibm.com > Cc: ipsec@lists.tislabs.com > Subject: Re: CBC makes Implementations too Slow. > > > >>>>> "Michael" == Michael Cyr writes: > > Michael> On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > >> CBC mode requires feedback, which makes it impossible to pipeline > >> encryptions; you can't encrypt plaintext block P[n+1] until you > >> have the ciphertext from encrypting P[n]. > > Michael> I know this discussion was a while ago, but I have a > Michael> question related to the problem. First, let me say that I'm > Michael> new to the list, and still somewhat new to IPsec in general, > Michael> so I hope you'll forgive any ignorance on my part. > > Michael> Would it be a complete violation of the protocol to use > Michael> random data for the IV data instead of a portion of the > Michael> ciphertext of the previous block? I know this violates the > Michael> spirit of cipher block _chaining_, but it would seem to > Michael> address the concern that CBC was meant to fix, which is to > Michael> ensure that if the same cleartext is encrypted twice, it > Michael> doesn't produce the same ciphertext. Anyone have a > Michael> definitive answer on this? > > My reading of the spec is that this is perfectly legal. The one thing > you're not supposed to do is to use a low entropy IV value, such as a > packet counter. > > That doesn't fix the performance problem for a single packet, though. > You can do each packet independently if you use a random IV, but each > plaintext block *within* the packet is still dependent on the previous > block. > > On the other hand, using independent IVs per packet provides a useful > gain if you have a number of packets pending (for the same SA) -- you > can then encrypt them in parallel. In high load cases you will almost > certainly have multiple packets waiting to be processed, so this > should indeed give you a significant performance gain. > > paul > From owner-ipsec@lists.tislabs.com Thu Nov 29 08:56:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATGuY805014; Thu, 29 Nov 2001 08:56:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12003 Thu, 29 Nov 2001 10:57:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14> References: <277DD60FB639D511AC0400B0D068B71E0293720E@CORPMX14> Date: Thu, 29 Nov 2001 10:57:51 -0500 To: Black_David@emc.com From: Stephen Kent Subject: [saag] RE: IP Storage and IPsec encapsulation Cc: mat@cisco.com, ipsec@lists.tislabs.com, saag@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:47 PM -0500 11/28/01, Black_David@emc.com wrote: > > Since this is a host-host application layer >> protocol, that pretty much implies that you'd want >> to use transport mode, since you end up with the >> same IP src/dst addresses if you used tunnel mode, >> which sounds gratuitously redundant. > >The configuration of interest is: > >|--------------------------| |---------------| >| IP Storage without IPsec |----| IPsec gateway |--> >|--------------------------| |---------------| > >Where the link between the two boxes is not attached >to anything else. The only IPsec implementation on this >end of the connection is in the gateway, and the only >link in the above diagram that complies with the protocol >requirements is the link on the right hand side of the >gateway. The gateway does not implement transport >mode, hence the interest in tunnel mode. David, The box in the above diagram looks a lot like a BITW IPsec implementation, rather than an SG, and if so it could use transport mode and be compliant with 2401. Only if the IP storage behind the IPsec device has multiple addresses would the IPsec device need to be viewed as an SG and thus implement tunnel mode only. Steve From owner-ipsec@lists.tislabs.com Thu Nov 29 08:56:34 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATGuY805016; Thu, 29 Nov 2001 08:56:34 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12009 Thu, 29 Nov 2001 10:59:34 -0500 (EST) To: "sami.vaarala" Cc: Tylor Allison , Ricky Charlet , IPsec WG Subject: Re: On shared keys References: From: Derek Atkins Date: 29 Nov 2001 11:08:54 -0500 In-Reply-To: "sami.vaarala"'s message of "Wed, 28 Nov 2001 18:45:54 +0200 (EET)" Message-ID: Lines: 66 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "sami.vaarala" writes: > In an earlier mail I pointed out another alternative that > I think would work for site-to-site setups: let the key > exchange protocol support only RSA, and generate RSA keypairs > deterministically from the pre-shared secret. > > In essence, you take the pre-shared secret, create a PRNG out of > the secret using a hash function, and then use a determining > RSA keypair generator to create the keypair. Both communicating > hosts use the same pre-shared secret, and thus end up with the > same RSA keypair. > > Thus, no PSK support in the key exchange, but the same simple > administration. > > -Sami But you dont WANT both sides to have the same keypair. The whole point of public key cryptography is that each entity has one and only one keypair, from which they can share their PUBLIC key with EVERY peer. If each set of peers are sharing a key then you have no gains over pre-shared secret keys. Basically, Alice generates Pub_a and Priv_a, Bob generates Pub_b and Priv_b, Charlie generates Pub_c and Priv_c, Dave generates Pub_d and Priv_d. To get a full mesh, each entity shares their public key with each other. This means that, in the end, each of the 4 machines holds four (4) public keys (one for each peer,), and one (1) private key (their own): Alice: Priv_a, Pub_a, Pub_b, Pub_c, Pub_d Bob: Priv_b, Pub_a, Pub_b, Pub_c, Pub_d Charlie: Priv_c, Pub_a, Pub_b, Pub_c, Pub_d Dave: Priv_d, Pub_a, Pub_b, Pub_c, Pub_d Notice that there are a total of four key-pairs in this mesh. Alice can use the same "key" (public key) with every peer. On the other hand, you would need six distinct secret keys to obtain the same mesh: Alice: K_ab, K_ac, K_ad Bob: K_ab, K_bc, K_bd Charlie: K_ac, K_bc, K_cd Dave: K_ad, K_bd, K_cd Now, if you want to add Eve to the mesh, you would need to add one more public key pair the system (Pub_e, Priv_e), or you would need to add four secret keys to the system (K_ae, K_be, K_ce, K_de). Basically, the total number of secret keys in the system is SUM(1..N) = n*(n-1)/2, which scales O(n^2), whereas the total number of public keys in the system is N. Do I even need to mention the insecurity of generating an RSA key from a short secret? Worse, do I need to mention the insecurity of both sides sharing a SINGLE keypair? -derek > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Nov 29 09:21:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATHLu806736; Thu, 29 Nov 2001 09:21:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12096 Thu, 29 Nov 2001 11:36:44 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14> References: <277DD60FB639D511AC0400B0D068B71E02937206@CORPMX14> Date: Thu, 29 Nov 2001 11:39:32 -0500 To: Black_David@emc.com From: Stephen Kent Subject: Re: IP Storage and IPsec encapsulation Cc: ipsec@lists.tislabs.com, saag@mit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk David, I'm trying to make my way through over 1K messages (that's what I get for going on a week vacation when new IPsec IDs come out ...) and so I didn't read all of your messages in order. Looking back at your original (?) message about use of tunnel vs. transport mode I agree with you that this should not be a problem for iSCSI use of IPsec, from a standards perspective. As you note, people need to be smart in configuring an external IPsec device (or set of devices) to ensure that, within their context, the desired security properties are achieved. Thus, merely because tunnel mode could be terminated at a point which would undermine security, in general, that does not mean that its use should be avoided in your spec, for the reasons you cite. My previous message also noted that the outboard IPsec device could be a bump in the wire, vs. an SG, which would allow both transport and tunnel mode, but this is a minor difference relative to your bugger question. As you noted, it is a local security policy (and architecture) issue where the IPsec devices are placed and whether that placement provides adequate security. Steve From owner-ipsec@lists.tislabs.com Thu Nov 29 09:22:07 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATHM6806754; Thu, 29 Nov 2001 09:22:06 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12090 Thu, 29 Nov 2001 11:33:10 -0500 (EST) Date: Thu, 29 Nov 2001 18:41:49 +0200 From: Sara Bitan Subject: Re: Just Fast Keying (JFK) draft To: "sami.vaarala" , David Wagner Cc: "'Steven M. Bellovin'" , alexey.vyskubov@nokia.com, ipsec@lists.tislabs.com, "Hallam-Baker, Phillip" Message-id: <023801c178f4$c0cb8040$3fa6003e@commagine.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sami! I agree with you. We have to compare two fully specified protocol to find out if one of them is _significantly_ simpler then the other. David! You said that "IKE has always scared me with its complexity, so I am warmly supportive of simplification efforts in this area. " Did you look at IKEv2, or at IKE-SIGMA? Both drafts suggest major changes to IKEv1, and I think they are both considerably less complex. What do you think? As a person who invested a lot in IKE implementation and interoperability till we brought IKEv1 to its maturity, I think we should make sure that a totally new key management protocol will be either _significantly_ more secure, or _significantly_ simpler, or answers requirements that are not answered by the two proposals to a new version of IKE. Before we launch this new adventure of inventing, implementing and bringing a new key management to its maturity (it took us five years last time we did it - yes I know you'll say that IKEv1 is complex;-) ) we must have very good reasons to do it, and I don't think we have them, Sara. ----- Original Message ----- From: sami.vaarala To: Hallam-Baker, Phillip Cc: 'Steven M. Bellovin' ; ; Sent: Wednesday, November 28, 2001 7:21 PM Subject: RE: Just Fast Keying (JFK) draft > > On Wed, 28 Nov 2001, Hallam-Baker, Phillip wrote: > > I am somewhat disappointed that there appears to have been almost no > > substantive discussion of JFK on the list. This may indicate that the > > protocol is secure, or it may indicate that nobody has been bothered to read > > it - which given the effort put into previous flames over the subject of > > keying would be somewhat disappointing. > > I read the draft, and found it very promising. However, it is difficult > to compare IKEv1/IKEv2 to JFK at this point, because JFK has not been > specified in full detail yet. (I'm referring to implementation > complexity, a security comparison should be possible.) > > To compare fairly, a wire format and a definition of the JFK "sa" > payload would be needed. In IKEv2, the SA payload and the traffic > selectors are a major cause of complexity, and thus have to be taken > into account when comparing the two proposals. > > -Sami > From owner-ipsec@lists.tislabs.com Thu Nov 29 09:52:23 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATHqM810753; Thu, 29 Nov 2001 09:52:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12178 Thu, 29 Nov 2001 12:02:11 -0500 (EST) Date: Thu, 29 Nov 2001 12:10:35 -0500 (EST) From: Henry Spencer To: Derek Atkins cc: IPsec WG Subject: Re: On shared keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 29 Nov 2001, Derek Atkins wrote: > > I think would work for site-to-site setups: let the key > > exchange protocol support only RSA, and generate RSA keypairs > > deterministically from the pre-shared secret... > > But you dont WANT both sides to have the same keypair. The whole > point of public key cryptography is that each entity has one and only > one keypair, from which they can share their PUBLIC key... This isn't a way of doing proper public-key cryptography. It's a way of doing shared-secret authentication using crypto machinery which only needs to understand public keys. It has all the disadvantages of shared-secret, *EXCEPT* that it has zero impact on the protocol and the protocol implementation. Nobody is claiming that this replaces real public-key cryptography. The claim is that it can avoid the need to contort the protocol for the sake of users who still want to use shared secrets. As such, it looks fairly promising, although details would need to be filled in and reviewed by the crypto gurus. > Do I even need to mention the insecurity of generating an RSA key from > a short secret? Worse, do I need to mention the insecurity of both > sides sharing a SINGLE keypair? In what way is it worse than old-style shared secrets? *That* is the crucial question. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Nov 29 10:02:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATI2v811798; Thu, 29 Nov 2001 10:02:57 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12222 Thu, 29 Nov 2001 12:16:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "sami.vaarala" Cc: "Tylor Allison" , "Ricky Charlet" , "IPsec WG" Subject: Re: On shared keys References: From: "Derek Atkins" Date: 29 Nov 2001 11:08:54 -0500 In-Reply-To: "sami.vaarala"'s message of "Wed, 28 Nov 2001 18:45:54 +0200 (EET)" Message-ID: Lines: 66 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 29 Nov 2001 17:25:22.0484 (UTC) FILETIME=[D3464740:01C178FA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "sami.vaarala" writes: > In an earlier mail I pointed out another alternative that > I think would work for site-to-site setups: let the key > exchange protocol support only RSA, and generate RSA keypairs > deterministically from the pre-shared secret. > > In essence, you take the pre-shared secret, create a PRNG out of > the secret using a hash function, and then use a determining > RSA keypair generator to create the keypair. Both communicating > hosts use the same pre-shared secret, and thus end up with the > same RSA keypair. > > Thus, no PSK support in the key exchange, but the same simple > administration. > > -Sami But you dont WANT both sides to have the same keypair. The whole point of public key cryptography is that each entity has one and only one keypair, from which they can share their PUBLIC key with EVERY peer. If each set of peers are sharing a key then you have no gains over pre-shared secret keys. Basically, Alice generates Pub_a and Priv_a, Bob generates Pub_b and Priv_b, Charlie generates Pub_c and Priv_c, Dave generates Pub_d and Priv_d. To get a full mesh, each entity shares their public key with each other. This means that, in the end, each of the 4 machines holds four (4) public keys (one for each peer,), and one (1) private key (their own): Alice: Priv_a, Pub_a, Pub_b, Pub_c, Pub_d Bob: Priv_b, Pub_a, Pub_b, Pub_c, Pub_d Charlie: Priv_c, Pub_a, Pub_b, Pub_c, Pub_d Dave: Priv_d, Pub_a, Pub_b, Pub_c, Pub_d Notice that there are a total of four key-pairs in this mesh. Alice can use the same "key" (public key) with every peer. On the other hand, you would need six distinct secret keys to obtain the same mesh: Alice: K_ab, K_ac, K_ad Bob: K_ab, K_bc, K_bd Charlie: K_ac, K_bc, K_cd Dave: K_ad, K_bd, K_cd Now, if you want to add Eve to the mesh, you would need to add one more public key pair the system (Pub_e, Priv_e), or you would need to add four secret keys to the system (K_ae, K_be, K_ce, K_de). Basically, the total number of secret keys in the system is SUM(1..N) = n*(n-1)/2, which scales O(n^2), whereas the total number of public keys in the system is N. Do I even need to mention the insecurity of generating an RSA key from a short secret? Worse, do I need to mention the insecurity of both sides sharing a SINGLE keypair? -derek > > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Nov 29 10:29:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATITf814200; Thu, 29 Nov 2001 10:29:41 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12288 Thu, 29 Nov 2001 12:42:27 -0500 (EST) Message-ID: <10C8636AE359D4119118009027AE9987120B7F72@FMSMSX34> From: "Walker, Jesse" To: ipsec@lists.tislabs.com Subject: Son-of-IKE Selection Criteria? Date: Thu, 29 Nov 2001 09:51:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Suddenly we suffer an embarassment of riches. We have three thoughtful, very well crafted, very credible proposals for Son-of-IKE, and we need to establish some selection criteria to choose among them. I wish we didn't have to choose, because all three have some very nice characteristics. The IKEv2 proposal of Harkins-Perlman-Kaufman is by far the most complete of the three, addresses the widest variety of issues, and remains the most faithful to the existing IKE. It appears to fix many of IKEv1's most onerous problems, and seems like it would have the best time-to-market characteristics. One of its most important steps is it begins to make security association management more explicit, which will finally help resolve the interoperability difficulties related to session termination. It is particularly pleasurable seeing the large number of practical protocol physical implementation issues dealt with, making it more plausible that resulting implementations might actually interoperate. Its completeness and degree of reuse of existing IKE elements and design philosophy make it very attractive. Krawzyck's SIGMA proposal strikes me as by far the cleanest, simplest, and most elegant of the three; enough said. It reuses much of IKE. However, its three-way handshake uses different sorts of state machines than the two-way handshakes used by the other proposals, so implementors would have to learn a new bag of tricks. SIGMA's greatest drawback is that it is fairly incomplete compared with Harkins et al proposal. The JFK proposal of Aiello et. al. exhibits the most novelty and creativity of the three. It also strikes me as the most complex of the three, but this is due to the novelty of its solution to the DoS problem; good optimizations often introduce more complexity. This complexity does not appear to have compromised the security goals, and given its pedigree, probably will not introduce problems, but this remains to be established. JFK does introduce one striking simplification: the elimination of negotiation by letting the responder dictate the security policy. One of the key deployment barriers to IPsec--perhaps the key one--has been the lack of a policy distribution and coordination mechanism, and JFK's approach sweeps this away entirely. JFK is also the only one of the three to grope toward a realistic rekey algorithm, another deficiency in the current IPsec. I would be happy for the WG to begin with any one of the three; getting a credible Son-of-IKE is the most important step we can take to make IPsec widely deployable, and all three proposals fit the bill in my estimation. If I had to make a choice today, I would select SIGMA, on the basis that elegant designs tend to lead to the best, most long-lived implementations and to best security. But I really would prefer not choosing; I would really like to see SIGMA incorporated into IKEv2, and for the authors also to pick up many of the good ideas from JFK, like its approach to policy and rekey. For whatever it's worth, this is my first reading of all three documents. What I'd like to know how the WG will make a decision among these excellent candidates. -- Jesse Walker From owner-ipsec@lists.tislabs.com Thu Nov 29 11:18:48 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATJIl815929; Thu, 29 Nov 2001 11:18:47 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12478 Thu, 29 Nov 2001 13:27:17 -0500 (EST) Message-Id: <200111291827.ACS00513@mira-sjcm-3.cisco.com> X-Sender: sfluhrer@mira-sjcm-3 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 29 Nov 2001 10:37:05 -0800 To: "Dilkie, Lee" , "'Paul Koning'" , mikecyr@austin.ibm.com From: Scott Fluhrer Subject: RE: CBC makes Implementations too Slow. Cc: ipsec@lists.tislabs.com In-Reply-To: <29B5A21C13C8D51190F900805F65B4EC39EFD0@rndex50.ottawa.mite l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 07:53 AM 11/29/01 , Dilkie, Lee wrote: >I'm not sure if using a packet counter for an IV is bad. It's just that you can't wrap. It's important that the same key/IV combination not get reused. I don't believe that the requirement for a random IV is necessary. I disagree. If you use a counter, and the initial blocks of two packets differ in precisely the same bits as the two counters do, the same plaintext will be given to the underlying block cipher, and produce the exact same ciphertext. I would claim that this potential leak is too serious to permit using a counter. In fact, the suggestion to reuse a previous ciphertext block as an IV can be insufficient, and we really should require implementations to use random IVs. >The reason I point this out is that the secure RTP spec uses an implicit IV (to save on transmitting extra data) which is based on information in the RTP header (and really is just a packet counter under the covers). Apart from the silliness of the argument "that protocol over there does it, hence it must be secure", may I point out that draft-ieft-avt-srtp-01 uses counter mode (or another "seekable additive stream cipher"), not CBC. > >Lee Dilkie > >Mitel Networks >350 Legget Drive >Kanata, ON, Canada >K2K 2W7 > >Phone: 1-613-592-5660 > >"It wasn't easy to juggle a pregnant wife and a troubled child, but somehow I managed to fit in eight hours of TV a day." > - Homer Simpson (from "The Simpsons") > > >> -----Original Message----- >> From: Paul Koning [mailto:ni1d@arrl.net] >> Sent: Thursday, November 29, 2001 9:37 AM >> To: mikecyr@austin.ibm.com >> Cc: ipsec@lists.tislabs.com >> Subject: Re: CBC makes Implementations too Slow. >> >> >> >>>>> "Michael" == Michael Cyr writes: >> >> Michael> On Tue, 30 Oct 2001, Steven M. Bellovin wrote: >> >> CBC mode requires feedback, which makes it impossible to pipeline >> >> encryptions; you can't encrypt plaintext block P[n+1] until you >> >> have the ciphertext from encrypting P[n]. >> >> Michael> I know this discussion was a while ago, but I have a >> Michael> question related to the problem. First, let me say that I'm >> Michael> new to the list, and still somewhat new to IPsec in general, >> Michael> so I hope you'll forgive any ignorance on my part. >> >> Michael> Would it be a complete violation of the protocol to use >> Michael> random data for the IV data instead of a portion of the >> Michael> ciphertext of the previous block? I know this violates the >> Michael> spirit of cipher block _chaining_, but it would seem to >> Michael> address the concern that CBC was meant to fix, which is to >> Michael> ensure that if the same cleartext is encrypted twice, it >> Michael> doesn't produce the same ciphertext. Anyone have a >> Michael> definitive answer on this? >> >> My reading of the spec is that this is perfectly legal. The one thing >> you're not supposed to do is to use a low entropy IV value, such as a >> packet counter. >> >> That doesn't fix the performance problem for a single packet, though. >> You can do each packet independently if you use a random IV, but each >> plaintext block *within* the packet is still dependent on the previous >> block. >> >> On the other hand, using independent IVs per packet provides a useful >> gain if you have a number of packets pending (for the same SA) -- you >> can then encrypt them in parallel. In high load cases you will almost >> certainly have multiple packets waiting to be processed, so this >> should indeed give you a significant performance gain. >> >> paul >> > From owner-ipsec@lists.tislabs.com Thu Nov 29 11:18:57 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATJIu815942; Thu, 29 Nov 2001 11:18:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12532 Thu, 29 Nov 2001 13:34:38 -0500 (EST) Date: Thu, 29 Nov 2001 20:44:38 +0200 (Israel Standard Time) From: Arne Ansper To: Joel Snyder cc: Subject: Re: Gee, shared secrets suck (was: Re: SOI: identity protection and DOS) In-Reply-To: <3C0501D3.314FE58A@opus1.com> Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > system and how end users have actually implemented VPNs. You must have > something akin to the simplicity and shortness of PSS to ensure that > people will be able to at least prototype these systems in their > networks. i wrote up my idea at http://home.cyber.ee/arne/howto.html arne From owner-ipsec@lists.tislabs.com Thu Nov 29 11:52:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATJqI816981; Thu, 29 Nov 2001 11:52:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12664 Thu, 29 Nov 2001 14:05:08 -0500 (EST) To: Henry Spencer Cc: IPsec WG Subject: Re: On shared keys References: From: Derek Atkins Date: 29 Nov 2001 14:14:12 -0500 In-Reply-To: Henry Spencer's message of "Thu, 29 Nov 2001 12:10:35 -0500 (EST)" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > > Do I even need to mention the insecurity of generating an RSA key from > > a short secret? Worse, do I need to mention the insecurity of both > > sides sharing a SINGLE keypair? > > In what way is it worse than old-style shared secrets? *That* is the > crucial question. It may be easier to break the RSA key if it's generated with a 'weakly-seeded' PRNG than if the 'weak seed' is used directly. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Nov 29 12:00:55 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATK0t817321; Thu, 29 Nov 2001 12:00:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12675 Thu, 29 Nov 2001 14:06:45 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <29B5A21C13C8D51190F900805F65B4EC39EFD0@rndex50.ottawa.mitel.com> References: <29B5A21C13C8D51190F900805F65B4EC39EFD0@rndex50.ottawa.mitel.com> Date: Thu, 29 Nov 2001 14:08:07 -0500 To: "Dilkie, Lee" From: Stephen Kent Subject: RE: CBC makes Implementations too Slow. Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:53 AM -0500 11/29/01, Dilkie, Lee wrote: >I'm not sure if using a packet counter for an IV is bad. It's just >that you can't wrap. It's important that the same key/IV combination >not get reused. I don't believe that the requirement for a random IV >is necessary. The reason I point this out is that the secure RTP >spec uses an implicit IV (to save on >transmitting extra data) which is based on information in the RTP >header (and really is just a packet counter under the covers). > >Lee Dilkie > >Mitel Networks >350 Legget Drive >Kanata, ON, Canada >K2K 2W7 The FIPS that defines CBC mode calls for the IV to be random or pseudo random. We explicitly discussed and rejected an implicit IV based on a value such as you cite for secure RTP. I don't know who decided that the approach they used was good, but I know what this WG has discussed previously and what the relevant crypto standards say. Steve From owner-ipsec@lists.tislabs.com Thu Nov 29 12:04:29 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATK4T817458; Thu, 29 Nov 2001 12:04:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12708 Thu, 29 Nov 2001 14:14:20 -0500 (EST) Message-ID: <80B684C5E29FD211AA8000A0C9CDD9190A6EF575@il0015exch005u.ih.lucent.com> From: "Kopeikin, Roy A (Roy)" To: Sara Bitan , "sami.vaarala" , David Wagner Cc: "'Steven M. Bellovin'" , alexey.vyskubov@nokia.com, ipsec@lists.tislabs.com, "Hallam-Baker, Phillip" Subject: RE: Just Fast Keying (JFK) draft Date: Thu, 29 Nov 2001 13:23:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sara, For IPsec to be more widely used some changes to IKE are probably justified. Perhaps we can resolve this by picking out the best parts of the current proposals, considering: - JFK re-keying algorithmn - advantage or not of SIGMA 2-way vs 3-way handshake - review JFK vs IKEv2 proposals for SA policy management and distribution Roy -----Original Message----- From: Sara Bitan [mailto:sarab@cs.Technion.AC.IL] Sent: Thursday, November 29, 2001 10:42 AM To: sami.vaarala; David Wagner Cc: 'Steven M. Bellovin'; alexey.vyskubov@nokia.com; ipsec@lists.tislabs.com; Hallam-Baker, Phillip Subject: Re: Just Fast Keying (JFK) draft Sami! I agree with you. We have to compare two fully specified protocol to find out if one of them is _significantly_ simpler then the other. David! You said that "IKE has always scared me with its complexity, so I am warmly supportive of simplification efforts in this area. " Did you look at IKEv2, or at IKE-SIGMA? Both drafts suggest major changes to IKEv1, and I think they are both considerably less complex. What do you think? As a person who invested a lot in IKE implementation and interoperability till we brought IKEv1 to its maturity, I think we should make sure that a totally new key management protocol will be either _significantly_ more secure, or _significantly_ simpler, or answers requirements that are not answered by the two proposals to a new version of IKE. Before we launch this new adventure of inventing, implementing and bringing a new key management to its maturity (it took us five years last time we did it - yes I know you'll say that IKEv1 is complex;-) ) we must have very good reasons to do it, and I don't think we have them, Sara. ----- Original Message ----- From: sami.vaarala To: Hallam-Baker, Phillip Cc: 'Steven M. Bellovin' ; ; Sent: Wednesday, November 28, 2001 7:21 PM Subject: RE: Just Fast Keying (JFK) draft > > On Wed, 28 Nov 2001, Hallam-Baker, Phillip wrote: > > I am somewhat disappointed that there appears to have been almost no > > substantive discussion of JFK on the list. This may indicate that the > > protocol is secure, or it may indicate that nobody has been bothered to read > > it - which given the effort put into previous flames over the subject of > > keying would be somewhat disappointing. > > I read the draft, and found it very promising. However, it is difficult > to compare IKEv1/IKEv2 to JFK at this point, because JFK has not been > specified in full detail yet. (I'm referring to implementation > complexity, a security comparison should be possible.) > > To compare fairly, a wire format and a definition of the JFK "sa" > payload would be needed. In IKEv2, the SA payload and the traffic > selectors are a major cause of complexity, and thus have to be taken > into account when comparing the two proposals. > > -Sami > From owner-ipsec@lists.tislabs.com Thu Nov 29 12:14:09 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATKE8818385; Thu, 29 Nov 2001 12:14:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12743 Thu, 29 Nov 2001 14:22:13 -0500 (EST) Date: Thu, 29 Nov 2001 21:30:57 +0200 From: Sara Bitan Subject: Re: Just Fast Keying (JFK) draft To: "Kopeikin, Roy A (Roy)" , "sami.vaarala" , David Wagner Cc: "'Steven M. Bellovin'" , alexey.vyskubov@nokia.com, ipsec@lists.tislabs.com, "Hallam-Baker, Phillip" Message-id: <02fd01c1790c$5f9f7a20$3fa6003e@commagine.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailer: Microsoft Outlook Express 5.00.2314.1300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <80B684C5E29FD211AA8000A0C9CDD9190A6EF575@il0015exch005u.ih.lucent.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Roy! I agree that changes to IKE not just justified but essential! The difference between IKEv2, IKE-SIGMA and JFG is that the first two enable IKE code re-use, while JFK doesn't! Sara ----- Original Message ----- From: Kopeikin, Roy A (Roy) To: Sara Bitan ; sami.vaarala ; David Wagner Cc: 'Steven M. Bellovin' ; ; ; Hallam-Baker, Phillip Sent: Thursday, November 29, 2001 9:23 PM Subject: RE: Just Fast Keying (JFK) draft > Sara, > For IPsec to be more widely used some changes to IKE are probably justified. > Perhaps we can resolve this by picking out the best parts of the current > proposals, considering: > - JFK re-keying algorithmn > - advantage or not of SIGMA 2-way vs 3-way handshake > - review JFK vs IKEv2 proposals for SA policy management and distribution > > Roy > > -----Original Message----- > From: Sara Bitan [mailto:sarab@cs.Technion.AC.IL] > Sent: Thursday, November 29, 2001 10:42 AM > To: sami.vaarala; David Wagner > Cc: 'Steven M. Bellovin'; alexey.vyskubov@nokia.com; > ipsec@lists.tislabs.com; Hallam-Baker, Phillip > Subject: Re: Just Fast Keying (JFK) draft > > > Sami! > I agree with you. We have to compare two fully specified protocol to find > out if one of them is _significantly_ simpler then the other. > > David! > You said that "IKE has always scared me with its complexity, so I am warmly > supportive of > simplification efforts in this area. " Did you look at IKEv2, or at > IKE-SIGMA? > Both drafts suggest major changes to IKEv1, and I think they are both > considerably less complex. What do you think? > > As a person who invested a lot in IKE implementation and interoperability > till we brought IKEv1 to its maturity, I think we should make sure that a > totally new key management protocol will be either > _significantly_ more secure, or > _significantly_ simpler, or > answers requirements that are not answered by the two proposals to a new > version of IKE. > > Before we launch this new adventure of inventing, implementing and bringing > a new key management to its maturity (it took us five years last time we did > it - yes I know you'll say that IKEv1 is complex;-) ) we must have very good > reasons to do it, and I don't think we have them, > > Sara. > > > > ----- Original Message ----- > From: sami.vaarala > To: Hallam-Baker, Phillip > Cc: 'Steven M. Bellovin' ; > ; > Sent: Wednesday, November 28, 2001 7:21 PM > Subject: RE: Just Fast Keying (JFK) draft > > > > > > On Wed, 28 Nov 2001, Hallam-Baker, Phillip wrote: > > > I am somewhat disappointed that there appears to have been almost no > > > substantive discussion of JFK on the list. This may indicate that the > > > protocol is secure, or it may indicate that nobody has been bothered to > read > > > it - which given the effort put into previous flames over the subject > of > > > keying would be somewhat disappointing. > > > > I read the draft, and found it very promising. However, it is difficult > > to compare IKEv1/IKEv2 to JFK at this point, because JFK has not been > > specified in full detail yet. (I'm referring to implementation > > complexity, a security comparison should be possible.) > > > > To compare fairly, a wire format and a definition of the JFK "sa" > > payload would be needed. In IKEv2, the SA payload and the traffic > > selectors are a major cause of complexity, and thus have to be taken > > into account when comparing the two proposals. > > > > -Sami > > From owner-ipsec@lists.tislabs.com Thu Nov 29 12:30:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATKUO819772; Thu, 29 Nov 2001 12:30:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA12773 Thu, 29 Nov 2001 14:38:03 -0500 (EST) Date: Thu, 29 Nov 2001 21:48:04 +0200 (Israel Standard Time) From: Arne Ansper To: IPsec WG Subject: Re: On shared keys In-Reply-To: Message-ID: X-X-Sender: arne@kiku.itsise MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-info: Headers changed by Barricade Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > In essence, you take the pre-shared secret, create a PRNG out of > the secret using a hash function, and then use a determining > RSA keypair generator to create the keypair. Both communicating > hosts use the same pre-shared secret, and thus end up with the > same RSA keypair. in order to end up with the same RSA key on both sides you must standardize both PRNG and RSA keypair generator. and if one of the implementations improves it's primality checks then you might have interoprability problems. arne From owner-ipsec@lists.tislabs.com Thu Nov 29 12:50:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATKoP821114; Thu, 29 Nov 2001 12:50:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA12911 Thu, 29 Nov 2001 15:05:49 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Henry Spencer" Cc: "IPsec WG" Subject: Re: On shared keys References: From: "Derek Atkins" Date: 29 Nov 2001 14:14:12 -0500 In-Reply-To: Henry Spencer's message of "Thu, 29 Nov 2001 12:10:35 -0500 (EST)" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 29 Nov 2001 20:06:39.0656 (UTC) FILETIME=[5B518A80:01C17911] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer writes: > > Do I even need to mention the insecurity of generating an RSA key from > > a short secret? Worse, do I need to mention the insecurity of both > > sides sharing a SINGLE keypair? > > In what way is it worse than old-style shared secrets? *That* is the > crucial question. It may be easier to break the RSA key if it's generated with a 'weakly-seeded' PRNG than if the 'weak seed' is used directly. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Thu Nov 29 14:24:24 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATMOO824446; Thu, 29 Nov 2001 14:24:24 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13078 Thu, 29 Nov 2001 16:30:15 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188467@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Ricky Charlet'" Cc: IPsec WG Subject: RE: On shared keys Date: Thu, 29 Nov 2001 21:37:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree with Ricky's view. In my opinion, PSK based authentication method need to exist for a good reason from the deployment point of view also: Although IPsec tunnels can be set up manually, manual deployment doesn't scale well, especially when PSK is used. However, more and more VPN service providers are offering managed VPN service. When both ends of an IPsec tunnel are under the same management, PSK generation and deployment is not a complex task. There is no scalability issues when the PSK is created and tracked by management tools on a per-tunnel basis. On the contrary, using PSK actually simplifies the VPN deployment requirement by eliminating the need of establishing and maintaining a complex PKI system. -----Original Message----- From: Ricky Charlet [mailto:rcharlet@redcreek.com] Sent: Tuesday, November 27, 2001 2:37 PM Cc: IPsec WG Subject: Re: On shared keys Hugo Krawczyk wrote: > > Everyone agrees that public key is the ONLY way to a scalable > Internet-wide protocol. No question about it. In particular, any > key-exchange protocol for IPsec MUST provide a PK-based exchange. I agree that, in theory, a PK based system should scale further than a PSK based system. But in practice, we live in a world where PSK based authentication methods have been made to scale to an entirely sufficient degree by almost every corporation. The advantages of scaling further yet seems pretty dim in most of their eyes when compared to the cost of re-tooling their credential handling. The set of organizations who need greater scalability than PSKs is small (but non-ignorable). The set of organizations who currently have working infrastructures to support PSK authentications is large. So, do we need a PSK authentication method as well as a PK authentication method? Each of the three next generation IKE replacement drafts dropped support for PSK authentication specifically in the interest of protocol simplicity. This is a laudable goal and should not be lightly dismissed. Simplicity increases both interoperability and security. Some have argued that we need a PSK authentication method because it is easy to test. This argument does not overcome the arguments in favor of protocol simplicity in my view. But, I would like to make the point (as others have) that a PSK authentication system which can easily interact with popular back-end authentication servers and will not tie the peers down to pre-configured, known IP addresses would be a highly usable and popular protocol as it would conviently address a great need. IMHO, such an authentication method is in more demand than a PK authentication method even though the PK authentication could scale larger. Next generation IKEers have all set about the goals of reducing complexity and setup cost. But I would also request (and here starts a new war) that the authors of IKE replacement protocols also consider taking on the goals set forth in the ipsra WG (draft-ietf-ipsra-reqmts-04.txt) but with the ability to 'change IKE'. I think that we should do a PSK authentication method because it would be useful. -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." Benjamin Franklin Ricky Charlet : SonicWall Inc. : usa (510) 497-2103 From owner-ipsec@lists.tislabs.com Thu Nov 29 14:24:25 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATMOO824454; Thu, 29 Nov 2001 14:24:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA13065 Thu, 29 Nov 2001 16:25:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.3.32.20011127092421.00f70cd0@mail> References: <3.0.3.32.20011127092421.00f70cd0@mail> Date: Thu, 29 Nov 2001 16:25:39 -0500 To: Alex Alten From: Stephen Kent Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Cc: IPsec WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:24 AM -0800 11/27/01, Alex Alten wrote: >At 01:34 AM 11/27/2001 +0200, Hugo Krawczyk wrote: >>Everyone agrees that public key is the ONLY way to a scalable >>Internet-wide protocol. No question about it. In particular, >>any key-exchange protocol for IPsec MUST provide a PK-based exchange. >> > >No. I STRONGLY disagree. I'll give a counter example. The banking >ATM network uses DES keys. It has scaled, in practice, world wide. > >And BTW, it's security & trust model is excellent. Have you ever heard >of a major compromise, say on the scale of 25,000 card #'s being stolen >(like with Visa?). Certainly nobody distrusts it because it uses >symmetric keys for authentication. In fact I'm certain YOU trust it >at least a couple a times a month. :-) > >- Alex Alex, There are multiple ATM networks, not one. They operate separately, with a small number of well-defined interconnects. My recollection (from a few years ago) is that DES Keys are used for ATM to bank communication, to generate and check a MAC on each transaction. The key is pairwise, between each ATM and the bank (or network) that operates it, and is managed by that bank (or network), which is a relatively easy thing to do because it is all in one administrative domain. DES keys also are used for inter-bank (or inter-ATM net) communication, to securely relay the MAC of the transaction (with the PIN XORed into it) between banks (or between an ATM net and a bank), when you use your card at an ATM that is not owned by the bank that issued it. This too is a pairwise shared key (that probably is not changed very often), although it is a bit harder to distribute in that it crosses an administrative boundary (analogous to Kerberos inter-realm keys). The point is that the ATM example is not very representative of general Internet communication. The number of ATMs per bank is small for small banks, large for large banks, and the there are bank-independent ATM nets. When your bank says it is part of Cirrus or some other ATM net, what that means is that there is a key shared between your bank and a "gateway" for the net, to allow inter-bank communication, not that there are keys to allow direct communication between that ATM and every bank belonging to the ATM net in question. So, although there are lots of ATMs out there, and lots of banks, the communication paths are restrictive and that makes key management much easier. Steve P.S. I'm sure Lynn will correct any errors in my possibly oversimplified (may out of date) description. From owner-ipsec@lists.tislabs.com Thu Nov 29 16:05:05 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU055829961; Thu, 29 Nov 2001 16:05:05 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13229 Thu, 29 Nov 2001 18:05:54 -0500 (EST) Message-Id: <4.3.2.7.2.20011129151200.0435a390@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Nov 2001 15:13:08 -0800 To: ipsec@lists.tislabs.com From: Mark Baugher Subject: RE: CBC makes Implementations too Slow. In-Reply-To: References: < <29B5A21C13C8D51190F900805F65B4EC39EFD0@rndex50.ottawa.mitel.com> <29B5A21C13C8D51190F900805F65B4EC39EFD0@rndex50.ottawa.mitel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk SRTP's implicit IV is for counter mode, not cbc. Mark At 02:08 PM 11/29/2001 -0500, Stephen Kent wrote: >At 10:53 AM -0500 11/29/01, Dilkie, Lee wrote: >>I'm not sure if using a packet counter for an IV is bad. It's just that >>you can't wrap. It's important that the same key/IV combination not get >>reused. I don't believe that the requirement for a random IV is >>necessary. The reason I point this out is that the secure RTP spec >> uses an implicit IV (to save on transmitting >>extra data) which is based on information in the RTP header (and really >>is just a packet counter under the covers). >> >>Lee Dilkie >> >>Mitel Networks >>350 Legget Drive >>Kanata, ON, Canada >>K2K 2W7 > > >The FIPS that defines CBC mode calls for the IV to be random or pseudo >random. We explicitly discussed and rejected an implicit IV based on a >value such as you cite for secure RTP. I don't know who decided that the >approach they used was good, but I know what this WG has discussed >previously and what the relevant crypto standards say. > >Steve From owner-ipsec@lists.tislabs.com Thu Nov 29 16:08:28 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU08S800135; Thu, 29 Nov 2001 16:08:28 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA13279 Thu, 29 Nov 2001 18:23:21 -0500 (EST) Message-ID: <002601c1792e$06230760$cace1dd5@mahdavi> From: "mahdavi" To: "ipsec" References: <20011031005533.B51867C01@berkshire.research.att.com> <15366.18464.416439.388616@pkoning.dev.equallogic.com> Subject: Re: CBC makes Implementations too Slow. Date: Fri, 30 Nov 2001 02:56:40 +0330 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi. And other way to encrease speed and also not to loose security and also not to pay for Overhead is to generate a random number for IV to use with first block and generate other IVs for other Blocks based on this IV and number of block. I mean this. (P satnds for Plain block, C stands for Ciphered Block, F is a function, S is Security function.) IV ( 0 ) = a random number; C ( 0 ) = S ( P(0) , IV ( 0 ) ) ; // may be S P (0) XOR IV ( 0 ) for i from 0 till end of Block IV ( i ) = F ( IV ( i - 1 ) ) ; C ( i ) = S ( P ( i ) , IV ( i ) ) ; // may be S ( P (0) XOR IV ( 0 ) If F be a right function that is known with both end node and be simple that can be generated as fast we will gain all option that I mentioned. In this way a very Efficient pipeline can be made. ----- Original Message ----- From: "Paul Koning" To: Cc: Sent: Thursday, November 29, 2001 6:07 PM Subject: Re: CBC makes Implementations too Slow. > >>>>> "Michael" == Michael Cyr writes: > > Michael> On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > >> CBC mode requires feedback, which makes it impossible to pipeline > >> encryptions; you can't encrypt plaintext block P[n+1] until you > >> have the ciphertext from encrypting P[n]. > > Michael> I know this discussion was a while ago, but I have a > Michael> question related to the problem. First, let me say that I'm > Michael> new to the list, and still somewhat new to IPsec in general, > Michael> so I hope you'll forgive any ignorance on my part. > > Michael> Would it be a complete violation of the protocol to use > Michael> random data for the IV data instead of a portion of the > Michael> ciphertext of the previous block? I know this violates the > Michael> spirit of cipher block _chaining_, but it would seem to > Michael> address the concern that CBC was meant to fix, which is to > Michael> ensure that if the same cleartext is encrypted twice, it > Michael> doesn't produce the same ciphertext. Anyone have a > Michael> definitive answer on this? > > My reading of the spec is that this is perfectly legal. The one thing > you're not supposed to do is to use a low entropy IV value, such as a > packet counter. > > That doesn't fix the performance problem for a single packet, though. > You can do each packet independently if you use a random IV, but each > plaintext block *within* the packet is still dependent on the previous > block. > > On the other hand, using independent IVs per packet provides a useful > gain if you have a number of packets pending (for the same SA) -- you > can then encrypt them in parallel. In high load cases you will almost > certainly have multiple packets waiting to be processed, so this > should indeed give you a significant performance gain. > > paul _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ipsec@lists.tislabs.com Thu Nov 29 19:39:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU3d0804470; Thu, 29 Nov 2001 19:39:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA13489 Thu, 29 Nov 2001 21:31:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message Subject: RE: IP Storage and IPsec encapsulation Date: Thu, 29 Nov 2001 18:39:19 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IP Storage and IPsec encapsulation thread-index: AcF49th/4UY3rX2uSOe5rknaplDnxgATrr3Q From: "William Dixon" To: "Stephen Kent" , Cc: , X-OriginalArrivalTime: 30 Nov 2001 02:39:20.0192 (UTC) FILETIME=[367E0800:01C17948] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require a transport layer interface definition for using IPSec security - in the iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port connection, deal with the binding of the authentication credential to the traffic in the SA, allow/disallow iSCSI awareness of IKE SA credentials, and IKE QM/IPSec SA state, and deal with the programmatic policy addition to an otherwise admin defined SPD. Practically, shipping products that use IKE and IPSec in either mode for TCP connection security means a well defined "policy" so that client (iSCSI initiator) and server (iSCSI target) side products interoperate with just credentials configured properly, ala web-based usage of SSL/TLS. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, November 29, 2001 8:40 AM To: Black_David@emc.com Cc: ipsec@lists.tislabs.com; saag@mit.edu Subject: Re: IP Storage and IPsec encapsulation David, I'm trying to make my way through over 1K messages (that's what I get for going on a week vacation when new IPsec IDs come out ...) and so I didn't read all of your messages in order. Looking back at your original (?) message about use of tunnel vs. transport mode I agree with you that this should not be a problem for iSCSI use of IPsec, from a standards perspective. As you note, people need to be smart in configuring an external IPsec device (or set of devices) to ensure that, within their context, the desired security properties are achieved. Thus, merely because tunnel mode could be terminated at a point which would undermine security, in general, that does not mean that its use should be avoided in your spec, for the reasons you cite. My previous message also noted that the outboard IPsec device could be a bump in the wire, vs. an SG, which would allow both transport and tunnel mode, but this is a minor difference relative to your bugger question. As you noted, it is a local security policy (and architecture) issue where the IPsec devices are placed and whether that placement provides adequate security. Steve From owner-ipsec@lists.tislabs.com Thu Nov 29 20:48:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU4mt805729; Thu, 29 Nov 2001 20:48:55 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA13585 Thu, 29 Nov 2001 22:59:35 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Class: urn:content-classes:message Subject: RE: IP Storage and IPsec encapsulation Date: Thu, 29 Nov 2001 18:39:19 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: IP Storage and IPsec encapsulation thread-index: AcF49th/4UY3rX2uSOe5rknaplDnxgATrr3Q From: "William Dixon" To: "Stephen Kent" , Cc: , X-OriginalArrivalTime: 30 Nov 2001 02:39:20.0192 (UTC) FILETIME=[367E0800:01C17948] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require a transport layer interface definition for using IPSec security - in the iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port connection, deal with the binding of the authentication credential to the traffic in the SA, allow/disallow iSCSI awareness of IKE SA credentials, and IKE QM/IPSec SA state, and deal with the programmatic policy addition to an otherwise admin defined SPD. Practically, shipping products that use IKE and IPSec in either mode for TCP connection security means a well defined "policy" so that client (iSCSI initiator) and server (iSCSI target) side products interoperate with just credentials configured properly, ala web-based usage of SSL/TLS. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, November 29, 2001 8:40 AM To: Black_David@emc.com Cc: ipsec@lists.tislabs.com; saag@mit.edu Subject: Re: IP Storage and IPsec encapsulation David, I'm trying to make my way through over 1K messages (that's what I get for going on a week vacation when new IPsec IDs come out ...) and so I didn't read all of your messages in order. Looking back at your original (?) message about use of tunnel vs. transport mode I agree with you that this should not be a problem for iSCSI use of IPsec, from a standards perspective. As you note, people need to be smart in configuring an external IPsec device (or set of devices) to ensure that, within their context, the desired security properties are achieved. Thus, merely because tunnel mode could be terminated at a point which would undermine security, in general, that does not mean that its use should be avoided in your spec, for the reasons you cite. My previous message also noted that the outboard IPsec device could be a bump in the wire, vs. an SG, which would allow both transport and tunnel mode, but this is a minor difference relative to your bugger question. As you noted, it is a local security policy (and architecture) issue where the IPsec devices are placed and whether that placement provides adequate security. Steve From owner-ipsec@lists.tislabs.com Fri Nov 30 00:24:19 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU8OI823720; Fri, 30 Nov 2001 00:24:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA13884 Fri, 30 Nov 2001 02:26:22 -0500 (EST) Date: Thu, 29 Nov 2001 23:24:24 -0800 (PST) From: Bernard Aboba To: William Dixon cc: Stephen Kent , Black_David@emc.com, ipsec@lists.tislabs.com, saag@mit.edu Subject: Re: [saag] RE: IP Storage and IPsec encapsulation In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC102EE68FA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk To add a bit to the debate, one has to consider not only the impact of the tunnel vs. transport decision itself, but also the other implications. For example, while iFCP and FCIP endpoints are typically statically addressed, iSCSI initiators are often hosts with dynamically assigned addresses. Therefore if tunnel mode is used with iSCSI, there is a need to dynamically configure the tunnel parameters, including IP address, configuration, etc. There is some additional complexity required as a result, and also some potential pitfalls, since most tunnel mode gateways don't yet implement the IPSRA WG recommendation for tunnel mode config, draft-ietf-ipsec-dhcp-13.txt. I'd hate to see us do a lot of work to specify how IPsec tunnel mode would be used to secure iSCSI only to find that the implementations won't interoperate because they were using various proprietary tunnel mode authentication and configuration extensions. Been there, done that ;) On Thu, 29 Nov 2001, William Dixon wrote: > Steve, Ran, this seems to again (L2TP UDP 1701 being the first) require > a transport layer interface definition for using IPSec security - in the > iSCSI case: how to use IKE and IPSec to secure a TCP src port, dst port > connection, deal with the binding of the authentication credential to > the traffic in the SA, allow/disallow iSCSI awareness of IKE SA > credentials, and IKE QM/IPSec SA state, and deal with the programmatic > policy addition to an otherwise admin defined SPD. > > Practically, shipping products that use IKE and IPSec in either mode for > TCP connection security means a well defined "policy" so that client > (iSCSI initiator) and server (iSCSI target) side products interoperate > with just credentials configured properly, ala web-based usage of > SSL/TLS. > > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Thursday, November 29, 2001 8:40 AM > To: Black_David@emc.com > Cc: ipsec@lists.tislabs.com; saag@mit.edu > Subject: Re: IP Storage and IPsec encapsulation > > > David, > > I'm trying to make my way through over 1K messages (that's what I get > for going on a week vacation when new IPsec IDs come out ...) and so > I didn't read all of your messages in order. > > Looking back at your original (?) message about use of tunnel vs. > transport mode I agree with you that this should not be a problem for > iSCSI use of IPsec, from a standards perspective. As you note, people > need to be smart in configuring an external IPsec device (or set of > devices) to ensure that, within their context, the desired security > properties are achieved. Thus, merely because tunnel mode could be > terminated at a point which would undermine security, in general, > that does not mean that its use should be avoided in your spec, for > the reasons you cite. My previous message also noted that the > outboard IPsec device could be a bump in the wire, vs. an SG, which > would allow both transport and tunnel mode, but this is a minor > difference relative to your bugger question. > > As you noted, it is a local security policy (and architecture) issue > where the IPsec devices are placed and whether that placement > provides adequate security. > > Steve > > _______________________________________________ > saag mailing list > saag@mit.edu > http://jis.mit.edu/mailman/listinfo/saag > From owner-ipsec@lists.tislabs.com Fri Nov 30 01:12:21 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU9CL829173; Fri, 30 Nov 2001 01:12:21 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA13992 Fri, 30 Nov 2001 03:32:46 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Fri, 30 Nov 2001 00:49:48 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: Arne Ansper cc: IPsec WG Subject: Re: On shared keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 29 Nov 2001, Arne Ansper wrote: > > In essence, you take the pre-shared secret, create a PRNG out of > > the secret using a hash function, and then use a determining > > RSA keypair generator to create the keypair. Both communicating > > hosts use the same pre-shared secret, and thus end up with the > > same RSA keypair. > > in order to end up with the same RSA key on both sides you must > standardize both PRNG and RSA keypair generator. and if one of the > implementations improves it's primality checks then you might have > interoprability problems. Again, I'm not a cryptographer. Still, I've had the impression that primality checking is not the problem here: even probabilistic algorithms have such an astronomically small chance of mistaking a composite for a prime that I wouldn't worry about it. I think the bigger problem are the criteria for what kind of primes to generate -- the sizes of the primes, and whether primes of some special form are to be used. Once these criteria are set in the algorithm, they cannot be changed without breaking interoperability. The other big issue would be the quality of the PRNG. How good does it have to be for this application? Still, I think it would be possible to agree on these two issues, and end up with a workable solution. -Sami From owner-ipsec@lists.tislabs.com Fri Nov 30 01:12:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU9Cj829189; Fri, 30 Nov 2001 01:12:45 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA13980 Fri, 30 Nov 2001 03:26:26 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Fri, 30 Nov 2001 00:42:54 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: Derek Atkins cc: Henry Spencer , IPsec WG Subject: Re: On shared keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 29 Nov 2001, Derek Atkins wrote: > Henry Spencer writes: > > In what way is it worse than old-style shared secrets? *That* is the > > crucial question. > > It may be easier to break the RSA key if it's generated with a > 'weakly-seeded' PRNG than if the 'weak seed' is used directly. I'm not a cryptographist -- can you explain to me why? I would expect the RSA keypair to be weaker if the pre-shared key had more entropy than the resulting RSA key. But is this the case with the average PSK? -Sami From owner-ipsec@lists.tislabs.com Fri Nov 30 02:50:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUAnx810680; Fri, 30 Nov 2001 02:49:59 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA14170 Fri, 30 Nov 2001 05:06:35 -0500 (EST) Message-Id: <3.0.3.32.20011130021842.00db66d8@mail> X-Sender: alten@mail X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 30 Nov 2001 02:18:42 -0800 To: "Dilkie, Lee" , andrew.krywaniuk@alcatel.com, "'IPsec WG'" From: Alex Alten Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) In-Reply-To: <29B5A21C13C8D51190F900805F65B4EC39EFC8@rndex50.ottawa.mite l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 05:16 PM 11/28/2001 -0500, Dilkie, Lee wrote: >Alex, > >With all due respect, I think the ATM network is a great example of why PSK > (symmetric kind) security is an expensive and non scalable solution. > Mr. Lee Dilkie, Unfortunately I don't have time to counter all your points due to an upcoming deadline. Nor will I have time to follow this thread in near real-time for a while. I will re-iterate my position. If a network security system is properly designed then either Public Key or Symmetric/Private Key cryptography will work fine in establishing trust. I furthermore claim that Symmetric/Private Key cryptography will scale to great numbers of users and I use the bank ATM secure network using DES as an excellent example. To prove this point beyond any reasonable doubt I suggest that you go read the US patents underlying the ATM security system. In particular, US Patent # 4,268,715 "Method and Apparatus for Securing Data Transmissions" is probably the core patent. You can look at whatever patents cite it or are cited by it to discover related patents dealing with secure enrollment of users, detecting forged cards, etc. As far as I'm concerned this should be the end of the discussion about whether or not Symmetric/Private Key cryptography can scale to large numbers of users in an efficient, easy to use by ordinary people, inexpensive to implement manner and interoperable between devices made by different manufacturers and maintained by different organizations. It has been done for the past 20 years by what is probably the most successful world-wide commercial networked security system. Anyone who still claims that Public Key is superior to Symmetric/Private Key cryptography, or that it is the only way to scale, is a *damn fool* and should be treated as such. Good Night, - Alex Alten -- Alex Alten Alten@Home.Com From owner-ipsec@lists.tislabs.com Fri Nov 30 05:47:35 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUDlY824339; Fri, 30 Nov 2001 05:47:35 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA14419 Fri, 30 Nov 2001 07:45:38 -0500 (EST) From: "David A. Mcgrew" To: "Mark Baugher" , Subject: RE: CBC makes Implementations too Slow. Date: Fri, 30 Nov 2001 05:01:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20011129151200.0435a390@mira-sjc5-6.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, Mark Baugher wrote: > SRTP's implicit IV is for counter mode, not cbc. thanks for pointing this out and calling it to my attention. I'd also like to point out that the ID http://search.ietf.org/internet-drafts/draft-mcgrew-saag-icm-00.txt includes a specification and test vectors for a definition of counter mode that works for both SRTP and ESP. David > > Mark > At 02:08 PM 11/29/2001 -0500, Stephen Kent wrote: > >At 10:53 AM -0500 11/29/01, Dilkie, Lee wrote: > >>I'm not sure if using a packet counter for an IV is bad. It's just that > >>you can't wrap. It's important that the same key/IV combination not get > >>reused. I don't believe that the requirement for a random IV is > >>necessary. The reason I point this out is that the secure RTP spec > >> uses an implicit IV (to save on > transmitting > >>extra data) which is based on information in the RTP header (and really > >>is just a packet counter under the covers). > >> > >>Lee Dilkie > >> > >>Mitel Networks > >>350 Legget Drive > >>Kanata, ON, Canada > >>K2K 2W7 > > > > > >The FIPS that defines CBC mode calls for the IV to be random or pseudo > >random. We explicitly discussed and rejected an implicit IV based on a > >value such as you cite for secure RTP. I don't know who decided > that the > >approach they used was good, but I know what this WG has discussed > >previously and what the relevant crypto standards say. > > > >Steve > From owner-ipsec@lists.tislabs.com Fri Nov 30 07:11:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUFBt829995; Fri, 30 Nov 2001 07:11:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14517 Fri, 30 Nov 2001 09:13:55 -0500 (EST) To: Sami Vaarala Cc: Henry Spencer , IPsec WG Subject: Re: On shared keys References: From: Derek Atkins Date: 30 Nov 2001 09:22:40 -0500 In-Reply-To: Sami Vaarala's message of "Fri, 30 Nov 2001 00:42:54 +0200 (EET)" Message-ID: Lines: 63 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sami Vaarala writes: > On 29 Nov 2001, Derek Atkins wrote: > > Henry Spencer writes: > > > In what way is it worse than old-style shared secrets? *That* is the > > > crucial question. > > > > It may be easier to break the RSA key if it's generated with a > > 'weakly-seeded' PRNG than if the 'weak seed' is used directly. > > I'm not a cryptographist -- can you explain to me why? > I would expect the RSA keypair to be weaker if the > pre-shared key had more entropy than the resulting > RSA key. But is this the case with the average PSK? First, the term is "cryptographer".... Second, please be explicit when you use the term PSK (Pre-Shared Key), are you talking about a Pre-Shared Secret Key or a Pre-Shared Public Key? Please be explicit, as many of us are arguing that Pre-Shared Public Keys are sufficient. Third, I can try to explain it. An average RSA key is 1024-2048 bits long. This implies you really need about 1024-2048 bits of entropy (note that you actually have less that that, because you always know that the first and last bits are 1, and you know the number has a particular form, but for brevity of this explanation let's call it the full length even though it may be a few bits less). An average shared secret maybe has 50 bits of entropy, if you're lucky. The problem is that if you generate an RSA key (requiring 1024-2048 bits of entropy) from a source that only has 50 bits of entropy, your RSA key effectively has only 50 bits of entropy in it. This implies that on average only one in every 20-40 bits is truly random (the others wind up depending on the values of the random bits). This implies that there is a lot of redundant, non-random information in the public key which can make breaking the key much easier. Considering the key-generation mechanism must be well-known, it means that you have an easier time determining which bits are the random ones, which ones are not, and how they relate to each other. To give a real-world example, a long time ago in a galaxy not so far away, a Public-Key generator had this code: char c = get_random_byte(); for (i = 0; i < key_length; i++) key_buf[i] = c; key_pair = generate_key_from_key_buf(key_buf); What you are suggesting is almost (but not quite) as disastrous as this completely broken pseudo-code. I hope this helps explain it. > -Sami -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 07:29:38 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUFTc801327; Fri, 30 Nov 2001 07:29:38 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14579 Fri, 30 Nov 2001 09:40:59 -0500 (EST) To: "mahdavi" Cc: "ipsec" Subject: Re: CBC makes Implementations too Slow. References: <20011031005533.B51867C01@berkshire.research.att.com> <15366.18464.416439.388616@pkoning.dev.equallogic.com> <002601c1792e$06230760$cace1dd5@mahdavi> From: Derek Atkins Date: 30 Nov 2001 09:50:32 -0500 In-Reply-To: "mahdavi"'s message of "Fri, 30 Nov 2001 02:56:40 +0330" Message-ID: Lines: 95 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem with this "mode" is that your plaintext/ciphertext has no relation to your IV. It means there really is no chaining going on, except via 'F' which may or may not provide as much security as 'S'. Moreover, the IV chaining you propose depends on neither P nor K, which some may consider a bug. -derek "mahdavi" writes: > Hi. > And other way to encrease speed and also not to loose security and also not > to pay for Overhead is to generate a random number for IV to use with first > block and generate other IVs for other Blocks based on this IV and number of > block. > > I mean this. > > (P satnds for Plain block, C stands for Ciphered Block, F is a function, S > is Security function.) > > > IV ( 0 ) = a random number; C ( 0 ) = S ( P(0) , IV ( 0 ) ) ; // may be S > P (0) XOR IV ( 0 ) > > for i from 0 till end of Block > IV ( i ) = F ( IV ( i - 1 ) ) ; C ( i ) = S ( P ( i ) , IV ( i ) ) ; // > may be S ( P (0) XOR IV ( 0 ) > > > If F be a right function that is known with both end node and be simple that > can be generated as fast we will gain all option that I mentioned. > > In this way a very Efficient pipeline can be made. > > > > ----- Original Message ----- > From: "Paul Koning" > To: > Cc: > Sent: Thursday, November 29, 2001 6:07 PM > Subject: Re: CBC makes Implementations too Slow. > > > > >>>>> "Michael" == Michael Cyr writes: > > > > Michael> On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > > >> CBC mode requires feedback, which makes it impossible to pipeline > > >> encryptions; you can't encrypt plaintext block P[n+1] until you > > >> have the ciphertext from encrypting P[n]. > > > > Michael> I know this discussion was a while ago, but I have a > > Michael> question related to the problem. First, let me say that I'm > > Michael> new to the list, and still somewhat new to IPsec in general, > > Michael> so I hope you'll forgive any ignorance on my part. > > > > Michael> Would it be a complete violation of the protocol to use > > Michael> random data for the IV data instead of a portion of the > > Michael> ciphertext of the previous block? I know this violates the > > Michael> spirit of cipher block _chaining_, but it would seem to > > Michael> address the concern that CBC was meant to fix, which is to > > Michael> ensure that if the same cleartext is encrypted twice, it > > Michael> doesn't produce the same ciphertext. Anyone have a > > Michael> definitive answer on this? > > > > My reading of the spec is that this is perfectly legal. The one thing > > you're not supposed to do is to use a low entropy IV value, such as a > > packet counter. > > > > That doesn't fix the performance problem for a single packet, though. > > You can do each packet independently if you use a random IV, but each > > plaintext block *within* the packet is still dependent on the previous > > block. > > > > On the other hand, using independent IVs per packet provides a useful > > gain if you have a number of packets pending (for the same SA) -- you > > can then encrypt them in parallel. In high load cases you will almost > > certainly have multiple packets waiting to be processed, so this > > should indeed give you a significant performance gain. > > > > paul > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 07:40:47 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUFek802428; Fri, 30 Nov 2001 07:40:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA14606 Fri, 30 Nov 2001 09:50:17 -0500 (EST) X-Authentication-Warning: localhost.localdomain: sami.vaarala owned process doing -bs Date: Fri, 30 Nov 2001 07:01:22 +0200 (EET) From: Sami Vaarala X-Sender: sami.vaarala@localhost.localdomain To: Derek Atkins cc: Henry Spencer , IPsec WG Subject: Re: On shared keys In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Derek, > Derek Atkins: > > First, the term is "cryptographer".... Second, please be explicit > when you use the term PSK (Pre-Shared Key), are you talking about a > Pre-Shared Secret Key or a Pre-Shared Public Key? Please be explicit, > as many of us are arguing that Pre-Shared Public Keys are sufficient. Yes, I'm talking about pre-shared secret keys (a passphrase). Pre-shared RSA keys are sufficient, I agree. Still, some people feel that pre-shared secrets are needed. > This implies that there is a lot of redundant, non-random information > in the public key which can make breaking the key much easier. > Considering the key-generation mechanism must be well-known, it means > that you have an easier time determining which bits are the random > ones, which ones are not, and how they relate to each other. Okay, so what you are saying is that the RSA keypair is easier to break than the corresponding shared secret? I.e. if the shared secret is 50 bits, the keypair is easier to break than 2^50 trials on the shared secret? (I am not suggesting that a 1024-bit RSA keypair generated from a 50-bit secret is as strong as a real 1024-bit RSA keypair -- of course not. But is it worse than a 50-bit shared secret?) Remember that the attacker would only see the RSA signature of the authenticator hash, and would *not* have access to the RSA public key (since it is generated locally at each end). > What you are suggesting is almost (but not quite) as disastrous as > this completely broken pseudo-code. > > I hope this helps explain it. I guess it's down to the details, and I'll have to look into it in more detail. -Sami From owner-ipsec@lists.tislabs.com Fri Nov 30 07:48:03 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUFm3802967; Fri, 30 Nov 2001 07:48:03 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14696 Fri, 30 Nov 2001 10:00:27 -0500 (EST) Message-ID: <3C07A170.448E1597@storm.ca> Date: Fri, 30 Nov 2001 10:10:40 -0500 From: Sandy Harris X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <3.0.3.32.20011130021842.00db66d8@mail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Alex Alten wrote: > I will re-iterate my position. If a network security system is properly > designed then either Public Key or Symmetric/Private Key cryptography > will work fine in establishing trust. So far, so good. > I furthermore claim that Symmetric/Private Key cryptography > will scale to great numbers of users Sorry, but this is nonsense. The classic problem with symmetric crypto is key management. It neither scales well nor works well across administrative boundaries. Consider n sites which all want to communicate. For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which is known to exactly two players and none of the others. Moreover, you have to communicate those keys securely to the second player in each case, and then keep it secure on both systems. With public key, you need only n key pairs. There is no need to communicate keys securely; the system is designed to work even if the enemy knows the public keys. Nor do you have to manage security for multiple keys, or keep track of who each key is shared with. You just need to keep your private key secure, not shared with anyone. Of course you can build a kerberos-like system using symmetric ciphers that has many of the advantages of public key. Using a central key server reduces the number of keys to n client-to-server keys and may simplify management. However, I doubt such a centralised model is appropriate for Internet infrastructure. > and I use the bank ATM secure network using DES as an excellent example. > ... I think that's an irrelevant example. A tightly controlled single purpose terminal-to-mainframe network under a single administrative authority bears no useful resemblanmce to the Internet. Someone gave a good detailed analysis earlier in the thread. You should re-read it. > As far as I'm concerned this should be the end of the discussion I agree, but for opposite reasons. > about whether or not Symmetric/Private Key cryptography can scale to > large numbers of users in > an efficient, easy to use by ordinary people, inexpensive to implement > manner and > interoperable between devices made by different manufacturers and > maintained by > different organizations. It has been done for the past 20 years by what is > probably the most successful world-wide commercial networked security system. > > Anyone who still claims that Public Key is superior to Symmetric/Private Key > cryptography, or that it is the only way to scale, is a *damn fool* and should > be treated as such. How about "obviously superior for some purposes, including most key distribution applications" and "almost always the best way to build scalable systems"? Methinks you'll consider me a fool. I heartily return the sentiment. From owner-ipsec@lists.tislabs.com Fri Nov 30 08:45:00 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUGix808164; Fri, 30 Nov 2001 08:45:00 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14832 Fri, 30 Nov 2001 10:31:12 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Sami Vaarala" Cc: "Henry Spencer" , "IPsec WG" Subject: Re: On shared keys References: From: "Derek Atkins" Date: 30 Nov 2001 09:22:40 -0500 In-Reply-To: Sami Vaarala's message of "Fri, 30 Nov 2001 00:42:54 +0200 (EET)" Message-ID: Lines: 63 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 30 Nov 2001 15:40:50.0781 (UTC) FILETIME=[637618D0:01C179B5] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Sami Vaarala writes: > On 29 Nov 2001, Derek Atkins wrote: > > Henry Spencer writes: > > > In what way is it worse than old-style shared secrets? *That* is the > > > crucial question. > > > > It may be easier to break the RSA key if it's generated with a > > 'weakly-seeded' PRNG than if the 'weak seed' is used directly. > > I'm not a cryptographist -- can you explain to me why? > I would expect the RSA keypair to be weaker if the > pre-shared key had more entropy than the resulting > RSA key. But is this the case with the average PSK? First, the term is "cryptographer".... Second, please be explicit when you use the term PSK (Pre-Shared Key), are you talking about a Pre-Shared Secret Key or a Pre-Shared Public Key? Please be explicit, as many of us are arguing that Pre-Shared Public Keys are sufficient. Third, I can try to explain it. An average RSA key is 1024-2048 bits long. This implies you really need about 1024-2048 bits of entropy (note that you actually have less that that, because you always know that the first and last bits are 1, and you know the number has a particular form, but for brevity of this explanation let's call it the full length even though it may be a few bits less). An average shared secret maybe has 50 bits of entropy, if you're lucky. The problem is that if you generate an RSA key (requiring 1024-2048 bits of entropy) from a source that only has 50 bits of entropy, your RSA key effectively has only 50 bits of entropy in it. This implies that on average only one in every 20-40 bits is truly random (the others wind up depending on the values of the random bits). This implies that there is a lot of redundant, non-random information in the public key which can make breaking the key much easier. Considering the key-generation mechanism must be well-known, it means that you have an easier time determining which bits are the random ones, which ones are not, and how they relate to each other. To give a real-world example, a long time ago in a galaxy not so far away, a Public-Key generator had this code: char c = get_random_byte(); for (i = 0; i < key_length; i++) key_buf[i] = c; key_pair = generate_key_from_key_buf(key_buf); What you are suggesting is almost (but not quite) as disastrous as this completely broken pseudo-code. I hope this helps explain it. > -Sami -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 08:49:30 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUGnT808390; Fri, 30 Nov 2001 08:49:29 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA14892 Fri, 30 Nov 2001 10:42:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "mahdavi" Cc: "ipsec" Subject: Re: CBC makes Implementations too Slow. References: <20011031005533.B51867C01@berkshire.research.att.com> <15366.18464.416439.388616@pkoning.dev.equallogic.com> <002601c1792e$06230760$cace1dd5@mahdavi> From: "Derek Atkins" Date: 30 Nov 2001 09:50:32 -0500 In-Reply-To: "mahdavi"'s message of "Fri, 30 Nov 2001 02:56:40 +0330" Message-ID: Lines: 95 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 30 Nov 2001 15:51:07.0062 (UTC) FILETIME=[D2CB1D60:01C179B6] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem with this "mode" is that your plaintext/ciphertext has no relation to your IV. It means there really is no chaining going on, except via 'F' which may or may not provide as much security as 'S'. Moreover, the IV chaining you propose depends on neither P nor K, which some may consider a bug. -derek "mahdavi" writes: > Hi. > And other way to encrease speed and also not to loose security and also not > to pay for Overhead is to generate a random number for IV to use with first > block and generate other IVs for other Blocks based on this IV and number of > block. > > I mean this. > > (P satnds for Plain block, C stands for Ciphered Block, F is a function, S > is Security function.) > > > IV ( 0 ) = a random number; C ( 0 ) = S ( P(0) , IV ( 0 ) ) ; // may be S > P (0) XOR IV ( 0 ) > > for i from 0 till end of Block > IV ( i ) = F ( IV ( i - 1 ) ) ; C ( i ) = S ( P ( i ) , IV ( i ) ) ; // > may be S ( P (0) XOR IV ( 0 ) > > > If F be a right function that is known with both end node and be simple that > can be generated as fast we will gain all option that I mentioned. > > In this way a very Efficient pipeline can be made. > > > > ----- Original Message ----- > From: "Paul Koning" > To: > Cc: > Sent: Thursday, November 29, 2001 6:07 PM > Subject: Re: CBC makes Implementations too Slow. > > > > >>>>> "Michael" == Michael Cyr writes: > > > > Michael> On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > > >> CBC mode requires feedback, which makes it impossible to pipeline > > >> encryptions; you can't encrypt plaintext block P[n+1] until you > > >> have the ciphertext from encrypting P[n]. > > > > Michael> I know this discussion was a while ago, but I have a > > Michael> question related to the problem. First, let me say that I'm > > Michael> new to the list, and still somewhat new to IPsec in general, > > Michael> so I hope you'll forgive any ignorance on my part. > > > > Michael> Would it be a complete violation of the protocol to use > > Michael> random data for the IV data instead of a portion of the > > Michael> ciphertext of the previous block? I know this violates the > > Michael> spirit of cipher block _chaining_, but it would seem to > > Michael> address the concern that CBC was meant to fix, which is to > > Michael> ensure that if the same cleartext is encrypted twice, it > > Michael> doesn't produce the same ciphertext. Anyone have a > > Michael> definitive answer on this? > > > > My reading of the spec is that this is perfectly legal. The one thing > > you're not supposed to do is to use a low entropy IV value, such as a > > packet counter. > > > > That doesn't fix the performance problem for a single packet, though. > > You can do each packet independently if you use a random IV, but each > > plaintext block *within* the packet is still dependent on the previous > > block. > > > > On the other hand, using independent IVs per packet provides a useful > > gain if you have a number of packets pending (for the same SA) -- you > > can then encrypt them in parallel. In high load cases you will almost > > certainly have multiple packets waiting to be processed, so this > > should indeed give you a significant performance gain. > > > > paul > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 09:06:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUH6X809355; Fri, 30 Nov 2001 09:06:33 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA15012 Fri, 30 Nov 2001 11:16:58 -0500 (EST) Message-ID: <000001c179bb$4c70f140$9865fea9@TRLSHUKLA1> From: "Jayant Shukla" To: Subject: Re: LAST CALL: NAT TRAVERSAL DRAFTS Date: Tue, 27 Nov 2001 21:13:04 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C17788.4DD707C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C17788.4DD707C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable These drafts infringe on our pending patents, specifically the part = about transport mode ESP encapsulation.=20 BTW, the original ESP-UDP proposal does not infringe on our IP. The = modifications=20 that were made after the San Diego meeting (where we presented our proposal) are the problem. regards, Jayant ------=_NextPart_000_0007_01C17788.4DD707C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
These drafts infringe on our pending = patents,=20 specifically the part about transport = mode
ESP encapsulation.
 
BTW, the original ESP-UDP proposal = does not=20 infringe on our IP. The modifications =
that were made after the San Diego = meeting (where=20 we presented
our proposal) are the = problem.
 
regards,
Jayant
 
------=_NextPart_000_0007_01C17788.4DD707C0-- From owner-ipsec@lists.tislabs.com Fri Nov 30 11:07:37 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJ7a816441; Fri, 30 Nov 2001 11:07:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15252 Fri, 30 Nov 2001 13:05:06 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Sandy Harris" , "'IPsec WG'" References: <3.0.3.32.20011130021842.00db66d8@mail> <3C07A170.448E1597@storm.ca> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Fri, 30 Nov 2001 13:14:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 30 Nov 2001 18:14:11.0184 (UTC) FILETIME=[CF542F00:01C179CA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here is my observation: The RSA puliblic/private key (RSA key) is better than symmetric pre-shared key (SPSK) in the following way: Suppose both the RSA key and SPSK all using centerally managed server in a domain and further assume that the SPSK is one for each device (not one for each pair of device). Let's say there are 500 devices in this domain: Then there will be 500 keys for SPSK so is RSA keys. Each device will either have 499 public keys or 499 SPSKs. Given the key management (add/delete/remove) are *almost* equal, the SPSK has a not ignorable drawback than RSA Key structure: To break RSA key, attacker has to break into the device that hold the private key or break into the device that itself is the victim of MIM attack. The device has to responsible for its own security. (Given the real world that the security of a device are not created equal, this is a reasonable requirement) On the other hand, to break a SPSK, the attacker can choose any of the 500 devices to breakin. The risk is much higher for a device due to it demand all other participated devices have the same security level. Sure, the SPSK can increase the number of keys that limited the key to only two parties (and increase the complexicity of the key management) but still it is 200% risk more than RSA key due to it demands the same level of security level on peer. --- David ----- Original Message ----- From: "Sandy Harris" To: "'IPsec WG'" Sent: Friday, November 30, 2001 10:10 AM Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > Alex Alten wrote: > > > I will re-iterate my position. If a network security system is properly > > designed then either Public Key or Symmetric/Private Key cryptography > > will work fine in establishing trust. > > So far, so good. > > > I furthermore claim that Symmetric/Private Key cryptography > > will scale to great numbers of users > > Sorry, but this is nonsense. The classic problem with symmetric crypto is > key management. It neither scales well nor works well across administrative > boundaries. > > Consider n sites which all want to communicate. > > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which is > known to exactly two players and none of the others. Moreover, you have > to communicate those keys securely to the second player in each case, and > then keep it secure on both systems. > > With public key, you need only n key pairs. There is no need to communicate > keys securely; the system is designed to work even if the enemy knows the > public keys. Nor do you have to manage security for multiple keys, or keep > track of who each key is shared with. You just need to keep your private > key secure, not shared with anyone. > > Of course you can build a kerberos-like system using symmetric ciphers > that has many of the advantages of public key. Using a central key server > reduces the number of keys to n client-to-server keys and may simplify > management. However, I doubt such a centralised model is appropriate for > Internet infrastructure. > > > and I use the bank ATM secure network using DES as an excellent example. > > ... > > I think that's an irrelevant example. A tightly controlled single purpose > terminal-to-mainframe network under a single administrative authority > bears no useful resemblanmce to the Internet. Someone gave a good detailed > analysis earlier in the thread. You should re-read it. > > > As far as I'm concerned this should be the end of the discussion > > I agree, but for opposite reasons. > > > about whether or not Symmetric/Private Key cryptography can scale to > > large numbers of users in > > an efficient, easy to use by ordinary people, inexpensive to implement > > manner and > > interoperable between devices made by different manufacturers and > > maintained by > > different organizations. It has been done for the past 20 years by what is > > probably the most successful world-wide commercial networked security system. > > > > Anyone who still claims that Public Key is superior to Symmetric/Private Key > > cryptography, or that it is the only way to scale, is a *damn fool* and should > > be treated as such. > > How about "obviously superior for some purposes, including most key > distribution applications" and "almost always the best way to build > scalable systems"? > > Methinks you'll consider me a fool. I heartily return the sentiment. > From owner-ipsec@lists.tislabs.com Fri Nov 30 11:08:42 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJ8g816501; Fri, 30 Nov 2001 11:08:42 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15270 Fri, 30 Nov 2001 13:17:22 -0500 (EST) Message-ID: <3C07CF58.4070802@isi.edu> Date: Fri, 30 Nov 2001 10:26:32 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Stephen Kent CC: "Steven M. Bellovin" , Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 2:30 PM -0800 11/19/01, Joe Touch wrote: > >> Steven M. Bellovin wrote: >> >> While I'm not certain I understand what problem you're trying to solve >> that isn't already solved by tunnel mode, there are some weaknesses in >> this scheme as you've outlined it here. First, unless you have >> port-specific routing, you can't implement the full glory of IPsec >> SPDs (I'm perfectly willing to listen if you want to say that that's a >> feature, not a bug). >> >> FWIW - this is yet another place where I'd prefer to let firewall >> rules do their job, and IPsec to its. So yes, since I believe this can >> already be done with existing mechanisms, I don't care whether it >> defeats IPsec's ability to integrate it. (at least at first look >> that's how it appears) > > > Joe, > > As I have said on many occasions in the past, if one uses a separate > firewall module/device to do the filtering, after receipt of an IPsec > packet, security suffers, because one no longer has the SA info to > verify the (IPsec) source of the packet. I'm not saying that your IP > encapsulation approach can't preserve this functionality, but I am > saying that it is an essential part of IPsec and must be preserved in > any future version. Steve, I thought we went over this already as well- once a packet is decrypted, the SA should be carried with the packet for further checks. 2401 already mentions this as a should; we'd certainly prefer a must. Joe From owner-ipsec@lists.tislabs.com Fri Nov 30 11:08:56 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJ8u816525; Fri, 30 Nov 2001 11:08:56 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15228 Fri, 30 Nov 2001 13:01:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3BF987FB.7070908@isi.edu> References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> Date: Fri, 30 Nov 2001 13:01:51 -0500 To: Joe Touch From: Stephen Kent Subject: Re: ipsec in tunnel mode and dynamic routing Cc: "Steven M. Bellovin" , Lars Eggert , Ricky Charlet , Giaretta Gerardo , ipsec@lists.tislabs.com, Derek Atkins , xbone@ISI.EDU Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:30 PM -0800 11/19/01, Joe Touch wrote: >Steven M. Bellovin wrote: > >While I'm not certain I understand what problem you're trying to >solve that isn't already solved by tunnel mode, there are some >weaknesses in this scheme as you've outlined it here. First, unless >you have port-specific routing, you can't implement the full glory >of IPsec SPDs (I'm perfectly willing to listen if you want to say >that that's a feature, not a bug). > > >FWIW - this is yet another place where I'd prefer to let firewall >rules do their job, and IPsec to its. So yes, since I believe this >can already be done with existing mechanisms, I don't care whether >it defeats IPsec's ability to integrate it. (at least at first look >that's how it appears) Joe, As I have said on many occasions in the past, if one uses a separate firewall module/device to do the filtering, after receipt of an IPsec packet, security suffers, because one no longer has the SA info to verify the (IPsec) source of the packet. I'm not saying that your IP encapsulation approach can't preserve this functionality, but I am saying that it is an essential part of IPsec and must be preserved in any future version. Steve From owner-ipsec@lists.tislabs.com Fri Nov 30 11:10:20 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJAJ816609; Fri, 30 Nov 2001 11:10:19 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15295 Fri, 30 Nov 2001 13:23:20 -0500 (EST) From: "Khaja E. Ahmed" To: "Sandy Harris" , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Fri, 30 Nov 2001 10:32:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C07A170.448E1597@storm.ca> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Can anyone shed some light on why bank networks have not moved to Public Key Cryptography based security in their ATMs? I don't claim to know but I am beginning to wonder if it is because of the implied use of a (potentially new) TTP who will need to issue certificates. (I assume that for practical reasons, the use of Public Key Cryptography implies the use of a PKI in some PKIXish fashion ) The political obstacles of using a PKI in the world of Financial Institutions seem to pale in comparison with the challenge of key management in a shared secret only world. Several projects that require trusted/encrypted communications chose to use PKI but often ran aground amid heated debates of: Who be the root authority? Should a new one be created? Who will control it? Can we use some existing root? Who favors which? ...and so on. Certainly I have watched (and continue to watch) some of the (technologically) most elegant and useful PKI projects hit the wrong political notes and wither on the vine. The argument that Alex Alten makes is one I disagree with (despite his having made it necessarily unpleasant to do so) for obvious technical reasons. That said, I wonder if those who continue to use shared secrets do so more to avoid the aforementioned political strife. I myself have taken to making a much greater effort to watch for these political 'icebergs' when designing a solution. The other obstacle seems to be that for some reason it appears that people get ambitious about issuing X.509 certificates as they do with nothing else. No one seems content to issue a certificate for a single application and make that application easy to deal with. Hence the credit card certificate wants to be used to secure email, establish VPN sessions, do client authenticated SSL, sign purchases on the internet, draw cash, give access to workplace, protect the cell phone and be accepted by the car wash. I see this desire to have multipurpose certificates as an obstacle to getting ANY useful certificate out into the hands of the public. These ambitions are often the reason why otherwise straightforward and well bounded applications fail. Then there is a second obstacle in practical deployments and use of PKI. The registration process! For some reason, organizations seem to be comfortable with and have a history of creating and registering shared secrets between parties. These same organizations seem to have a hard time coping with the registration process for certificates. Not quite sure why. Insights into this issue will also be interesting. I have my share of bruises and opinions from attempting to tackle this in banking, but would love to hear other's opinions. I realize that this discussion belongs as much on the PKIX list as here but because the scaling of IPsec depends on effective use of PKI, I thought it would be important to bring these points up here. A desktop VPN certificate for a user is likely to get bogged down trying to be his email cert, his SSL cert, his... you get the picture. Khaja PS: As Jaswant Sing, India's minister of External Affairs and Defense said in a speech with Secretary Powell, "We disagree, but I don't see a reason to be disagreeable about it." > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Sandy Harris > Sent: Friday, November 30, 2001 7:11 AM > To: 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > Alex Alten wrote: > > > I will re-iterate my position. If a network security system is properly > > designed then either Public Key or Symmetric/Private Key cryptography > > will work fine in establishing trust. > > So far, so good. > > > I furthermore claim that Symmetric/Private Key cryptography > > will scale to great numbers of users > > Sorry, but this is nonsense. The classic problem with symmetric crypto is > key management. It neither scales well nor works well across > administrative > boundaries. > > Consider n sites which all want to communicate. > > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which is > known to exactly two players and none of the others. Moreover, you have > to communicate those keys securely to the second player in each case, and > then keep it secure on both systems. > > With public key, you need only n key pairs. There is no need to > communicate > keys securely; the system is designed to work even if the enemy knows the > public keys. Nor do you have to manage security for multiple keys, or keep > track of who each key is shared with. You just need to keep your private > key secure, not shared with anyone. > > Of course you can build a kerberos-like system using symmetric ciphers > that has many of the advantages of public key. Using a central key server > reduces the number of keys to n client-to-server keys and may simplify > management. However, I doubt such a centralised model is appropriate for > Internet infrastructure. > > > and I use the bank ATM secure network using DES as an excellent example. > > ... > > I think that's an irrelevant example. A tightly controlled single purpose > terminal-to-mainframe network under a single administrative authority > bears no useful resemblanmce to the Internet. Someone gave a good detailed > analysis earlier in the thread. You should re-read it. > > > As far as I'm concerned this should be the end of the discussion > > I agree, but for opposite reasons. > > > about whether or not Symmetric/Private Key cryptography can scale to > > large numbers of users in > > an efficient, easy to use by ordinary people, inexpensive to implement > > manner and > > interoperable between devices made by different manufacturers and > > maintained by > > different organizations. It has been done for the past 20 > years by what is > > probably the most successful world-wide commercial networked > security system. > > > > Anyone who still claims that Public Key is superior to > Symmetric/Private Key > > cryptography, or that it is the only way to scale, is a *damn > fool* and should > > be treated as such. > > How about "obviously superior for some purposes, including most key > distribution applications" and "almost always the best way to build > scalable systems"? > > Methinks you'll consider me a fool. I heartily return the sentiment. From owner-ipsec@lists.tislabs.com Fri Nov 30 11:29:46 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJTk817119; Fri, 30 Nov 2001 11:29:46 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15376 Fri, 30 Nov 2001 13:44:03 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE0118846F@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Sandy Harris'" , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Fri, 30 Nov 2001 18:52:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I tend to disagree with what you have stated. Please see comments inline. -----Original Message----- From: Sandy Harris [mailto:sandy@storm.ca] Sent: Friday, November 30, 2001 10:11 AM To: 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) .....[text omitted] > I furthermore claim that Symmetric/Private Key cryptography will scale > to great numbers of users [sandy] Sorry, but this is nonsense. The classic problem with symmetric crypto is key management. It neither scales well nor works well across administrative boundaries. [cliff] It depends whether you do it humanly or through management tools. When you do it manually, it doesn't scale well. When you use software to do it, not a problem. [sandy] Consider n sites which all want to communicate. For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which is known to exactly two players and none of the others. Moreover, you have to communicate those keys securely to the second player in each case, and then keep it secure on both systems. [cliff] Again, using provisioning and management tools, managing n*(n-1)/2 unique keys does not pose a scalability issue at all. The key can be provisioned to each box easily, since both ends of a tunnel are under the same management. On the other side, when you are using cert, you still have to deal the issue of sending the private key to the box, if the key pair is generated outside of the box, or deal with the issue of making cert request and then later install the cert. Do you think that is easier than just delivering the PSK to the device by management software? [sandy] With public key, you need only n key pairs. There is no need to communicate keys securely; the system is designed to work even if the enemy knows the public keys. Nor do you have to manage security for multiple keys, or keep track of who each key is shared with. You just need to keep your private key secure, not shared with anyone. [cliff] It depends where the key pair is generated. If it is generated inside the box, you need to get the cert request out and then later install the issued cert. You also have to install root CA chain to each box. You also have to do CRL checking. Simple comparison between N key pair vs. n*(n-1)/2 unique keys is unfair. You have to look at the whole picture. When using provisioning software, managing n key pairs or managing n*(n-1)/2 doesn't pose major scalability difference at all, in terms of key generation cost. Installing cert is no easier than installing PSK. Bottom line is that PSK based IPsec/IKE VPN has been accepted by customers and deployed in field via service provider offering. It is just one type of authentication that a service provider can offer and customers can choose. It simplifies the VPN setup by eliminating PKI system in the deployment. Saying that PSK based VPN is not scalable is biased, when you think you are doing it manually. So please look at the whole picture and realize that PSK based VPN has been offered by service providers and accepted happily by tens-of-thousands customers because of its simplicity and good scalability when such VPN systems are deployed via provisioning and management tools. From owner-ipsec@lists.tislabs.com Fri Nov 30 11:31:53 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJVr817187; Fri, 30 Nov 2001 11:31:53 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA15367 Fri, 30 Nov 2001 13:43:08 -0500 (EST) Message-Id: <5.1.0.14.0.20011130134926.00ad2b40@38.218.28.12> X-Sender: clenahan@38.218.28.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 30 Nov 2001 13:51:23 -0500 To: "ipsec" From: "clenahan@fortresstech.com" Subject: Re: CBC makes Implementations too Slow. In-Reply-To: References: <"mahdavi"'s message of "Fri, 30 Nov 2001 02:56:40 +0330"> <20011031005533.B51867C01@berkshire.research.att.com> <15366.18464.416439.388616@pkoning.dev.equallogic.com> <002601c1792e$06230760$cace1dd5@mahdavi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Is there an rfc or paper that discuss the proper uses of IV w/ different modes? At 09:50 AM 11/30/2001 -0500, Derek Atkins wrote: >The problem with this "mode" is that your plaintext/ciphertext has no >relation to your IV. It means there really is no chaining going on, >except via 'F' which may or may not provide as much security as 'S'. >Moreover, the IV chaining you propose depends on neither P nor K, >which some may consider a bug. > >-derek > >"mahdavi" writes: > > > Hi. > > And other way to encrease speed and also not to loose security and also not > > to pay for Overhead is to generate a random number for IV to use with first > > block and generate other IVs for other Blocks based on this IV and > number of > > block. > > > > I mean this. > > > > (P satnds for Plain block, C stands for Ciphered Block, F is a function, S > > is Security function.) > > > > > > IV ( 0 ) = a random number; C ( 0 ) = S ( P(0) , IV ( 0 ) ) ; // may be S > > P (0) XOR IV ( 0 ) > > > > for i from 0 till end of Block > > IV ( i ) = F ( IV ( i - 1 ) ) ; C ( i ) = S ( P ( i ) , IV ( i ) ) > ; // > > may be S ( P (0) XOR IV ( 0 ) > > > > > > If F be a right function that is known with both end node and be simple > that > > can be generated as fast we will gain all option that I mentioned. > > > > In this way a very Efficient pipeline can be made. > > > > > > > > ----- Original Message ----- > > From: "Paul Koning" > > To: > > Cc: > > Sent: Thursday, November 29, 2001 6:07 PM > > Subject: Re: CBC makes Implementations too Slow. > > > > > > > >>>>> "Michael" == Michael Cyr writes: > > > > > > Michael> On Tue, 30 Oct 2001, Steven M. Bellovin wrote: > > > >> CBC mode requires feedback, which makes it impossible to pipeline > > > >> encryptions; you can't encrypt plaintext block P[n+1] until you > > > >> have the ciphertext from encrypting P[n]. > > > > > > Michael> I know this discussion was a while ago, but I have a > > > Michael> question related to the problem. First, let me say that I'm > > > Michael> new to the list, and still somewhat new to IPsec in general, > > > Michael> so I hope you'll forgive any ignorance on my part. > > > > > > Michael> Would it be a complete violation of the protocol to use > > > Michael> random data for the IV data instead of a portion of the > > > Michael> ciphertext of the previous block? I know this violates the > > > Michael> spirit of cipher block _chaining_, but it would seem to > > > Michael> address the concern that CBC was meant to fix, which is to > > > Michael> ensure that if the same cleartext is encrypted twice, it > > > Michael> doesn't produce the same ciphertext. Anyone have a > > > Michael> definitive answer on this? > > > > > > My reading of the spec is that this is perfectly legal. The one thing > > > you're not supposed to do is to use a low entropy IV value, such as a > > > packet counter. > > > > > > That doesn't fix the performance problem for a single packet, though. > > > You can do each packet independently if you use a random IV, but each > > > plaintext block *within* the packet is still dependent on the previous > > > block. > > > > > > On the other hand, using independent IVs per packet provides a useful > > > gain if you have a number of packets pending (for the same SA) -- you > > > can then encrypt them in parallel. In high load cases you will almost > > > certainly have multiple packets waiting to be processed, so this > > > should indeed give you a significant performance gain. > > > > > > paul > > > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > >-- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 12:33:22 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUKXM820800; Fri, 30 Nov 2001 12:33:22 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15522 Fri, 30 Nov 2001 14:40:27 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188470@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Fri, 30 Nov 2001 19:49:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This analysis is seriously flawed: 1) SPSK or group pre-shared key per box is a bad idea. No security conscious people will adopt this. Because of this serious flaw in assumption, all security level comparison are meaningless. 2) Once an attacker compromise a box, he has access to either private key or the pre-shared key. Any communication with the box's partners are compromised, whether using PKI or PSK for IKE authentication. Where is the 200% risk come from? 3) why each device needs to have 499 public keys? They are contained in each box's cert and delivered as part of IKE exchange. -----Original Message----- From: david chen [mailto:ietf_davidchen@hotmail.com] Sent: Friday, November 30, 2001 1:15 PM To: Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Here is my observation: The RSA puliblic/private key (RSA key) is better than symmetric pre-shared key (SPSK) in the following way: Suppose both the RSA key and SPSK all using centerally managed server in a domain and further assume that the SPSK is one for each device (not one for each pair of device). Let's say there are 500 devices in this domain: Then there will be 500 keys for SPSK so is RSA keys. Each device will either have 499 public keys or 499 SPSKs. Given the key management (add/delete/remove) are *almost* equal, the SPSK has a not ignorable drawback than RSA Key structure: To break RSA key, attacker has to break into the device that hold the private key or break into the device that itself is the victim of MIM attack. The device has to responsible for its own security. (Given the real world that the security of a device are not created equal, this is a reasonable requirement) On the other hand, to break a SPSK, the attacker can choose any of the 500 devices to breakin. The risk is much higher for a device due to it demand all other participated devices have the same security level. Sure, the SPSK can increase the number of keys that limited the key to only two parties (and increase the complexicity of the key management) but still it is 200% risk more than RSA key due to it demands the same level of security level on peer. --- David ----- Original Message ----- From: "Sandy Harris" To: "'IPsec WG'" Sent: Friday, November 30, 2001 10:10 AM Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > Alex Alten wrote: > > > I will re-iterate my position. If a network security system is > > properly designed then either Public Key or Symmetric/Private Key > > cryptography will work fine in establishing trust. > > So far, so good. > > > I furthermore claim that Symmetric/Private Key cryptography will > > scale to great numbers of users > > Sorry, but this is nonsense. The classic problem with symmetric crypto > is key management. It neither scales well nor works well across administrative > boundaries. > > Consider n sites which all want to communicate. > > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which > is known to exactly two players and none of the others. Moreover, you > have to communicate those keys securely to the second player in each > case, and then keep it secure on both systems. > > With public key, you need only n key pairs. There is no need to communicate > keys securely; the system is designed to work even if the enemy knows > the public keys. Nor do you have to manage security for multiple keys, > or keep track of who each key is shared with. You just need to keep > your private key secure, not shared with anyone. > > Of course you can build a kerberos-like system using symmetric ciphers > that has many of the advantages of public key. Using a central key > server reduces the number of keys to n client-to-server keys and may > simplify management. However, I doubt such a centralised model is > appropriate for Internet infrastructure. > > > and I use the bank ATM secure network using DES as an excellent > > example. ... > > I think that's an irrelevant example. A tightly controlled single > purpose terminal-to-mainframe network under a single administrative > authority bears no useful resemblanmce to the Internet. Someone gave a > good detailed analysis earlier in the thread. You should re-read it. > > > As far as I'm concerned this should be the end of the discussion > > I agree, but for opposite reasons. > > > about whether or not Symmetric/Private Key cryptography can scale to > > large numbers of users in an efficient, easy to use by ordinary > > people, inexpensive to implement manner and > > interoperable between devices made by different manufacturers and > > maintained by > > different organizations. It has been done for the past 20 years by what is > > probably the most successful world-wide commercial networked > > security system. > > > > Anyone who still claims that Public Key is superior to > > Symmetric/Private Key > > cryptography, or that it is the only way to scale, is a *damn fool* > > and should > > be treated as such. > > How about "obviously superior for some purposes, including most key > distribution applications" and "almost always the best way to build > scalable systems"? > > Methinks you'll consider me a fool. I heartily return the sentiment. > From owner-ipsec@lists.tislabs.com Fri Nov 30 13:57:01 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAULv1824713; Fri, 30 Nov 2001 13:57:01 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15740 Fri, 30 Nov 2001 16:04:31 -0500 (EST) To: "Wang, Cliff" Cc: "'Sandy Harris'" , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <4652644B98DFF34696801F8F3070D3FE0118846F@D2CSPEXM001.smartpipes.com> From: Derek Atkins Date: 30 Nov 2001 16:14:06 -0500 In-Reply-To: "Wang, Cliff"'s message of "Fri, 30 Nov 2001 18:52:54 -0000" Message-ID: Lines: 54 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" writes: > [cliff] Again, using provisioning and management tools, managing n*(n-1)/2 > unique keys does not pose a scalability issue at all. The key can be > provisioned to each box easily, since both ends of a tunnel are under the > same management. On the other side, when you are using cert, you still have > to deal the issue of sending the private key to the box, if the key pair is > generated outside of the box, or deal with the issue of making cert request > and then later install the cert. Do you think that is easier than just > delivering the PSK to the device by management software? You presuppose a CA. I can envision a system (it exists today) where the key is generated on the box and no external communication is required. No cert_req; no cert_resp. As a device manager all you have to do is read the public key off the device and use it. > [sandy] > With public key, you need only n key pairs. There is no need to communicate > keys securely; the system is designed to work even if the enemy knows the > public keys. Nor do you have to manage security for multiple keys, or keep > track of who each key is shared with. You just need to keep your private key > secure, not shared with anyone. > > [cliff] It depends where the key pair is generated. If it is generated > inside the box, you need to get the cert request out and then later install > the issued cert. You also have to install root CA chain to each box. You > also have to do CRL checking. Simple comparison between N key pair vs. > n*(n-1)/2 unique keys is unfair. You have to look at the whole picture. Again, you are imposing a Certification Authority which does not necessarily exist. It certainly is not required. > So please look at the whole picture and realize that PSK based VPN has been > offered by service providers and accepted happily by tens-of-thousands > customers because of its simplicity and good scalability when such VPN > systems are deployed via provisioning and management tools. And sand has been offered by oasis's in deserts all around the world for centuries, and people will still drink it. Yes, you have to look at the whole picture, and realize that you're placing additional, needless constraints on the problem (namely an external Certificate Authority with all the trimmings). If you compare apples to apples (instead of apples to oranges, which is what you're doing), you would be comparing Pre-Shared Public Keys (without a CA) to Pre-Shared Symmetric Keys. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 13:57:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAULv8824727; Fri, 30 Nov 2001 13:57:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15746 Fri, 30 Nov 2001 16:06:57 -0500 (EST) To: "Wang, Cliff" Cc: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <4652644B98DFF34696801F8F3070D3FE01188470@D2CSPEXM001.smartpipes.com> From: Derek Atkins Date: 30 Nov 2001 16:16:33 -0500 In-Reply-To: "Wang, Cliff"'s message of "Fri, 30 Nov 2001 19:49:31 -0000" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" writes: > 3) why each device needs to have 499 public keys? They are contained in each > box's cert and delivered as part of IKE exchange. You pre-share to keys so you don't need a Certification Authority. Basically, if I have a copy of your driver's license in my posession, then in order to verify your driver's license I just need to compare it to my copy. That way I don't have to go ask the DMV to verify it for me, I've cached that verification locally (by storing a copy). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 14:18:08 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUMI8825242; Fri, 30 Nov 2001 14:18:08 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15797 Fri, 30 Nov 2001 16:30:44 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <5.1.0.14.0.20011130134926.00ad2b40@38.218.28.12> References: <"mahdavi"'s message of "Fri, 30 Nov 2001 02:56:40 +0330"> <20011031005533.B51867C01@berkshire.research.att.com> <15366.18464.416439.388616@pkoning.dev.equallogic.com> <002601c1792e$06230760$cace1dd5@mahdavi> <5.1.0.14.0.20011130134926.00ad2b40@38.218.28.12> Date: Fri, 30 Nov 2001 16:30:49 -0500 To: "clenahan@fortresstech.com" From: Stephen Kent Subject: Re: CBC makes Implementations too Slow. Cc: "ipsec" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:51 PM -0500 11/30/01, clenahan@fortresstech.com wrote: >Is there an rfc or paper that discuss the proper uses of IV w/ >different modes? > Each algorithm/mode combination used with ESP is responsible for defining IV management. If your question is broader, not restricted to the IPsec context, then I'd refer you to FIPS 81, which provides guidance for DES modes of operation. Steve From owner-ipsec@lists.tislabs.com Fri Nov 30 14:29:39 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUMTd825679; Fri, 30 Nov 2001 14:29:39 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15823 Fri, 30 Nov 2001 16:45:48 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188471@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Derek Atkins'" , "Wang, Cliff" Cc: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Fri, 30 Nov 2001 21:54:53 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk If you pre-share peer's public key instead of using CA, then it is the same n*(n-1) scale. It is no better than pre-shared key in scalability. -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Friday, November 30, 2001 4:17 PM To: Wang, Cliff Cc: 'david chen'; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) "Wang, Cliff" writes: > 3) why each device needs to have 499 public keys? They are contained > in each box's cert and delivered as part of IKE exchange. You pre-share to keys so you don't need a Certification Authority. Basically, if I have a copy of your driver's license in my posession, then in order to verify your driver's license I just need to compare it to my copy. That way I don't have to go ask the DMV to verify it for me, I've cached that verification locally (by storing a copy). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 14:38:59 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUMcw826616; Fri, 30 Nov 2001 14:38:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15837 Fri, 30 Nov 2001 16:50:53 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3C07CF58.4070802@isi.edu> References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> <3C07CF58.4070802@isi.edu> Date: Fri, 30 Nov 2001 16:56:58 -0500 To: Joe Touch From: Stephen Kent Subject: Re: ipsec in tunnel mode and dynamic routing Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:26 AM -0800 11/30/01, Joe Touch wrote: >Stephen Kent wrote: > >>At 2:30 PM -0800 11/19/01, Joe Touch wrote: >> >>>Steven M. Bellovin wrote: >>> >>>While I'm not certain I understand what problem you're trying to >>>solve that isn't already solved by tunnel mode, there are some >>>weaknesses in this scheme as you've outlined it here. First, >>>unless you have port-specific routing, you can't implement the >>>full glory of IPsec SPDs (I'm perfectly willing to listen if you >>>want to say that that's a feature, not a bug). >>> >>>FWIW - this is yet another place where I'd prefer to let firewall >>>rules do their job, and IPsec to its. So yes, since I believe this >>>can already be done with existing mechanisms, I don't care whether >>>it defeats IPsec's ability to integrate it. (at least at first >>>look that's how it appears) >> >> >>Joe, >> >>As I have said on many occasions in the past, if one uses a >>separate firewall module/device to do the filtering, after receipt >>of an IPsec packet, security suffers, because one no longer has the >>SA info to verify the (IPsec) source of the packet. I'm not saying >>that your IP encapsulation approach can't preserve this >>functionality, but I am saying that it is an essential part of >>IPsec and must be preserved in any future version. > > >Steve, > >I thought we went over this already as well- once a packet is >decrypted, the SA should be carried with the packet for further >checks. 2401 already mentions this as a should; we'd certainly >prefer a must. > >Joe 2401 requires that the SA binding be maintained only within the IPsec implementation. I understood your comments to suggest something else, e.g., a separate firewall module not part of IPsec. If I misunderstood, I apologize. Steve From owner-ipsec@lists.tislabs.com Fri Nov 30 14:41:13 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUMfC826665; Fri, 30 Nov 2001 14:41:12 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15832 Fri, 30 Nov 2001 16:50:46 -0500 (EST) To: "Wang, Cliff" Cc: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <4652644B98DFF34696801F8F3070D3FE01188471@D2CSPEXM001.smartpipes.com> From: Derek Atkins Date: 30 Nov 2001 17:00:22 -0500 In-Reply-To: "Wang, Cliff"'s message of "Fri, 30 Nov 2001 21:54:53 -0000" Message-ID: Lines: 47 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" writes: > If you pre-share peer's public key instead of using CA, then it is the same > n*(n-1) scale. > It is no better than pre-shared key in scalability. No, because unlike symmetric keys you do NOT need a unique key per peer with public/private keys. Each node has one key-pair and all peers get a copy of the public key. So there are only N keys (well, technically 2*N keys, N public keys and N private keys ;) But this is still better than the N*(N-1)/2 symmetric keys. -derek > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Friday, November 30, 2001 4:17 PM > To: Wang, Cliff > Cc: 'david chen'; Sandy Harris; 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > "Wang, Cliff" writes: > > > 3) why each device needs to have 499 public keys? They are contained > > in each box's cert and delivered as part of IKE exchange. > > You pre-share to keys so you don't need a Certification Authority. > > Basically, if I have a copy of your driver's license in my posession, then > in order to verify your driver's license I just need to compare it to my > copy. That way I don't have to go ask the DMV to verify it for me, I've > cached that verification locally (by storing a copy). > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 14:41:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUMfQ826682; Fri, 30 Nov 2001 14:41:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA15872 Fri, 30 Nov 2001 16:54:22 -0500 (EST) Message-ID: <3C080214.8040603@isi.edu> Date: Fri, 30 Nov 2001 14:03:00 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> <3C07CF58.4070802@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > 2401 requires that the SA binding be maintained only within the IPsec > implementation. I understood your comments to suggest something else, > e.g., a separate firewall module not part of IPsec. If I misunderstood, > I apologize. We want the SA is kept outside the IPsec, so that packets that pass through other modules in the meantime will retain their SA, e.g., Sec 8.4. Joe From owner-ipsec@lists.tislabs.com Fri Nov 30 15:12:04 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUNC4828675; Fri, 30 Nov 2001 15:12:04 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15947 Fri, 30 Nov 2001 17:08:49 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Wang, Cliff" Cc: "'david chen'" , "Sandy Harris" , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <4652644B98DFF34696801F8F3070D3FE01188470@D2CSPEXM001.smartpipes.com> From: "Derek Atkins" Date: 30 Nov 2001 16:16:33 -0500 In-Reply-To: "Wang, Cliff"'s message of "Fri, 30 Nov 2001 19:49:31 -0000" Message-ID: Lines: 19 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 30 Nov 2001 22:18:31.0437 (UTC) FILETIME=[F18543D0:01C179EC] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" writes: > 3) why each device needs to have 499 public keys? They are contained in each > box's cert and delivered as part of IKE exchange. You pre-share to keys so you don't need a Certification Authority. Basically, if I have a copy of your driver's license in my posession, then in order to verify your driver's license I just need to compare it to my copy. That way I don't have to go ask the DMV to verify it for me, I've cached that verification locally (by storing a copy). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 15:30:18 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUNUH829086; Fri, 30 Nov 2001 15:30:18 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA16089 Fri, 30 Nov 2001 17:47:16 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Wang, Cliff" Cc: "'david chen'" , "Sandy Harris" , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <4652644B98DFF34696801F8F3070D3FE01188471@D2CSPEXM001.smartpipes.com> From: "Derek Atkins" Date: 30 Nov 2001 17:00:22 -0500 In-Reply-To: "Wang, Cliff"'s message of "Fri, 30 Nov 2001 21:54:53 -0000" Message-ID: Lines: 47 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 30 Nov 2001 22:57:01.0656 (UTC) FILETIME=[5284B580:01C179F2] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" writes: > If you pre-share peer's public key instead of using CA, then it is the same > n*(n-1) scale. > It is no better than pre-shared key in scalability. No, because unlike symmetric keys you do NOT need a unique key per peer with public/private keys. Each node has one key-pair and all peers get a copy of the public key. So there are only N keys (well, technically 2*N keys, N public keys and N private keys ;) But this is still better than the N*(N-1)/2 symmetric keys. -derek > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Friday, November 30, 2001 4:17 PM > To: Wang, Cliff > Cc: 'david chen'; Sandy Harris; 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > "Wang, Cliff" writes: > > > 3) why each device needs to have 499 public keys? They are contained > > in each box's cert and delivered as part of IKE exchange. > > You pre-share to keys so you don't need a Certification Authority. > > Basically, if I have a copy of your driver's license in my posession, then > in order to verify your driver's license I just need to compare it to my > copy. That way I don't have to go ask the DMV to verify it for me, I've > cached that verification locally (by storing a copy). > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 15:47:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUNlQ800332; Fri, 30 Nov 2001 15:47:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15926 Fri, 30 Nov 2001 17:03:21 -0500 (EST) Message-ID: <4652644B98DFF34696801F8F3070D3FE01188472@D2CSPEXM001.smartpipes.com> From: "Wang, Cliff" To: "'Derek Atkins'" , "Wang, Cliff" Cc: "'david chen'" , Sandy Harris , "'IPsec WG'" Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) Date: Fri, 30 Nov 2001 22:12:25 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It depends on how you see things. I agree that you only need to have 2N keys in existence. But from a usage/implementation/deployment point of view, you are still dealing n*(n-1) key delivery. The only difference is that you deliver the same public key (N-1) times to N boxes in the case of RSA, but you deliver (N-1)*N/2 different keys in PSK case, assuming we are talking a full mesh relationship. Maybe we see things from different view point. From mathematics, you are right in the number of keys needed. >From an operation point of view, I see no scalability advantage, in terms of key generation (RSA key pair is much more expensive than a random symmetric key), in terms of delivery, in terms of usage, in terms of storage. So I guess we need to make it clear on what is the assumption of the discussion, when we claim scalability advantage. Mathematically, or in real world applications. -----Original Message----- From: Derek Atkins [mailto:warlord@MIT.EDU] Sent: Friday, November 30, 2001 5:00 PM To: Wang, Cliff Cc: 'david chen'; Sandy Harris; 'IPsec WG' Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) "Wang, Cliff" writes: > If you pre-share peer's public key instead of using CA, then it is the > same > n*(n-1) scale. > It is no better than pre-shared key in scalability. No, because unlike symmetric keys you do NOT need a unique key per peer with public/private keys. Each node has one key-pair and all peers get a copy of the public key. So there are only N keys (well, technically 2*N keys, N public keys and N private keys ;) But this is still better than the N*(N-1)/2 symmetric keys. -derek > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Friday, November 30, 2001 4:17 PM > To: Wang, Cliff > Cc: 'david chen'; Sandy Harris; 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > "Wang, Cliff" writes: > > > 3) why each device needs to have 499 public keys? They are contained > > in each box's cert and delivered as part of IKE exchange. > > You pre-share to keys so you don't need a Certification Authority. > > Basically, if I have a copy of your driver's license in my posession, > then in order to verify your driver's license I just need to compare > it to my copy. That way I don't have to go ask the DMV to verify it > for me, I've cached that verification locally (by storing a copy). > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 15:52:27 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUNqQ800436; Fri, 30 Nov 2001 15:52:26 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA15957 Fri, 30 Nov 2001 17:09:33 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit x-receiver: m.gratton@adga.ca X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 To: "Wang, Cliff" Cc: "'Sandy Harris'" , "'IPsec WG'" Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) References: <4652644B98DFF34696801F8F3070D3FE0118846F@D2CSPEXM001.smartpipes.com> From: "Derek Atkins" Date: 30 Nov 2001 16:14:06 -0500 In-Reply-To: "Wang, Cliff"'s message of "Fri, 30 Nov 2001 18:52:54 -0000" Message-ID: Lines: 54 X-Mailer: Gnus v5.7/Emacs 20.7 X-OriginalArrivalTime: 30 Nov 2001 22:18:57.0312 (UTC) FILETIME=[00F17A00:01C179ED] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk "Wang, Cliff" writes: > [cliff] Again, using provisioning and management tools, managing n*(n-1)/2 > unique keys does not pose a scalability issue at all. The key can be > provisioned to each box easily, since both ends of a tunnel are under the > same management. On the other side, when you are using cert, you still have > to deal the issue of sending the private key to the box, if the key pair is > generated outside of the box, or deal with the issue of making cert request > and then later install the cert. Do you think that is easier than just > delivering the PSK to the device by management software? You presuppose a CA. I can envision a system (it exists today) where the key is generated on the box and no external communication is required. No cert_req; no cert_resp. As a device manager all you have to do is read the public key off the device and use it. > [sandy] > With public key, you need only n key pairs. There is no need to communicate > keys securely; the system is designed to work even if the enemy knows the > public keys. Nor do you have to manage security for multiple keys, or keep > track of who each key is shared with. You just need to keep your private key > secure, not shared with anyone. > > [cliff] It depends where the key pair is generated. If it is generated > inside the box, you need to get the cert request out and then later install > the issued cert. You also have to install root CA chain to each box. You > also have to do CRL checking. Simple comparison between N key pair vs. > n*(n-1)/2 unique keys is unfair. You have to look at the whole picture. Again, you are imposing a Certification Authority which does not necessarily exist. It certainly is not required. > So please look at the whole picture and realize that PSK based VPN has been > offered by service providers and accepted happily by tens-of-thousands > customers because of its simplicity and good scalability when such VPN > systems are deployed via provisioning and management tools. And sand has been offered by oasis's in deserts all around the world for centuries, and people will still drink it. Yes, you have to look at the whole picture, and realize that you're placing additional, needless constraints on the problem (namely an external Certificate Authority with all the trimmings). If you compare apples to apples (instead of apples to oranges, which is what you're doing), you would be comparing Pre-Shared Public Keys (without a CA) to Pre-Shared Symmetric Keys. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ipsec@lists.tislabs.com Fri Nov 30 16:15:58 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB10Fv802221; Fri, 30 Nov 2001 16:15:58 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16197 Fri, 30 Nov 2001 18:30:30 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3C080214.8040603@isi.edu> References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> <3C07CF58.4070802@isi.edu> <3C080214.8040603@isi.edu> Date: Fri, 30 Nov 2001 18:34:18 -0500 To: Joe Touch From: Stephen Kent Subject: Re: ipsec in tunnel mode and dynamic routing Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:03 PM -0800 11/30/01, Joe Touch wrote: >Stephen Kent wrote: > >> >>2401 requires that the SA binding be maintained only within the >>IPsec implementation. I understood your comments to suggest >>something else, e.g., a separate firewall module not part of IPsec. >>If I misunderstood, I apologize. > > >We want the SA is kept outside the IPsec, so that packets that pass >through other modules in the meantime will retain their SA, e.g., >Sec 8.4. > >Joe Joe, Your sentence is not well formed, but I suspect we do have a serious disagreement here. An SA is an IPsec concept and thus it exists only within an IPsec module. IPsec has never been just an encryption protocol, although some have suggested otherwise. Encryption, by itself, does not provide protection against the major forms of attack that most Internet users experience. Rather, access control is the security service that is the focus of most security mechanisms that we employ, if one remembers that the primary motivation for authentication (user or otherwise) is as an input to an access control decision. Since the authentication of the other IPsec peer is an IPsec function, it makes sense to retain that authentication info and use it to filter traffic within IPsec, i.e., to perform identity-based access control enforcement there. Steve From owner-ipsec@lists.tislabs.com Fri Nov 30 21:30:33 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB15UW807512; Fri, 30 Nov 2001 21:30:32 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16595 Fri, 30 Nov 2001 23:41:56 -0500 (EST) X-Originating-IP: [66.31.70.172] From: "david chen" To: "Wang, Cliff" , "Sandy Harris" , "'IPsec WG'" References: <4652644B98DFF34696801F8F3070D3FE01188470@D2CSPEXM001.smartpipes.com> Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) Date: Fri, 30 Nov 2001 23:51:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 01 Dec 2001 04:50:59.0618 (UTC) FILETIME=[C5548820:01C17A23] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Cliff, Let's agree that the pre-shared symmetric key will only *intended* used by two devices. Let's look at a 5 devices network and a central keys deposit server. For key management purpose, both the pre-shared RSA public keys and the symmetic keys will be in a server. (Don't see any scalable model other than this) For a fully meshed communication model among these 5 devices: 1) the symmetric keys case: The server have to store 10 = (5*4)/2 s. keys. and keep track of which link associate to which key. Before device_1 communicates with device_2, these transactions have to happen: the sk_12 will be sent from server to device_1 and device_2 through out-of-band secured channel. (well, this dynamic model is scalable otherwise if the 10 keys pre-loaed on each of the 5 devices; it will be difficult when a device join-in...) After the full mesh is reached, each device will have 4 Skeys. 2) the RSA keys case: The server have to strore 5 public keys and don't care about link info., but have to associate device to its public key. Before device_1 communicates with device_2, these transactions have to happen: the pk_1 is sent to device_2 from server and the pk_2 is sent to device_1 trough out-of-band secured channel. After the full mesh is reached, each device will have 4 public keys and its own private keys. Observation: 1. The symmetric key management model shows that for a single skey, there are 3 parties know it. The 2 devices and the server. Clearly, get the skeys in the server is most effective to break entire mesh. In contrast to the symmetric key, get the public-keys in the RA does not break any secure link. (therefore, you can let 3rd party manage this server "RA", as long as it guarantees id/public-key bindings) 2. The number of keys in the server is clearly more for symmetric keys. In addition, it has to keep track of 'link-id'/key pair which is more difficult than that of 'device-id' in the case of public keys. --- David P.S. I agree that when a device been tampered, all the established secured link to this device are broken for either symmetric or asymmetric keys are used. ----- Original Message ----- From: "Wang, Cliff" To: "'david chen'" ; "Sandy Harris" ; "'IPsec WG'" Sent: Friday, November 30, 2001 2:49 PM Subject: RE: On shared keys (was RE: SOI: identity protection and DOS) > This analysis is seriously flawed: > 1) SPSK or group pre-shared key per box is a bad idea. No security conscious > people will adopt this. Because of this serious flaw in assumption, all > security level comparison are meaningless. > 2) Once an attacker compromise a box, he has access to either private key or > the pre-shared key. > Any communication with the box's partners are compromised, whether using PKI > or PSK for IKE authentication. Where is the 200% risk come from? > 3) why each device needs to have 499 public keys? They are contained in each > box's cert and delivered as part of IKE exchange. > > -----Original Message----- > From: david chen [mailto:ietf_davidchen@hotmail.com] > Sent: Friday, November 30, 2001 1:15 PM > To: Sandy Harris; 'IPsec WG' > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > Here is my observation: > > The RSA puliblic/private key (RSA key) is better than symmetric pre-shared > key (SPSK) in the following way: Suppose both the RSA key and SPSK all using > centerally managed server in a domain and further assume that the SPSK is > one for each device (not one for each pair of device). Let's say there are > 500 devices in this domain: Then there will be 500 keys for SPSK so is RSA > keys. Each device will either have 499 public keys or 499 SPSKs. Given the > key management (add/delete/remove) are *almost* equal, the SPSK has a not > ignorable drawback than RSA Key structure: To break RSA key, attacker has to > break into the device that hold the private key or break into the device > that itself is the victim of MIM attack. The device has to responsible for > its own security. (Given the real world that the security of a device are > not created equal, this is a reasonable requirement) > > On the other hand, to break a SPSK, the attacker can choose any of the 500 > devices to breakin. The risk is much higher for a device due to it demand > all other participated devices have the same security level. > > Sure, the SPSK can increase the number of keys that limited the key to only > two parties (and increase the complexicity of the key management) but still > it is 200% risk more than RSA key due to it demands the same level of > security level on peer. > > > --- David > > > > ----- Original Message ----- > From: "Sandy Harris" > To: "'IPsec WG'" > Sent: Friday, November 30, 2001 10:10 AM > Subject: Re: On shared keys (was RE: SOI: identity protection and DOS) > > > > Alex Alten wrote: > > > > > I will re-iterate my position. If a network security system is > > > properly designed then either Public Key or Symmetric/Private Key > > > cryptography will work fine in establishing trust. > > > > So far, so good. > > > > > I furthermore claim that Symmetric/Private Key cryptography will > > > scale to great numbers of users > > > > Sorry, but this is nonsense. The classic problem with symmetric crypto > > is key management. It neither scales well nor works well across > administrative > > boundaries. > > > > Consider n sites which all want to communicate. > > > > For symmetric ciphers, you need n*(n-1)/2 unique keys, each of which > > is known to exactly two players and none of the others. Moreover, you > > have to communicate those keys securely to the second player in each > > case, and then keep it secure on both systems. > > > > With public key, you need only n key pairs. There is no need to > communicate > > keys securely; the system is designed to work even if the enemy knows > > the public keys. Nor do you have to manage security for multiple keys, > > or keep track of who each key is shared with. You just need to keep > > your private key secure, not shared with anyone. > > > > Of course you can build a kerberos-like system using symmetric ciphers > > that has many of the advantages of public key. Using a central key > > server reduces the number of keys to n client-to-server keys and may > > simplify management. However, I doubt such a centralised model is > > appropriate for Internet infrastructure. > > > > > and I use the bank ATM secure network using DES as an excellent > > > example. ... > > > > I think that's an irrelevant example. A tightly controlled single > > purpose terminal-to-mainframe network under a single administrative > > authority bears no useful resemblanmce to the Internet. Someone gave a > > good detailed analysis earlier in the thread. You should re-read it. > > > > > As far as I'm concerned this should be the end of the discussion > > > > I agree, but for opposite reasons. > > > > > about whether or not Symmetric/Private Key cryptography can scale to > > > large numbers of users in an efficient, easy to use by ordinary > > > people, inexpensive to implement manner and > > > interoperable between devices made by different manufacturers and > > > maintained by > > > different organizations. It has been done for the past 20 years by what > is > > > probably the most successful world-wide commercial networked > > > security > system. > > > > > > Anyone who still claims that Public Key is superior to > > > Symmetric/Private > Key > > > cryptography, or that it is the only way to scale, is a *damn fool* > > > and > should > > > be treated as such. > > > > How about "obviously superior for some purposes, including most key > > distribution applications" and "almost always the best way to build > > scalable systems"? > > > > Methinks you'll consider me a fool. I heartily return the sentiment. > > > From owner-ipsec@lists.tislabs.com Fri Nov 30 21:30:36 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB15Ua807524; Fri, 30 Nov 2001 21:30:36 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16565 Fri, 30 Nov 2001 23:30:22 -0500 (EST) Mime-Version: 1.0 X-Sender: karen.seo@po1.bbn.com Message-Id: Date: Fri, 30 Nov 2001 23:43:31 -0500 To: "Joseph D. Harwood" From: Karen Seo Subject: Re: ESP Draft Cc: "Ipsec" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id XAA16562 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello Joseph, That was quick :-). Thank you for the review/feedback. Responses below... Please let us know if you have further questions/comments. Karen >Page 8, Section 2 - >(see Section ?? below) > >3.3.2.2? Yes. >Page 12, Section 2.2.1 - >See Section ?? for processing details. > >3.3.2.2? Yes. >Page 14, Section 2.4 - > >" o For the purpose of ensuring that the bits to be encrypted > are a multiple of the algorithm's blocksize (first bullet > above), the padding computation applies to the Payload Data > exclusive of any IV, but including the ESP trailer > fields. If a combined algorithm mode requires transmission > of the SPI and Sequence Number to effect integrity, then > these data items, and any associated, ICV-equivalent data, > are included in the computation of the pad length. (If the > ESN option is selected, the high order 32 bits of the ESN > also would enter into the computation, if the combined mode > algorithm requires their transmission for integrity.)" > >The reference to SPI and Sequence Number above are for replicated >transmission? If so, perhaps this could be mentioned. Good point. We'll add this. >Page 17, Section 3.1.1 - > >"Destination options extension header(s) could appear > before, after, or both before and after the ESP header depending on > the semantics desired" > >Just a question I've had for a while, is there an advantage to allowing the >destination options to come before the ESP header? Just to be sure I'm using before/after the same way that you are :-)... If an IP packet has the following fields: orig IP hdr, dest opts, routing hdr, ESP hdr, dest ops, etc. If the destination options come BEFORE then they will be used as the packet travels along the path of the SA. In the example above, there is a routing extension header for source routing (say from A to B to C to D.) The destination options in the BEFORE location would be processed at B, and if the semantics required, the destination options would be passed along and processed at C, etc. But the semantics might also cause them to be processed only at B. If the destination options come AFTER then they will be applied after the packet has arrived at the endpoint of the SA and the IPsec header has been processed. These would be options that would apply to a host, e.g., ones indicating that the packet is a jumbogram. While the "BEFORE" ones won't be protected by ESP, there's no way to apply the internal "AFTER" ones along the packet's path (they would typically be encrypted, etc.) >Page 22, Section 3.3.2.1 - > >" 2. adds any necessary padding Ï Optional TFC padding and > (encryption) Padding" > >Non-text character. Oops -- should have been a "--". >Page 23. Section 3.3.2.2 - > >" 2. adds any necessary paddingÏincludes optional TFC padding > and Padding." > >Non-text character, Hmm...I need to get Microsoft to stop converting my "--"s to hyphens :-). The non-text character should have been a "--". >and should there be an (encryption) before the Padding? Yes, there should be an "(encryption)" before the "Padding". I checked with Steve Kent on the following questions and have included his replies below. >Page 32, Section 5 - > >"AES in CBC mode" > >128/192/256? This is a placeholder for an RFC. We'll see what the new ID from NIST says, and what the WG decides. I'd suggest 128 is sufficient as a default. > >Page 32, Section 5 - > >Should 3DES be required for compatibility with existing implementations? The previous version of ESP required DES, not 3DES, so not all compliant existing implementations would offer 3DES. I agree that, in practice, it is likely to be true that most folks do offer 3DES CBC, but making this a mandatory mode removes incentive to go to AES CBC, which will be faster. So, I would not recommend including 3DES CBC as a mandatory mode. > >Page 32, Section 5 - > >I saw the IP Storage group is looking at requiring AES in a Counter Mode, >any word when NIST will have something on this? > You'll have to ask NIST folks when they may have a counter mode standard. We already have several counter mode proposals floating around as IDs, and will have to select one. The WG needs to decide if it will be a mandatory mode, and thus merit inclusion in this document, or if it will be an optional mode and thus not part of the ESP spec. From owner-ipsec@lists.tislabs.com Fri Nov 30 23:04:26 2001 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fB174P809834; Fri, 30 Nov 2001 23:04:25 -0800 (PST) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16838 Sat, 1 Dec 2001 01:18:30 -0500 (EST) Message-ID: <3C087834.2060308@isi.edu> Date: Fri, 30 Nov 2001 22:27:00 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: ipsec in tunnel mode and dynamic routing References: <20011119193857.6C4687B55@berkshire.research.att.com> <3BF987FB.7070908@isi.edu> <3C07CF58.4070802@isi.edu> <3C080214.8040603@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > At 2:03 PM -0800 11/30/01, Joe Touch wrote: > >> Stephen Kent wrote: >> >>> >>> 2401 requires that the SA binding be maintained only within the IPsec >>> implementation. I understood your comments to suggest something else, >>> e.g., a separate firewall module not part of IPsec. If I >>> misunderstood, I apologize. >> >> >> >> We want the SA is kept outside the IPsec, so that packets that pass >> through other modules in the meantime will retain their SA, e.g., Sec >> 8.4. >> >> Joe > > > Joe, > > Your sentence is not well formed, but I suspect we do have a serious > disagreement here. Delete the /is/. Sorry about that :-) Yes, it appears we do disagree - let's see where the thread goes, though. > An SA is an IPsec concept and thus it exists only within an IPsec > module. IPsec has never been just an encryption protocol, although some > have suggested otherwise. Encryption, by itself, does not provide > protection against the major forms of attack that most Internet users > experience. Rather, access control is the security service that is the > focus of most security mechanisms that we employ, if one remembers that > the primary motivation for authentication (user or otherwise) is as an > input to an access control decision. > > Since the authentication of the other IPsec peer is an IPsec function, > it makes sense to retain that authentication info and use it to filter > traffic within IPsec, i.e., to perform identity-based access control > enforcement there. In that case, what we have is a failure of firewall code (ipfw, e.g.) and tunnel mechanisms (gifconfig, e.g.). If that code is "inside" the IPsec implementation, the SA would be available. There is more to packet processing than just encryption and authentication, _however_ that doesn't mean that the configuration interface needs to be as integrated as the implementation. If, for example, all firewall processing and tunneling were _implemented_ inside IPsec, then the SAs would be properly available. So, I agree that the implementation should be integrated, but not necessarily that the configuration should be as tightly integrated. Joe