From ipsec-bounces@ietf.org Tue Aug 3 19:00:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7420cMi024236; Tue, 3 Aug 2004 19:00:38 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAyI-0006tj-41; Tue, 03 Aug 2004 21:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAur-0006CY-Lq for ipsec@megatron.ietf.org; Tue, 03 Aug 2004 21:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00623 for ; Tue, 3 Aug 2004 21:50:03 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAy3-0006F8-8t for ipsec@ietf.org; Tue, 03 Aug 2004 21:53:23 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i741kdg15936 for ; Tue, 3 Aug 2004 21:46:39 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i741lFCO014074 for ; Tue, 3 Aug 2004 21:47:15 -0400 (EDT) Received: from 69-161-22-203.chvlva.adelphia.net(69.161.22.203) by nutshell.tislabs.com via csmap (V6.0) id srcAAAzAayBB; Tue, 3 Aug 04 21:47:06 -0400 Date: Tue, 03 Aug 2004 21:49:51 -0500 To: ipsec@lists.tislabs.com From: administration@tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cvhbehhftyibxpyggoud" X-Spam-Score: 1.5 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ipsec] Notify about using the e-mail account. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------cvhbehhftyibxpyggoud Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear user of e-mail server "Tislabs.com",

Some of our clients complained about the spam (negative e-mail content)
outgoing from your e-mail account. Probably, you have been infected by
a proxy-relay trojan server. In order to keep your computer safe,
follow the instructions.

Advanced details can be found in attached file.

Sincerely,
The Tislabs.com team http://www.tislabs.com ----------cvhbehhftyibxpyggoud Content-Type: text/html; name="MoreInfo.pif.htm" Content-Disposition: attachment; filename="MoreInfo.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: MoreInfo.pif
Virus name: W32/Bagle.n@MM

----------cvhbehhftyibxpyggoud Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------cvhbehhftyibxpyggoud-- From ipsec-bounces@ietf.org Tue Aug 3 19:02:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7422QVg024351; Tue, 3 Aug 2004 19:02:26 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAyJ-0006tt-44; Tue, 03 Aug 2004 21:53:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsAur-0006CZ-Lq for ipsec@megatron.ietf.org; Tue, 03 Aug 2004 21:50:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00626 for ; Tue, 3 Aug 2004 21:50:04 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsAy2-0006F4-H8 for ipsec@ietf.org; Tue, 03 Aug 2004 21:53:23 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i741kcg15931 for ; Tue, 3 Aug 2004 21:46:38 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i741lFOn014071 for ; Tue, 3 Aug 2004 21:47:15 -0400 (EDT) Received: from 69-161-22-203.chvlva.adelphia.net(69.161.22.203) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2zaqBB; Tue, 3 Aug 04 21:47:06 -0400 Date: Tue, 03 Aug 2004 21:49:51 -0500 To: ipsec@lists.tislabs.com From: management@tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fxvvwttifqnhyotmougp" X-Spam-Score: 1.5 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [Ipsec] E-mail technical support warning. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------fxvvwttifqnhyotmougp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear user of "Tislabs.com" mailing system,

Your e-mail account has been temporary disabled because of unauthorized access.

Further details can be obtained from attached file.

Best wishes,
The Tislabs.com team http://www.tislabs.com ----------fxvvwttifqnhyotmougp Content-Type: text/html; name="details.pif.htm" Content-Disposition: attachment; filename="details.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: details.pif
Virus name: W32/Bagle.n@MM

----------fxvvwttifqnhyotmougp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------fxvvwttifqnhyotmougp-- From ipsec-bounces@ietf.org Tue Aug 3 20:49:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i743nIor031511; Tue, 3 Aug 2004 20:49:18 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCjq-00045o-2W; Tue, 03 Aug 2004 23:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsCjY-0003zP-VP for ipsec@megatron.ietf.org; Tue, 03 Aug 2004 23:46:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07755 for ; Tue, 3 Aug 2004 23:46:30 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsCmk-00089B-RD for ipsec@ietf.org; Tue, 03 Aug 2004 23:49:52 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i743h5g01695 for ; Tue, 3 Aug 2004 23:43:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i743hfVQ029449 for ; Tue, 3 Aug 2004 23:43:41 -0400 (EDT) Received: from pcp961896pcs.brnsbg01.in.comcast.net(68.58.143.151) by nutshell.tislabs.com via csmap (V6.0) id srcAAAaGa4F5; Tue, 3 Aug 04 23:43:34 -0400 Date: Tue, 03 Aug 2004 19:24:27 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------tuxxrwpqgpvqowzejiwo" X-Spam-Score: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------tuxxrwpqgpvqowzejiwo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Animals

----------tuxxrwpqgpvqowzejiwo Content-Type: text/html; name="New_MP3_Player.exe.htm" Content-Disposition: attachment; filename="New_MP3_Player.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: New_MP3_Player.exe
Virus name: W32/Bagle.ai@MM

----------tuxxrwpqgpvqowzejiwo Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------tuxxrwpqgpvqowzejiwo-- From ipsec-bounces@ietf.org Wed Aug 4 12:02:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i74J2jTb006765; Wed, 4 Aug 2004 12:02:46 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQlB-0001hO-DJ; Wed, 04 Aug 2004 14:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsQZf-0006rw-63 for ipsec@megatron.ietf.org; Wed, 04 Aug 2004 14:33:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26701 for ; Wed, 4 Aug 2004 14:33:13 -0400 (EDT) Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsQcy-0005an-TM for ipsec@ietf.org; Wed, 04 Aug 2004 14:36:42 -0400 Received: from EUR-MSG-02.europe.corp.microsoft.com ([65.53.192.43]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 4 Aug 2004 19:31:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [ipsec] Nested SAs in 2401bis Date: Wed, 4 Aug 2004 19:32:41 +0100 Message-ID: <579E83556A36E44EB2945CCE990B317401A760C7@EUR-MSG-02.europe.corp.microsoft.com> Thread-Topic: [ipsec] Nested SAs in 2401bis Thread-Index: AcQ43riWnWN7cAS2Ru6VW24AUNph9RBaDTJA From: "Michael Roe" To: "Karen Seo" , "Stephen Kent" , X-OriginalArrivalTime: 04 Aug 2004 18:31:59.0323 (UTC) FILETIME=[53FCC2B0:01C47A51] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1730652127==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1730652127== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U3RldmUsIEthcmVuLA0KDQpJJ3ZlIGJlZW4gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgaG93IG5lc3Rl ZCBTQXMgd29yayBpbiAyNDAxYmlzLA0Kbm93IHRoYXQgaXQgZG9lc27igJl0IGhhdmUgU0EgYnVu ZGxlcy4gSSB0aGluayBpdCB3b3VsZCBtYWtlIHRoZQ0KZG9jdW1lbnQgZWFzaWVyIHRvIHVuZGVy c3RhbmQgaWYgdGhlcmUgd2FzIGEgd29ya2VkIGV4YW1wbGUgb2YNCmFuIFNQRCB3aXRoIG5lc3Rl ZCBTQXMuDQoNCkhlcmUncyBob3cgSSAqdGhpbmsqIGl0J3Mgc3VwcHNvZWQgdG8gd29yay4gU3Vw cG9zZSB3ZSBoYXZlIGENCnRyYW5zcG9ydCBtb2RlIFNBIGZyb20gQSB0byBDLCB3aGljaCBpcyBj YXJyaWVkIG92ZXIgYSB0dW5uZWwNCm1vZGUgU0EgZnJvbSBBIHRvIEIuIChlLmcuIEEgaXMgYSBs YXB0b3Agb24gdGhlIHB1YmxpYyBpbnRlcm5ldCwNCkIgaXMgYSBmaXJld2FsbCB0aGF0IHByb3Rl Y3RzIGEgY29ycG9yYXRlIG5ldHdvcmssIEMgaXMgYSBzZXJ2ZXINCm9uIHRoZSBjb3Jwb3JhdGUg bmV0d29yayB0aGF0IGRlbWFuZHMgZW5kLXRvLWVuZCBhdXRoZW50aWNhdGlvbg0Kb2YgQTsgYWx0 ZXJuYXRpdmVseSwgQSBpcyBhIE1JUFY2IG1vYmlsZSBub2RlIGFuZCBCIGlzIGEgaG9tZQ0KYWdl bnQpDQoNCg0KKy0tLSsgICAgICstLS0rICArLS0tKw0KfCBBIHw9PT09PXwgQiB8ICB8IEMgfA0K fCAgIHwtLS0tLS0tLS0tLS18ICAgfA0KfCAgIHw9PT09PXwgICB8ICB8ICAgfA0KKy0tLSsgICAg ICstLS0rICArLS0tKw0KDQpUaGVuIEEncyBTUEQgbG9va3MgbGlrZSB0aGlzOg0KDQogICBsb2Nh bCByZW1vdGUgcHJvdG9jb2wgYWN0aW9uDQoxICBDICAgICBBICAgICAgKiAgICAgICAgQllQQVNT DQoyICBBICAgICBDICAgICAgSUNNUCxFU1AsSUtFIFBST1RFQ1QoRVNQLCB0dW5uZWwsIEEgdG8g QiwgYXV0aCtjb25mKQ0KMyAgQSAgICAgQyAgICAgICogICAgICAgIFBST1RFQ1QoRVNQLCB0cmFu c3BvcnQsIGF1dGgpDQo0ICBBICAgICBCICAgICAgSUNNUCxJS0UgQllQQVNTDQoNCkEncyB1bnBy b3RlY3RlZC1zaWRlIGZvcndhcmRpbmcgdGFibGUgaXMgc2V0IHNvIHRoYXQgb3V0Ym91bmQgcGFj a2V0cyBkZXN0aW5lZA0KZm9yIEMgYXJlIGxvb3BlZCBiYWNrIHRvIHRoZSBwcm90ZWN0ZWQgc2lk ZS4gQSdzIHByb3RlY3RlZCBzaWRlIGZvcndhcmRpbmcgdGFibGUNCmlzIHNldCBzbyB0aGF0IGlu Ym91bmQgRVNQIHBhY2tldHMgYXJlIGxvb3BlZCBiYWNrIHRvIHRoZSB1bnByb3RlY3RlZCBzaWRl Lg0KDQpBbiBvdXRib3VuZCBUQ1AgcGFja2V0IGZyb20gQSB0byBDIHdvdWxkIG1hdGNoIHJ1bGUg MyBhbmQgaGF2ZSBhIHRyYW5zcG9ydC1tb2RlDQpoZWFkZXIgcHJlcGVuZGVkIHRvIGl0LiBUaGUg dW5wcm90ZWN0ZWQtc2lkZSBmb3J3YXJkaW5nIHRhYmxlIHdvdWxkIHRoZW4gbG9vcA0KYmFjayB0 aGUgcGFja2V0LiBUaGUgcGFja2V0IGlzIGNvbXBhcmVkIGFnYWluc3QgU1BELUkgKHNlZSBmaWcu IDIgaW4gMjQwMWJpcyksDQptYXRjaGVzIHJ1bGUgMSwgYW5kIHNvIGlzIGFsbG93ZWQgYmFjayBp bi4gVGhlIHBhY2tldCBpcyBjb21wYXJlZCBhZ2FpbnN0IHRoZQ0KU1BEIGZvciBhIHRoaXJkIHRp bWUsIGFuZCB0aGlzIHRpbWUgaXQgbWF0Y2hlcyBydWxlIDIsIHNvIHRoYXQgaXQgZ2V0cyBhDQp0 dW5uZWwgbW9kZSBoZWFkZXIgYXBwZW5kZWQgdG8gaXQuIFRoaXMgdGltZSB0aGUgZm9yd2FyZGlu ZyB0YWJsZSBkb2Vzbid0DQpsb29wIGJhY2sgdGhlIHBhY2tldCwgYmVjYXVzZSB0aGUgb3V0ZXIg c291cmNlIGFkZHJlc3MgaXMgQiwgc28gdGhlIHBhY2tldA0KZ29lcyBvdXQgb250byB0aGUgd2ly ZS4NCg0KQW4gaW5ib3VuZCBUQ1AgcGFja2V0IGZyb20gQyB0byBBLCB3cmFwcGVkIGluIHR3byBF U1AgaGVhZGVycywgd291bGQgZmlyc3QNCm1hdGNoIDIgYW5kIGhhdmUgdGhlIHR1bm5lbCBtb2Rl IGhlYWRlciByZW1vdmVkLiBUaGUgcHJvdGVjdGVkLXNpZGUgZm9yd2FyZGluZw0KZnVuY3Rpb24g d291bGQgdGhlbiBzZW5kIGl0IGJhY2sgdG8gdGhlIHVucHJvdGVjdGVkIHNpZGUuIEl0IGlzIGNv bXBhcmVkIGFnYWluc3QNClNQRC1PIChzZWUgZmlnLiAzIGluIDI0MDFiaXMpIGFuZCBmb3VuZCB0 byBtYXRjaCBydWxlIDEsIHNvIGl0IGlzIGFsbG93ZWQgYmFjaw0Kb3V0LiBUaGUgcGFja2V0IGlz IGNvbXBhcmVkIGFnYWluc3QgdGhlIFNQRCBmb3IgdGhlIHRoaXJkIHRpbWUuIFRoaXMgdGltZSBp dA0KbWF0Y2hlcyBydWxlIDMgYW5kIGhhcyB0aGUgdHJhbnNwb3J0LW1vZGUgRVNQIGhlYWRlciBy ZW1vdmVkLiBUaGUgZm9yd2FyZGluZw0KZnVjbnRpb24gcGFzc2VzIGl0IHVwIHRvIHRoZSBuZXh0 IGxheWVyLCBiZWNhdXNlIGl0IGlzbuKAmXQgYW4gRVNQIHBhY2tldC4NCg0KSXMgdGhpcyByaWdo dD8NCg0KVGhhbmtzLA0KTWlrZQ0KDQpQUy4gSXQgd291bGQgYXBwZWFyIHRoYXQgaW4gYSBoaWdo LWFzc3VyYW5jZSBpbXBsZW1lbnRhdGlvbiwgdGhlIGZvcndhcmRpbmcgZnVuY3Rpb24NCm9uIHRo ZSB1bnByb3RlY3RlZCBzaWRlIGlzIHBhcnQgb2YgdGhlIHRydXN0ZWQgY29tcHV0aW5nIGJhc2Uu IEl0IGlzIHRydXN0ZWQgdG8gbG9vcA0KYmFjayBwYWNrZXRzIGRlc3RpbmVkIGZvciBDOyBpZiBp dCBkb2Vzbid0LCB0aGV5IHdvbid0IGdldCB0aGUgc2Vjb25kIGxheWVyIG9mIGNyeXB0bw0KYXBw bGllZCB0byB0aGVtIGFuZCB3aWxsIGJlIHZpc2libGUgdG8gYW4gZWF2ZXNkcm9wcGVyIG9uIHRo ZSBsaW5rIGJldHdlZW4gQSBhbmQgQi4NCg0K --===============1730652127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1730652127==-- From ipsec-bounces@ietf.org Thu Aug 5 02:07:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75976YV050070; Thu, 5 Aug 2004 02:07:07 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bse9m-0005O5-UT; Thu, 05 Aug 2004 05:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bse4e-0004Vv-NK for ipsec@megatron.ietf.org; Thu, 05 Aug 2004 04:58:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05019 for ; Thu, 5 Aug 2004 04:58:06 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bse85-0002pt-Tj for ipsec@ietf.org; Thu, 05 Aug 2004 05:01:43 -0400 Received: from brahma.intotoind.com (brahma.intotoind.com [127.0.0.1]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i758w0ib011334 for ; Thu, 5 Aug 2004 14:28:00 +0530 Received: from localhost (navink@localhost) by brahma.intotoind.com (8.12.11/8.12.8/Submit) with ESMTP id i758w0jD011331 for ; Thu, 5 Aug 2004 14:28:00 +0530 X-Authentication-Warning: brahma.intotoind.com: navink owned process doing -bs Date: Thu, 5 Aug 2004 14:28:00 +0530 (IST) From: Navin Kumar X-X-Sender: navink@brahma.intotoind.com To: ipsec@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] Implementation of AES-XCBC MAC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi, Is there any implementation of AES-XCBC MAC algorithm or any IPSec/IKE implementation which includes AES-XCBC MAC ? have a nice day, navin _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Aug 5 15:30:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i75MU9qA041281; Thu, 5 Aug 2004 15:30:10 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqWU-0001aY-TF; Thu, 05 Aug 2004 18:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BsqQb-0006YV-He for ipsec@megatron.ietf.org; Thu, 05 Aug 2004 18:09:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19999 for ; Thu, 5 Aug 2004 18:09:34 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BsqUA-0006H1-Cd for ipsec@ietf.org; Thu, 05 Aug 2004 18:13:19 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i75M8v7X020301; Thu, 5 Aug 2004 18:08:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <579E83556A36E44EB2945CCE990B317401A760C7@EUR-MSG-02.europe.corp.microsoft .com> References: <579E83556A36E44EB2945CCE990B317401A760C7@EUR-MSG-02.europe.corp.microsoft .com> Date: Thu, 5 Aug 2004 16:21:11 -0400 To: "Michael Roe" From: Stephen Kent Subject: Re: [ipsec] Nested SAs in 2401bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:32 PM +0100 8/4/04, Michael Roe wrote: >Steve, Karen, > >I've been trying to understand how nested SAs work in 2401bis, >now that it doesn't have SA bundles. I think it would make the >document easier to understand if there was a worked example of >an SPD with nested SAs. thanks for constructing an example. we'll incorporate it, with some minor changes, into an appendix. >Here's how I *think* it's suppsoed to work. Suppose we have a >transport mode SA from A to C, which is carried over a tunnel >mode SA from A to B. (e.g. A is a laptop on the public internet, >B is a firewall that protects a corporate network, C is a server >on the corporate network that demands end-to-end authentication >of A; alternatively, A is a MIPV6 mobile node and B is a home >agent) > > >+---+ +---+ +---+ >| A |=====| B | | C | >| |------------| | >| |=====| | | | >+---+ +---+ +---+ > >Then A's SPD looks like this: > > local remote protocol action >1 C A * BYPASS I would change this entry to make the protocol field = ESP, to keep it tightly constrained, and to make it clear that what we want is to loop back packets that have already had ESP applied. >2 A C ICMP,ESP,IKE PROTECT(ESP, tunnel, A to B, auth+conf) >3 A C * PROTECT(ESP, transport, auth) >4 A B ICMP,IKE BYPASS > >A's unprotected-side forwarding table is set so that outbound packets destined >for C are looped back to the protected side. A's protected side >forwarding table >is set so that inbound ESP packets are looped back to the unprotected side. > >An outbound TCP packet from A to C would match rule 3 and have a >transport-mode >header prepended to it. The unprotected-side forwarding table would then loop >back the packet. The packet is compared against SPD-I (see fig. 2 in 2401bis), >matches rule 1, and so is allowed back in. as noted above, if the goal is to bypass ONLY the packets from C that are being protected via this nesting, I'd construct a more restrictive SPD entry for #1, one that requires the packet to have ESP as the declared protocol. >The packet is compared against the >SPD for a third time, and this time it matches rule 2, so that it gets a >tunnel mode header appended to it. This time the forwarding table doesn't >loop back the packet, because the outer source address is B, so the packet >goes out onto the wire. > >An inbound TCP packet from C to A, wrapped in two ESP headers, would first >match 2 and have the tunnel mode header removed. The protected-side forwarding >function would then send it back to the unprotected side. Need to say why the protected side forwarding table loops it back, e.g., because the protocol is ESP, indicative of nesting. >It is compared against >SPD-O (see fig. 3 in 2401bis) and found to match rule 1, so it is allowed back >out. The packet is compared against the SPD for the third time. This time it >matches rule 3 and has the transport-mode ESP header removed. The forwarding >fucntion passes it up to the next layer, because it isn't an ESP packet. > >Is this right? yes. as I said, I'd make a minor change to the first SPD entry, and I'd add in a description of forwarding table entries on each side to make it as clear as possible, but this is a good example and I agree that it will help explain how to achieve nesting. > >Thanks, >Mike > >PS. It would appear that in a high-assurance implementation, the >forwarding function >on the unprotected side is part of the trusted computing base. It is >trusted to loop >back packets destined for C; if it doesn't, they won't get the >second layer of crypto >applied to them and will be visible to an eavesdropper on the link >between A and B. agreed. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 7 13:38:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77KcQ7u073009; Sat, 7 Aug 2004 13:38:27 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtXve-0004gv-1T; Sat, 07 Aug 2004 16:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtXt3-0004J2-M4 for ipsec@megatron.ietf.org; Sat, 07 Aug 2004 16:33:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21234 for ; Sat, 7 Aug 2004 16:33:51 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtXx2-0001KD-5r for ipsec@ietf.org; Sat, 07 Aug 2004 16:38:00 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i77KUKg08594 for ; Sat, 7 Aug 2004 16:30:20 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i77KV1aV004675 for ; Sat, 7 Aug 2004 16:31:01 -0400 (EDT) Received: from rs15.luxsci.com(65.61.166.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAAU1aqij; Sat, 7 Aug 04 16:30:59 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i77KXekq014447 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 7 Aug 2004 15:33:40 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i77KW0MP014288; Sat, 7 Aug 2004 20:32:00 GMT Message-Id: <200408072032.i77KW0MP014288@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sat, 07 Aug 2004 20:32:00 +0000 From: "William Dixon" To: "'Michael Myers'" Subject: RE: [Ipsec] OCSP in IKEv2 Date: Sat, 7 Aug 2004 13:30:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-Lux-Comment: LuxSci remailer message ID code - 1091910720-1002100.42967585 X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Mike, please correct my understanding here if I'm making a mistake. You mentioned peer-to-peer applicability which prompted my investigation. The summary is that your draft should be more clear about the risks of using OCSP inband with IKEv2 in peer-to-peer scenarios, such as not recommend it. I think using OCSP inband in IKEv2 for peer-to-peer would not be recommended - as it is limited by the classic problem of how an IKE initiator knows which credential or trust anchor to expect from the responder. There are deployment scenarios where this situation is solvable - such as IKE negotiation to my own corporate gateway, or generally, any case where I can configure an IPsec policy to use a particular CA or root for a given destination address/range/etc. But in the open Internet or in general peer-to-peer scenarios, I won't know which cert or trust anchor to expect from a given destination. I'm not aware of an actual recommendation for peer-to-peer IKEv1/2 authentication. We might get a chance to address this in the IKEv2 security considerations draft (early stages w/Scott Kelly). The risk is to the initiator of a malicious responder when forced to use that responder to relay/forward OCSP messages to the backend OCSP server (the OCSP responder). I don't see the draft really explains how the proposed design notes this should only be used where the IKE initiator is safe from IKE responder attacks. And the circumstance where the responder is able to take advantage of the IKE initiator's limited knowledge of what credential to expect. >From RFC 2560: All definitive [OCSP] response messages SHALL be digitally signed. The key used to sign the response MUST belong to one of the following: -- the CA who issued the certificate in question Clearly if I'm negotiating IKEv2 with a random Internet peer, my use of OCSP inband with IKEv2 can allow the initiator to accept any certificate from any pre-configured trust anchor. If we follow the server-auth SSL deployment model for client certs it could be any of 130+ root CAs, or whatever someone has been able to stuff into their trusted root store. If we don't depend upon pre-configured roots, then why would we need to use OCSP ? If you would suggests that we depend on PKI-enabled DNS for hints about which credential to expect, then please mention this in your draft. Though for peer-to-peer scenarios, it may be an insurmountable barrier to update any ISP's DNS that I'm connected to with my client PKI info. In fact I probably don't want to do that if I have several certs from issuers/roots that would identify my business relationships. Cheers, Wm William Dixon, Founder, Principal Consultant V6 Security, Inc. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Michael Myers > Sent: Saturday, August 07, 2004 10:22 AM > To: ipsec@ietf.org > Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com > Subject: [Ipsec] OCSP in IKEv2 > > All, > > The intersection of IPSEC with PKI is of recent interest. > Towards that dialog, Hannes Tschofenig and I have proposed > how OCSP could be used to deliver certificate status in-band > to IKEv2. We were driven first to consider the important use > case of EAP (i.e. the Road Warrior) but also considered the > Peer-to-Peer case in order to develop a general solution. > > This individual submission I-D can be found at: > http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-os cp-00.txt > > Two new certificate encoding types are proposed: OCSP > Responder Hash and OCSP Response. An OCSP Responder Hash is > sent in a CERTREQ, computed as trust anchor hashes are > computed but sent in a separate CERTREQ. A corresponding > OCSP Response is sent back in its own CERT payload and in the > context of the CERT payload carrying the participant's > certificate. That is, an IKEv2 participant sends both its > cert and that cert's status in separate CERT payloads. > > Hannes and I look forward to your comments and debate. I've > cross-posted due to intersecting interests but please post > comments to the IPSEC list only. > > Michael Myers > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 7 15:52:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i77MqKHY081023; Sat, 7 Aug 2004 15:52:21 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bta0p-0004FU-Fd; Sat, 07 Aug 2004 18:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtZzo-0003zX-Tx for ipsec@megatron.ietf.org; Sat, 07 Aug 2004 18:49:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27968 for ; Sat, 7 Aug 2004 18:48:57 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bta3n-00033x-Ln for ipsec@ietf.org; Sat, 07 Aug 2004 18:53:09 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i77MjLg18477 for ; Sat, 7 Aug 2004 18:45:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i77Mk2jP015401 for ; Sat, 7 Aug 2004 18:46:02 -0400 (EDT) Received: from rs15.luxsci.com(65.61.166.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmKaOeE; Sat, 7 Aug 04 18:46:00 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i77MmfnN003335 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 7 Aug 2004 17:48:41 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i77Mk1i0003036; Sat, 7 Aug 2004 22:46:01 GMT Message-Id: <200408072246.i77Mk1i0003036@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sat, 07 Aug 2004 22:46:01 +0000 From: "William Dixon" To: "'Michael Myers'" Subject: RE: [Ipsec] OCSP in IKEv2 Date: Sat, 7 Aug 2004 15:45:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <200408072032.i77KW0MP014288@rs15.luxsci.com> X-Lux-Comment: LuxSci remailer message ID code - 1091918761-6585177.54749668 X-Spam-Score: 0.8 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org To clarify after discussing with Michael about this. My comments were based on two concerns for the authors: 1. does adding OCSP inband w/in IKEv2 create a weakness in the IKE authentication properties when certificate status is decided out of band (with OCSP, to avoid the CRL vs. OCSP points) My comments below were focused particularly on usage in peer-to-peer scenarios. Which I now realize also apply to CRLs inband. Rereading the draft again, it's pretty clear. The OCSP response is sent at the same time the responders CERT payload is provided. But I'm wondering why there is a "MUST not ignore the OCSP response payload" statement in the draft. I don't think an error message MUST be sent. Generally IKEv2-14 authentication errors or other failures do not require error notifications to the peer: "An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE_SA to the same authenticated identity." 2. what use cases (scenarios) are compelling for the WG to take up this work ? Specifically what are the IKEv2 peer-to-peer scenarios ? After talking with Michael about this, it was apparent that any time the OCSP responder is not directly reachable by one of the peers and is reachable through the peer, OCSP inband within IKEv2 would be necessary. We came up with a few corporate client-server scenarios easily. The use of PKI for peer-to-peer authentication & consequent authorization is more the question, and is not specifically related to using OCSP or CRLs inband. I would imagine then there is a 1:1 mapping with scenarios where CRLs have to be passed inband. So the answer to #2 may be irrelevant, it's more the issue that the IKEv2 standard should provide equal inband support for standard PKIX WG certificate revocation/status checking mechanisms. I don't know why this was omitted from IKEv2 earlier or if it was just lack of a proposal. Perhaps the authors familiar with OCSP deployment can identify unique OCSP inband scenarios - clearly whenever CRLs get large would be one, and potentially the must-have scenario, as there is not yet a proposal for IKE MTU detection & fragmentation avoidance. So #2 becomes a political or process question - do we adopt OCSP support in IKEv2 at this point, advance this draft as an addendum, or maybe incorporate it into the PKI4IPsec work. Hope this helps. Cheers, Wm > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of William Dixon > Sent: Saturday, August 07, 2004 1:31 PM > To: 'Michael Myers' > Cc: ipsec@lists.tislabs.com > Subject: RE: [Ipsec] OCSP in IKEv2 > > Hi Mike, please correct my understanding here if I'm making a > mistake. You mentioned peer-to-peer applicability which > prompted my investigation. The summary is that your draft > should be more clear about the risks of using OCSP inband > with IKEv2 in peer-to-peer scenarios, such as not recommend it. > > I think using OCSP inband in IKEv2 for peer-to-peer would not > be recommended > - as it is limited by the classic problem of how an IKE > initiator knows which credential or trust anchor to expect > from the responder. There are deployment scenarios where this > situation is solvable - such as IKE negotiation to my own > corporate gateway, or generally, any case where I can > configure an IPsec policy to use a particular CA or root for > a given destination address/range/etc. But in the open > Internet or in general peer-to-peer scenarios, I won't know > which cert or trust anchor to expect from a given > destination. I'm not aware of an actual recommendation for > peer-to-peer IKEv1/2 authentication. We might get a chance to > address this in the IKEv2 security considerations draft > (early stages w/Scott Kelly). > > The risk is to the initiator of a malicious responder when > forced to use that responder to relay/forward OCSP messages > to the backend OCSP server (the OCSP responder). I don't see > the draft really explains how the proposed design notes this > should only be used where the IKE initiator is safe from IKE > responder attacks. And the circumstance where the responder > is able to take advantage of the IKE initiator's limited > knowledge of what credential to expect. > > >From RFC 2560: > All definitive [OCSP] response messages SHALL be digitally > signed. The key > used to sign the response MUST belong to one of the following: > > -- the CA who issued the certificate in question > > Clearly if I'm negotiating IKEv2 with a random Internet peer, > my use of OCSP inband with IKEv2 can allow the initiator to > accept any certificate from any pre-configured trust anchor. > If we follow the server-auth SSL deployment model for client > certs it could be any of 130+ root CAs, or whatever someone > has been able to stuff into their trusted root store. If we > don't depend upon pre-configured roots, then why would we > need to use OCSP ? If you would suggests that we depend on > PKI-enabled DNS for hints about which credential to expect, > then please mention this in your draft. Though for > peer-to-peer scenarios, it may be an insurmountable barrier > to update any ISP's DNS that I'm connected to with my client > PKI info. In fact I probably don't want to do that if I have > several certs from issuers/roots that would identify my > business relationships. > > Cheers, > Wm > William Dixon, Founder, Principal Consultant > V6 Security, Inc. > > > -----Original Message----- > > From: ipsec-bounces@ietf.org > [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Michael Myers > > Sent: Saturday, August 07, 2004 10:22 AM > > To: ipsec@ietf.org > > Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com > > Subject: [Ipsec] OCSP in IKEv2 > > > > All, > > > > The intersection of IPSEC with PKI is of recent interest. > > Towards that dialog, Hannes Tschofenig and I have proposed how OCSP > > could be used to deliver certificate status in-band to > IKEv2. We were > > driven first to consider the important use case of EAP > (i.e. the Road > > Warrior) but also considered the Peer-to-Peer case in order > to develop > > a general solution. > > > > This individual submission I-D can be found at: > > http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-os > cp-00.txt > > > > Two new certificate encoding types are proposed: OCSP > Responder Hash > > and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, > > computed as trust anchor hashes are computed but sent in a separate > > CERTREQ. A corresponding OCSP Response is sent back in its > own CERT > > payload and in the context of the CERT payload carrying the > > participant's certificate. That is, an IKEv2 participant > sends both > > its cert and that cert's status in separate CERT payloads. > > > > Hannes and I look forward to your comments and debate. I've > > cross-posted due to intersecting interests but please post > comments to > > the IPSEC list only. > > > > Michael Myers > > > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Aug 7 17:11:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i780BAt6085676; Sat, 7 Aug 2004 17:11:11 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtbFJ-0006R3-BE; Sat, 07 Aug 2004 20:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BtbF2-0006K7-ME for ipsec@megatron.ietf.org; Sat, 07 Aug 2004 20:08:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01608 for ; Sat, 7 Aug 2004 20:08:46 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BtbJ3-0004Ay-9q for ipsec@ietf.org; Sat, 07 Aug 2004 20:12:57 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7805Gg22507 for ; Sat, 7 Aug 2004 20:05:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7805vbw021739 for ; Sat, 7 Aug 2004 20:05:57 -0400 (EDT) Received: from rs15.luxsci.com(65.61.166.71) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2laqDQ; Sat, 7 Aug 04 20:05:55 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.10) with ESMTP id i7808hhQ014628 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 7 Aug 2004 19:08:43 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.10/Submit) id i780612F014218; Sun, 8 Aug 2004 00:06:01 GMT Message-Id: <200408080006.i780612F014218@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sun, 08 Aug 2004 00:06:01 +0000 From: "William Dixon" To: Date: Sat, 7 Aug 2004 17:04:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Lux-Comment: LuxSci remailer message ID code - 1091923561-6307671.9069014 X-Spam-Score: 0.8 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Subject: [Ipsec] IKEv2 traffic selector negotiation examples X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org One of the things that was missing during IKEv1 development was a set of clear examples of expected negotiation results between two host IPsec policies (SPD traffic selectors in QM). How would we document this for IKEv2 under 2401 or 2401bis rules ? Or should we ? I think we will have greater interoperability if there is a consistent set of test cases that everyone uses for interop testing. This is primarily a concern with overlapping SPD entries when IPsec policy is deployed to secure host-to-host communication. For example, IKEv2-14 section 2.9 talks about selector negotiation, but not in sufficient detail for me to know exactly how each of the client QM traffic selector proposals is responded to by the server below, for different client IP source addresses. And it is more complicated now that IKEv2 allows multiple SAs with the same selectors. Client policy: >From Any IP to My IP all traffic -> discard >From My IP to Server IP subnet all traffic -> protect_AH_ESP >From My IP to Server IP TCP src 1028, dst 4242 -> protect_ESP_only >From My IP to Any IP UDP src *, dst 137-139 -> discard (block outbound netbios) >From Any IP to My IP ICMP Type 3 -> bypass (for TCP PMTU detection) >From My subnet to Multicast Addr1 UDP src *, dst 4242 -> bypass (receive multicast app from local sender) Server policy: >From Any to Any all traffic -> discard (including multicast & broadcast) >From Any to My IP Subnet all traffic -> protect_AH_ESP >From Any to My IP all traffic -> protect_ESP_only >From Any to My IP TCP/UDP src *, dst 135-139 -> discard (block inbound RPC endpoint mapper & NetBIOS) >From My Subnet to My IP TCP src *, dst 445 -> bypass (expose Windows filesharing to my local subnet) >From Any to My IP TCP src *, dst 80 -> bypass (allow web server for anyone) >From Any to My IP TCP src *, dst 22 -> bypass (allow SSH incoming connections outside of IPsec to anyone) >From Any to My IP ICMP Type 3 -> bypass (allow incoming ICMP DU PMTU messages for TCP) >From My IP to Any IP TCP src *, dst 80 -> bypass (Allow outbound web browsing outside of IPsec) Definitions: My IP = My unicast IP address - either statically defined or dynamically defined based on the DHCP assigned address. Any = Any unicast IP address when it is a source address, and Any IP address when it is a destination address to include unicast, multicast or broadcast addresses. My subnet = really any subnet that I can specifically define, perhaps commonly the subnets used by local LAN or my company. I didn't fully specify inbound & outbound selectors for each case for brevity. The full policy specification would. thanks, Wm _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Aug 8 20:39:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i793dGRH018582; Sun, 8 Aug 2004 20:39:17 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu0vC-0006c8-PY; Sun, 08 Aug 2004 23:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bu0ud-0006XP-Sz for ipsec@megatron.ietf.org; Sun, 08 Aug 2004 23:33:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13062 for ; Sun, 8 Aug 2004 23:33:25 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bu0ys-0004ny-Ii for ipsec@ietf.org; Sun, 08 Aug 2004 23:37:51 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i793Tsg18201 for ; Sun, 8 Aug 2004 23:29:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i793Ub3C008495 for ; Sun, 8 Aug 2004 23:30:37 -0400 (EDT) Received: from pcp961896pcs.brnsbg01.in.comcast.net(68.58.143.151) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdWayLq; Sun, 8 Aug 04 23:30:34 -0400 Date: Sun, 08 Aug 2004 19:12:03 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jhypmcztlynavojtlhor" X-Spam-Score: 1.9 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Re: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------jhypmcztlynavojtlhor Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >Predators

----------jhypmcztlynavojtlhor Content-Type: text/html; name="Dog.exe.htm" Content-Disposition: attachment; filename="Dog.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Dog.exe
Virus name: W32/Bagle.ai@MM

----------jhypmcztlynavojtlhor Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------jhypmcztlynavojtlhor-- From ipsec-bounces@ietf.org Mon Aug 9 10:25:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79HPUcC092613; Mon, 9 Aug 2004 10:25:31 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuDlX-0005B3-7m; Mon, 09 Aug 2004 13:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuDhf-0004GA-NW for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 13:12:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14615 for ; Mon, 9 Aug 2004 13:12:51 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuDm1-0000cx-4f for ipsec@ietf.org; Mon, 09 Aug 2004 13:17:26 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79H9Ig28428 for ; Mon, 9 Aug 2004 13:09:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79HA3u2008449 for ; Mon, 9 Aug 2004 13:10:03 -0400 (EDT) Received: from ool-435222a6.dyn.optonline.net(67.82.34.166) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7NaOBq; Mon, 9 Aug 04 13:09:53 -0400 Date: Mon, 09 Aug 2004 13:23:26 -0500 To: "Ipsec" From: "Radia.Perlman" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------bzdgutbftnabgyffeezj" X-Spam-Score: 1.3 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------bzdgutbftnabgyffeezj Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price

----------bzdgutbftnabgyffeezj Content-Type: text/html; name="price.zip.htm" Content-Disposition: attachment; filename="price.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: price.zip
Virus name: JS/IllWill

----------bzdgutbftnabgyffeezj Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------bzdgutbftnabgyffeezj-- From ipsec-bounces@ietf.org Mon Aug 9 11:44:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79IibQ4001850; Mon, 9 Aug 2004 11:44:38 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuF2r-00083K-HX; Mon, 09 Aug 2004 14:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuEhu-00038d-Pk for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 14:17:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23058 for ; Mon, 9 Aug 2004 14:17:13 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuEmG-00038b-4o for ipsec@ietf.org; Mon, 09 Aug 2004 14:21:46 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79IDag08211 for ; Mon, 9 Aug 2004 14:13:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79IEATl018926 for ; Mon, 9 Aug 2004 14:14:10 -0400 (EDT) Received: from unknown(12.36.40.105) by nutshell.tislabs.com via csmap (V6.0) id srcAAAITaa8K; Mon, 9 Aug 04 14:14:08 -0400 Date: Mon, 09 Aug 2004 13:16:52 -0600 To: "Ipsec" From: "Ebooth" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------nldmbglstvgblkjatiyy" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------nldmbglstvgblkjatiyy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price

----------nldmbglstvgblkjatiyy Content-Type: text/html; name="08_price.zip.htm" Content-Disposition: attachment; filename="08_price.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: 08_price.zip
Virus name: JS/IllWill

----------nldmbglstvgblkjatiyy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------nldmbglstvgblkjatiyy-- From ipsec-bounces@ietf.org Mon Aug 9 12:27:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79JRAp9006831; Mon, 9 Aug 2004 12:27:10 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFVH-0004pm-6p; Mon, 09 Aug 2004 15:08:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuFI4-0002jx-3c for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 14:54:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26960 for ; Mon, 9 Aug 2004 14:54:34 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuFMR-0004Eb-28 for ipsec@ietf.org; Mon, 09 Aug 2004 14:59:08 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79Ioug11891 for ; Mon, 9 Aug 2004 14:50:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79Ipcfa025014 for ; Mon, 9 Aug 2004 14:51:38 -0400 (EDT) Received: from unknown(200.244.132.130) by nutshell.tislabs.com via csmap (V6.0) id srcAAAM_aa0W; Mon, 9 Aug 04 14:51:34 -0400 Date: Mon, 09 Aug 2004 15:54:48 -0300 To: "Ipsec" From: "Jeremy.de" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ujqzyteekdlectaubghi" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ujqzyteekdlectaubghi Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price

----------ujqzyteekdlectaubghi Content-Type: text/html; name="price2.zip.htm" Content-Disposition: attachment; filename="price2.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: price2.zip
Virus name: JS/IllWill

----------ujqzyteekdlectaubghi Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ujqzyteekdlectaubghi-- From ipsec-bounces@ietf.org Mon Aug 9 13:55:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Kt83D015748; Mon, 9 Aug 2004 13:55:09 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuGy2-0000gJ-LL; Mon, 09 Aug 2004 16:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuG09-00069h-EM for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 15:40:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03597 for ; Mon, 9 Aug 2004 15:40:07 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuG4W-0005Z5-RU for ipsec@ietf.org; Mon, 09 Aug 2004 15:44:42 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79JaYg15572 for ; Mon, 9 Aug 2004 15:36:34 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79Jawi1001685 for ; Mon, 9 Aug 2004 15:36:58 -0400 (EDT) Received: from unknown(66.220.193.142) by nutshell.tislabs.com via csmap (V6.0) id srcAAAhBayrd; Mon, 9 Aug 04 15:36:55 -0400 Date: Mon, 09 Aug 2004 12:37:50 -0800 To: "Ipsec" From: "Ddukes" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------otmxuucgbocfdpqyuurt" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------otmxuucgbocfdpqyuurt Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit price

----------otmxuucgbocfdpqyuurt Content-Type: text/html; name="08_price.zip.htm" Content-Disposition: attachment; filename="08_price.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: 08_price.zip
Virus name: JS/IllWill

----------otmxuucgbocfdpqyuurt Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------otmxuucgbocfdpqyuurt-- From ipsec-bounces@ietf.org Mon Aug 9 16:45:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79Nj8Y6033666; Mon, 9 Aug 2004 16:45:08 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJhI-00058h-MI; Mon, 09 Aug 2004 19:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJdO-0004Zg-RP for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 19:32:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03338 for ; Mon, 9 Aug 2004 19:32:52 -0400 (EDT) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuJho-0005MH-9f for ipsec@ietf.org; Mon, 09 Aug 2004 19:37:29 -0400 Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i79NWj886468 for ; Mon, 9 Aug 2004 16:32:45 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: Date: Mon, 9 Aug 2004 16:31:53 -0700 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) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Subject: [Ipsec] RE: OCSP in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org All BTW, the ADs have agreed this I-D will be placed onto the Standards Track, subject to resolution of comments. I am sure there are folks out there with an opinion. Mike -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of Michael Myers Sent: Saturday, August 07, 2004 10:22 AM To: ipsec@ietf.org Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com Subject: [Ipsec] OCSP in IKEv2 All, The intersection of IPSEC with PKI is of recent interest. Towards that dialog, Hannes Tschofenig and I have proposed how OCSP could be used to deliver certificate status in-band to IKEv2. We were driven first to consider the important use case of EAP (i.e. the Road Warrior) but also considered the Peer-to-Peer case in order to develop a general solution. This individual submission I-D can be found at: http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-00.txt Two new certificate encoding types are proposed: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, computed as trust anchor hashes are computed but sent in a separate CERTREQ. A corresponding OCSP Response is sent back in its own CERT payload and in the context of the CERT payload carrying the participant's certificate. That is, an IKEv2 participant sends both its cert and that cert's status in separate CERT payloads. Hannes and I look forward to your comments and debate. I've cross-posted due to intersecting interests but please post comments to the IPSEC list only. Michael Myers _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 9 16:58:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i79NwtP4034576; Mon, 9 Aug 2004 16:58:55 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJyq-00018c-Eu; Mon, 09 Aug 2004 19:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuJrs-0008ER-Dn for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 19:47:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04513 for ; Mon, 9 Aug 2004 19:47:50 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuJwH-0005gr-Vy for ipsec@ietf.org; Mon, 09 Aug 2004 19:52:27 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i79NiGg27693 for ; Mon, 9 Aug 2004 19:44:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79NivU9003824 for ; Mon, 9 Aug 2004 19:44:57 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPMaqzh; Mon, 9 Aug 04 19:44:53 -0400 Received: from [10.84.130.138] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i79NlX7b027928; Mon, 9 Aug 2004 19:47:36 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200408080006.i780612F014218@rs15.luxsci.com> References: <200408080006.i780612F014218@rs15.luxsci.com> Date: Mon, 9 Aug 2004 19:46:59 -0400 To: "William Dixon" From: Stephen Kent Subject: Re: [Ipsec] IKEv2 traffic selector negotiation examples Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:04 PM -0700 8/7/04, William Dixon wrote: >One of the things that was missing during IKEv1 development was a set of >clear examples of expected negotiation results between two host IPsec >policies (SPD traffic selectors in QM). How would we document this for IKEv2 >under 2401 or 2401bis rules ? Or should we ? I think we will have greater >interoperability if there is a consistent set of test cases that everyone >uses for interop testing. This is primarily a concern with overlapping SPD >entries when IPsec policy is deployed to secure host-to-host communication. > I think thus would be useful, but only for 2401bis, since 2401 and IKEv2 don't fit well together. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Aug 9 19:07:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A27ITc046929; Mon, 9 Aug 2004 19:07:18 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLxX-0008CE-TT; Mon, 09 Aug 2004 22:01:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuLuX-0007Sm-Vd for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 21:58:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16852 for ; Mon, 9 Aug 2004 21:58:43 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuLyy-0008WL-RH for ipsec@ietf.org; Mon, 09 Aug 2004 22:03:22 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7A1t5g04801 for ; Mon, 9 Aug 2004 21:55:06 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79LW845018399 for ; Mon, 9 Aug 2004 17:32:08 -0400 (EDT) Received: from 135090050160.paradyne.com(135.90.50.160) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8Eaa7J; Mon, 9 Aug 04 17:32:05 -0400 Date: Mon, 09 Aug 2004 17:37:20 -0500 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lspuoumffvpmhcuqqwzp" X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------lspuoumffvpmhcuqqwzp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price

----------lspuoumffvpmhcuqqwzp Content-Type: text/html; name="newprice.zip.htm" Content-Disposition: attachment; filename="newprice.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: newprice.zip
Virus name: JS/IllWill

----------lspuoumffvpmhcuqqwzp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------lspuoumffvpmhcuqqwzp-- From ipsec-bounces@ietf.org Mon Aug 9 19:38:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A2csNE051805; Mon, 9 Aug 2004 19:38:59 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMLZ-0004kW-M6; Mon, 09 Aug 2004 22:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuMG0-0003lx-3M for ipsec@megatron.ietf.org; Mon, 09 Aug 2004 22:20:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18964 for ; Mon, 9 Aug 2004 22:20:53 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuMKS-0000bx-0N for ipsec@ietf.org; Mon, 09 Aug 2004 22:25:32 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7A2HHg08784 for ; Mon, 9 Aug 2004 22:17:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i79Kx89k014146 for ; Mon, 9 Aug 2004 16:59:09 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAAstaWMB; Mon, 9 Aug 04 16:59:06 -0400 Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i79L1p7X022103 for ; Mon, 9 Aug 2004 17:01:52 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 9 Aug 2004 17:01:36 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Subject: [Ipsec] new ICMP text for 2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Folks, The 2401bis text proposed below is based on a draft proposal sent on 4/13 (plus some text from the original issue 91 write up in Oct 2003) and reflects list discussions with: - Mark Duffy about case 2 (whether or not the receiver should be doing the kind of checking we propose) -- we believe the receiver MUST do this checking. (see Steve Kent's email of May 7 and May 10) - Mark Duffy re: removal of text re: "fast path and slow path" -- we agreed to remove it. - Rich Graveman re: clarifying that we believe this proposal would work with ICMPv6 - Mark Duffy and Mohan Parthasarathy re: clarifying what we meant by checking "to ensure that the enclosed packet is consistent with its source" and "to see if the selector fields in the enclosed packet match those of an existing SA, etc. - one BIG (but accommodating) change is that we dropped the requirement to use a dedicated SA for ICMP error messages -------- A. The following text will be placed in Section 6. "ICMP Processing". This section discusses IPsec handling of ICMP traffic. Please note that: a. There are two categories of ICMP traffic -- error messages (e.g., type = destination unreachable) and non-error messages (e.g., type = echo). This section applies exclusively to error messages. Non-error ICMP messages should be explicitly accounted for in the SPD. b. This section applies to ICMPv6 as well as to ICMPv4. c. A mechanism SHOULD be provided to allow an administrator to cause ICMP messages (selected, all, none) to be logged as an aid to problem diagnosis." 6.1 ICMP message not protected by IPsec An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial or degradation of service. This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus there is also a motivation for accepting and acting upon unauthenticated ICMP messages. To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic. This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code. Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size." [See Section xxx for recommendations.] 6.2 ICMP messages protected by IPsec (This section does NOT apply to ICMP traffic that is bypassed or consumed on the ciphertext side of the IPsec boundary.) Both the payload of an ICMP error packet, and the header of the ICMP packet require checking from an access control perspective. If one of these packets is forwarded to a host behind a security gateway, the receiving host IP implementation will make decisions based on the payload, i.e., the header of the packet that purportedly triggered the error response. Thus an IPsec implementation SHOULD to try to ensure that this header information is consistent with the IPsec peer that transmitted the ICMP packet. If this sort of check is not performed, then for example, anyone with whom the receiving IPsec system (A) has an active SA could send an ICMP destination dead message that refers to any host/net with which A is currently communicating, and thus effect a highly efficient DoS attack re communication with other peers of A. Normal IPsec receiver processing of traffic is not sufficient to protect against such attacks. If no SA exists that matches the traffic selectors associated with an ICMP error packet, then an IPsec implementation MUST map an outbound ICMP error packet to the SA that would carry the return traffic associated with the packet that triggered the ICMP error packet. (This allows an administrator to explicitly account for ICMP error packets in SPD entries, causing them to bypass the payload check noted below. This results in reduced security for hosts, as noted above.) This requires an IPsec implementation to detect outbound ICMP error packets that map to no extant SA, and treat them specially with regard to SA creation and lookup. The implementation extracts the header for the packet that triggered the error (from the ICMP message payload), reverses the source and destination IP address fields, extracts the protocol field, and reverses the port fields (if accessible). it them uses this extracted information to locate an appropriate, active outbound SA. This implies that there must be an active SA for that traffic. An IPsec implementation MUST NOT create a new SA carry ICMP traffic error packets as a result of an attempt to transmit such packets. If an IPsec implementation receives an IMCP error packet that does not match the SA traffic selectors, the receiver also MUST process the received message in a special fashion. Specifically, the receiver must extract the header of the triggering packet from the ICMP payload, and reverse fields as described above to determine if the packet is consistent with the selectors for the SA via which it was received. Only then is it safe to forward the ICMP message to the destination. The sender and receiver MUST support the following processing when ICMP error packets are sent over SAs with selectors that DO NOT match these packets: a. If an IPsec implementation encounters an outbound ICMP error message for which no applicable SA exists, it extracts the header info from the payload, reverses the source and destination IP addresses, and, if accessible, the source and destination port fields. It uses the address, protocol, and port fields (if available) to perform an SPD lookup. If an appropriate, extant SA is found, the packet is transmitted via this SA. (No new SA will be created to carry an ICMP error packet.) If no suitable SA exists, the ICMP packet is dropped, an auditable event. b. If an IPsec implementation receives an ICMP error packet on an SA and the traffic selectors for that SA do not allow for the packet, a secondary check is performed. The receiver extracts the header info from the ICMP payload, reverses the source and destination IP addresses, and, if accessible, the source and destination port fields. The resulting values are compared to the selectors for the SA via which the ICMP packet was received. If the selectors match, the packet is forwarded, otherwise it it is discarded, and auditable event. B. The following text will be added to Security Considerations: An IPsec implementation is configured to pass ICMP error packets over SAs based on the ICMP header values, without checking the header info from the ICMP packet payload. For example, a tunnel may be created between two sites that uses ANY for protocol and port fields and IP address ranges that encompass all systems behind the security gateways serving each site. In such cases, the hosts behind the security gateways will be vulnerable to DoS attacks that might be launched by other peers with which there are active SAs. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 02:57:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7A9v5mJ045623; Tue, 10 Aug 2004 02:57:06 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuTLN-0002M1-W9; Tue, 10 Aug 2004 05:54:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuTFC-0000sd-Qc for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 05:48:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07823 for ; Tue, 10 Aug 2004 05:48:31 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuTJh-0000Md-AW for ipsec@ietf.org; Tue, 10 Aug 2004 05:53:14 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7A9iwg28644 for ; Tue, 10 Aug 2004 05:44:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7A9jgdh007801 for ; Tue, 10 Aug 2004 05:45:42 -0400 (EDT) Received: from goliath.siemens.de(192.35.17.28) by nutshell.tislabs.com via csmap (V6.0) id srcAAAH3ayop; Tue, 10 Aug 04 05:45:39 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i7A9mQ0T020906 for ; Tue, 10 Aug 2004 11:48:26 +0200 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i7A9mFNW005034 for ; Tue, 10 Aug 2004 11:48:25 +0200 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 10 Aug 2004 11:48:15 +0200 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0468649E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'ipsec@lists.tislabs.com'" Subject: [Ipsec] OCSP in IKEv2 Date: Tue, 10 Aug 2004 11:47:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi william, thanks for your response. the term peer-to-peer is a bit overloaded and you understood it as a way to run ikev2 between two arbitrary end hosts in the internet. there is indeed a problem independently of oscp (as we know from various working groups; e.g., mobile ip). in the draft we discussed the corporate network access authentication (which includes the eap case; section 1.1.3 of ). in this scenario the initiator (road warrior) requests an ocsp response from the responder. as a more generic use case where both nodes use ocsp section 5.1 of was introduced. it, however, does not say that the two peers need to be arbitrary end hosts. it could be useful to spend a few words on the raised issue in our draft. maybe they are also reflected in sufficient detail in your ikev2 security considerations draft (since they issue has broader scope). ciao hannes > -----Original Message----- > From: William Dixon [mailto:ietf-wd@v6security.com] > Sent: Saturday, August 07, 2004 10:31 PM > To: 'Michael Myers' > Cc: ipsec@lists.tislabs.com > Subject: RE: [Ipsec] OCSP in IKEv2 > > Hi Mike, please correct my understanding here if I'm making a mistake. > You mentioned peer-to-peer applicability which prompted my > investigation. The summary is that your draft should be more clear > about the risks of using OCSP inband with IKEv2 in peer-to-peer > scenarios, such as not recommend it. > > I think using OCSP inband in IKEv2 for peer-to-peer would not be > recommended > - as it is limited by the classic problem of how an IKE initiator > knows which credential or trust anchor to expect from the responder. > There are deployment scenarios where this situation is solvable - such > as IKE negotiation to my own corporate gateway, or generally, any case > where I can configure an IPsec policy to use a particular CA or root > for a given destination address/range/etc. But in the open Internet or > in general peer-to-peer scenarios, I won't know which cert or trust > anchor to expect from a given destination. I'm not aware of an actual > recommendation for peer-to-peer IKEv1/2 authentication. We might get a > chance to address this in the IKEv2 security considerations draft > (early stages w/Scott Kelly). > > The risk is to the initiator of a malicious responder when forced to > use that responder to relay/forward OCSP messages to the backend OCSP > server (the OCSP responder). I don't see the draft really explains how > the proposed design notes this should only be used where the IKE > initiator is safe from IKE responder attacks. And the circumstance > where the responder is able to take advantage of the IKE initiator's > limited knowledge of what credential to expect. > > >From RFC 2560: > All definitive [OCSP] response messages SHALL be digitally signed. > The key > used to sign the response MUST belong to one of the following: > > -- the CA who issued the certificate in question > > Clearly if I'm negotiating IKEv2 with a random Internet peer, my use > of OCSP inband with IKEv2 can allow the initiator to accept any > certificate from any pre-configured trust anchor. > If we follow the server-auth SSL deployment model for client certs it > could be any of 130+ root CAs, or whatever someone has been able to > stuff into their trusted root store. If we don't depend upon > pre-configured roots, then why would we need to use OCSP ? If you > would suggests that we depend on PKI-enabled DNS for hints about which > credential to expect, then please mention this in your draft. Though > for peer-to-peer scenarios, it may be an insurmountable barrier to > update any ISP's DNS that I'm connected to with my client PKI info. In > fact I probably don't want to do that if I have several certs from > issuers/roots that would identify my business relationships. > > Cheers, > Wm > William Dixon, Founder, Principal Consultant > V6 Security, Inc. > > > -----Original Message----- > > From: ipsec-bounces@ietf.org > [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Michael Myers > > Sent: Saturday, August 07, 2004 10:22 AM > > To: ipsec@ietf.org > > Cc: Ietf-Pkix@Imc. Org; Pki4ipsec@Honor. Icsalabs. Com > > Subject: [Ipsec] OCSP in IKEv2 > > > > All, > > > > The intersection of IPSEC with PKI is of recent interest. > > Towards that dialog, Hannes Tschofenig and I have proposed how OCSP > > could be used to deliver certificate status in-band to > IKEv2. We were > > driven first to consider the important use case of EAP > (i.e. the Road > > Warrior) but also considered the Peer-to-Peer case in order > to develop > > a general solution. > > > > This individual submission I-D can be found at: > > http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-os > cp-00.txt > > > > Two new certificate encoding types are proposed: OCSP > Responder Hash > > and OCSP Response. An OCSP Responder Hash is sent in a CERTREQ, > > computed as trust anchor hashes are computed but sent in a separate > > CERTREQ. A corresponding OCSP Response is sent back in its > own CERT > > payload and in the context of the CERT payload carrying the > > participant's certificate. That is, an IKEv2 participant > sends both > > its cert and that cert's status in separate CERT payloads. > > > > Hannes and I look forward to your comments and debate. I've > > cross-posted due to intersecting interests but please post > comments to > > the IPSEC list only. > > > > Michael Myers > > > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 04:27:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7ABRUfk074718; Tue, 10 Aug 2004 04:27:30 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUcp-0000k7-4C; Tue, 10 Aug 2004 07:17:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuUbn-0000YZ-16 for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 07:15:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14369 for ; Tue, 10 Aug 2004 07:15:57 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuUgJ-0001rb-My for ipsec@ietf.org; Tue, 10 Aug 2004 07:20:40 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7ABCIg06983 for ; Tue, 10 Aug 2004 07:12:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7ABD40p021806 for ; Tue, 10 Aug 2004 07:13:04 -0400 (EDT) Received: from unknown(83.145.195.1) by nutshell.tislabs.com via csmap (V6.0) id srcAAAc3ayLQ; Tue, 10 Aug 04 07:13:01 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i7ABFYYu023027 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 Aug 2004 14:15:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i7ABFXNB023024; Tue, 10 Aug 2004 14:15:33 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16664.44629.116209.965728@fireball.kivinen.iki.fi> Date: Tue, 10 Aug 2004 14:15:33 +0300 From: Tero Kivinen To: Stephen Kent Subject: [Ipsec] new ICMP text for 2401bis In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 0 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Stephen Kent writes: > 6.1 ICMP message not protected by IPsec If I understood correctly this section covers the ICMP messages coming from the "internet" side, i.e from the interface where we normally receive ESP traffic? So this section does not cover the unprotected ICMP messges coming from the "insde" side, right? Having picture here would really make things easier understand. Something like: (1) (3) (5) (7) +------+/ +---------+/ \+---------+ \+------+ |Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B| +------+ /+---------+ // +---------+\ +------+ (2) // (6) (4) // +----------------+/ // |IPsec HOST C(4a)|=======// +----------------+ Where Host A and B are non IPsec hosts, and SGW A and B are IPsec Gateways, and IPsec HOST C is a host capable of talking IPsec itself (but not a gateway). Numbers near the boxes refer to the interface at that point. A double line "=" is used to mark IPsec connection (ESP tunnel or similar) and number inside the box like "(3a)" refers a traffic exiting from tunnel after decryption and authentication. And then say that section 6.1 covers cases (3), (4), and (5). > 6.2 ICMP messages protected by IPsec Especially this title is hard to understand. I think it should say something like "6.2 ICMP messages protected by or to be protected by IPsec". So this section covers traffic on numbers (2) and (6). And probably also (3a), (4a) and (5a)? > (This section does NOT apply to ICMP traffic that is bypassed or > consumed on the ciphertext side of the IPsec boundary.) > > Both the payload of an ICMP error packet, and the header of the ICMP > packet require checking from an access control perspective. If one of > these packets is forwarded to a host behind a security gateway, the > receiving host IP implementation will make decisions based on the > payload, i.e., the header of the packet that purportedly triggered > the error response. Thus an IPsec implementation SHOULD to try to > ensure that this header information is consistent with the IPsec peer > that transmitted the ICMP packet. If this sort of check is not > performed, then for example, anyone with whom the receiving IPsec > system (A) has an active SA could send an ICMP destination dead > message that refers to any host/net with which A is currently > communicating, and thus effect a highly efficient DoS attack re > communication with other peers of A. Normal IPsec receiver > processing of traffic is not sufficient to protect against such > attacks. Ok, this talks about the (3a), (4a) and (5a).... I.e. tunnel exit checks. > If no SA exists that matches the traffic selectors associated with an > ICMP error packet, then an IPsec implementation MUST map an outbound > ICMP error packet to the SA that would carry the return traffic > associated with the packet that triggered the ICMP error packet. > (This allows an administrator to explicitly account for ICMP error > packets in SPD entries, causing them to bypass the payload check > noted below. This results in reduced security for hosts, as noted > above.) This requires an IPsec implementation to detect outbound ICMP > error packets that map to no extant SA, and treat them specially with > regard to SA creation and lookup. The implementation extracts the > header for the packet that triggered the error (from the ICMP message > payload), reverses the source and destination IP address fields, > extracts the protocol field, and reverses the port fields (if > accessible). it them uses this extracted information to locate an > appropriate, active outbound SA. This implies that there must be an > active SA for that traffic. An IPsec implementation MUST NOT create a > new SA carry ICMP traffic error packets as a result of an attempt to > transmit such packets. And this talks packets coming at (2) and (6). > If an IPsec implementation receives an IMCP error packet that does ^^^^ Typo > not match the SA traffic selectors, the receiver also MUST process I assume here "SA traffic selectors" referes to the normal traffic selectors, like SA only for TCP 22 receiving ICMP host unreachable with internal packet having TCP 22. > the received message in a special fashion. Specifically, the receiver > must extract the header of the triggering packet from the ICMP > payload, and reverse fields as described above to determine if the > packet is consistent with the selectors for the SA via which it was > received. Only then is it safe to forward the ICMP message to the > destination. And this is again for the (3a), (4a) and (5a). > The sender and receiver MUST support the following processing when > ICMP error packets are sent over SAs with selectors that DO NOT match > these packets: "... DO NOT match these ICMP packets (but the packet inside the ICMP message matches)"? > a. If an IPsec implementation encounters an outbound ICMP > error message for which no applicable SA exists, it > extracts the header info from the payload, reverses the > source and destination IP addresses, and, if accessible, > the source and destination port fields. It uses the > address, protocol, and port fields (if available) to > perform an SPD lookup. If an appropriate, extant SA is > found, the packet is transmitted via this SA. (No new SA > will be created to carry an ICMP error packet.) If no > suitable SA exists, the ICMP packet is dropped, an > auditable event. Looks good. So this covers packets coming from (2), and (6). > b. If an IPsec implementation receives an ICMP error packet on > an SA and the traffic selectors for that SA do not allow > for the packet, a secondary check is performed. The > receiver extracts the header info from the ICMP payload, > reverses the source and destination IP addresses, and, if > accessible, the source and destination port fields. The > resulting values are compared to the selectors for the SA > via which the ICMP packet was received. If the selectors > match, the packet is forwarded, otherwise it it is > discarded, and auditable event. And this (3a), (4a) and (5a). > B. The following text will be added to Security Considerations: > > An IPsec implementation is configured to pass ICMP error packets over > SAs based on the ICMP header values, without checking the header info > from the ICMP packet payload. I think that needs some kind of rewording like "An IPsec implementation can be configured ..." or similar. > For example, a tunnel may be created between two sites that uses ANY > for protocol and port fields and IP address ranges that encompass > all systems behind the security gateways serving each site. In such > cases, the hosts behind the security gateways will be vulnerable to > DoS attacks that might be launched by other peers with which there > are active SAs. Perhaps we should describe the situation more here? BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF processing stuff from there (section 6 and appendix B)? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 09:27:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AGRWQb043988; Tue, 10 Aug 2004 09:27:32 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZ3a-0000iu-Ui; Tue, 10 Aug 2004 12:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuYxH-0007uw-K6; Tue, 10 Aug 2004 11:54:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06525; Tue, 10 Aug 2004 11:54:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZ1r-0007AB-0w; Tue, 10 Aug 2004 11:59:11 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BuYlT-0005IH-MG; Tue, 10 Aug 2004 11:42:15 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 10 Aug 2004 11:42:15 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec mailing list , ipsec chair , Internet Architecture Board , ipsec chair , RFC Editor Subject: [Ipsec] Protocol Action: 'UDP Encapsulation of IPsec Packets' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has approved the following document: - 'UDP Encapsulation of IPsec Packets ' as a Proposed Standard This document is the product of the IP Security Protocol Working Group. The IESG contact persons are Russ Housley and Steve Bellovin. Technical Summary This protocol specification defines methods to encapsulate and decapsulate IPsec Encapsulating Security Payload (ESP) packets inside UDP packets for the purpose of traversing Network Address Translators. ESP encapsulation can be used in both IPv4 and IPv6. ESP encapsulation is used whenever negotiated by the Internet Key Exchange (IKE) protocol. Working Group Summary The IPsec Working Group came to consensus on this document. Protocol Quality This document was reviewed by Russell Housley for the IESG. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 10:11:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7AHB8c8047045; Tue, 10 Aug 2004 10:11:09 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZsS-0006wa-MI; Tue, 10 Aug 2004 12:53:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuZmJ-0004ww-0i for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 12:47:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11186 for ; Tue, 10 Aug 2004 12:47:07 -0400 (EDT) Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuZqp-0008S3-RV for ipsec@ietf.org; Tue, 10 Aug 2004 12:51:55 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7AGhTg03538 for ; Tue, 10 Aug 2004 12:43:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i7AGhhuv008384 for ; Tue, 10 Aug 2004 12:43:43 -0400 (EDT) Received: from mailout.fastq.com(204.62.193.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAZsa4vq; Tue, 10 Aug 04 12:43:40 -0400 Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i7AGkO898280; Tue, 10 Aug 2004 09:46:24 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: "William Dixon" Subject: RE: [Ipsec] OCSP in IKEv2 Date: Tue, 10 Aug 2004 09:45:30 -0700 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: <200408072246.i77Mk1i0003036@rs15.luxsci.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org William, I have no issue with reducing the normative strength of this clause (1) so long as we directly address the case. The question is what does a IKEv2 responder send back should it be unable to comply with an initiator's request for in-band OCSP? To your second point (2), it has been established that IKEv2 is too far along in its consensus formation for the degree of reset direct inclusion of this proposal would cause. Russ' direction is equally unambiguous regarding PKI4IPSEC: OCSP for IKEv2 will be an individual submission I-D gated onto the Standards Track, subject to comments. Which brings us back to the first point: improving the I-D based on comments. These days making PKI work translates in part to knob reduction. I interpret this into a reduction of optional protocol elements and crisp SHALL/SHALL NOT requirements instead of SHOULD or MAY. That said, it is useful in some instances to be accommodative. I am not yet convinced this is such an instance. Failing to include an OCSP Response is not an all-out failure as you cite from IKEv2. The responder may simply be unable to provide the requested service. That does not mean it has failed in some fundamental way. But neither am I expert in IPSEC's current state of deployment. I remain open to debate on this point but as I see it today, a responder unable to satisfy an initiator's request for in-band OCSP should say so, if only in an error message. The initiator can then retry with a reduced level of assurance if it so chooses. Mike -----Original Message----- From: William Dixon Sent: Saturday, August 07, 2004 3:46 PM (1) . . . I'm wondering why there is a "MUST not ignore the OCSP response payload" statement in the draft. I don't think an error message MUST be sent [because IKEv2 says] "An endpoint MUST conclude that the other endpoint has failed only when repeated attempts to contact it have gone unanswered for a timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE_SA to the same authenticated identity." (2) . . . do we adopt OCSP support in IKEv2 at this point, advance this draft as an addendum, or maybe incorporate it into the PKI4IPsec work _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Aug 10 18:51:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B1phPr093088; Tue, 10 Aug 2004 18:51:44 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuiBN-0006sh-8b; Tue, 10 Aug 2004 21:45:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bui7n-0006Fm-EC for ipsec@megatron.ietf.org; Tue, 10 Aug 2004 21:41:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23191 for ; Tue, 10 Aug 2004 21:41:52 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuiCO-0003XY-Or for ipsec@ietf.org; Tue, 10 Aug 2004 21:46:44 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7B1fgl0092130; Tue, 10 Aug 2004 18:41:43 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 10 Aug 2004 18:41:45 -0700 To: "Michael Myers" , From: Paul Hoffman / VPNC Subject: [Ipsec] RE: OCSP in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:31 PM -0700 8/9/04, Michael Myers wrote: >BTW, the ADs have agreed this I-D will be placed onto the Standards >Track, subject to resolution of comments. Such a statement seems wildly premature for a -00 document. To date, there has been nearly zero interest from anyone in the IPsec vendor community for in-band OCSP. Further, I am unaware of any deman from the VPN user community for this. Having a standards-track document will lead some to think that vendors are supposed to support this. Given that there is no actual need for handling OCSP in IPsec, the document should not move on to standards track; Experimental status is fine. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 09:01:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BG17N2057792; Wed, 11 Aug 2004 09:01:07 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvQn-0007QZ-Qx; Wed, 11 Aug 2004 11:54:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuvKs-00068W-UF for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 11:48:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13910 for ; Wed, 11 Aug 2004 11:48:16 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuvPd-0001gv-KK for ipsec@ietf.org; Wed, 11 Aug 2004 11:53:15 -0400 Received: from brahma.intotoind.com (brahma.intotoind.com [127.0.0.1]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id i7BFm8jb001086; Wed, 11 Aug 2004 21:18:08 +0530 Received: from localhost (navink@localhost) by brahma.intotoind.com (8.12.11/8.12.8/Submit) with ESMTP id i7BFm7iE001082; Wed, 11 Aug 2004 21:18:07 +0530 X-Authentication-Warning: brahma.intotoind.com: navink owned process doing -bs Date: Wed, 11 Aug 2004 21:18:07 +0530 (IST) From: Navin Kumar X-X-Sender: navink@brahma.intotoind.com To: sheila.frankel@nist.gov, In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ipsec@ietf.org Subject: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC 3566) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, RFC 3566 (AES-XCBC-MAC-96 Algorithm and Its Use with IPSec) states that : Case 1: if the size of last block of message is 128 bits : do E[n] = Encryption (M[n] XOR E[n-1] XOR K2) with K1 Case2: if the size of last block of message is less than 128 bits: do i)Pad M[n] with a '1'bit followed by '0'bits to make M[n] to be a block size of 128 bits. ii) E[n] = Encryption (M[n] XOR E[n-1] XOR K3 ) with K1 where M[n] - the last block of message E[n] - the AESXCBC-MAC value E[n-1] = encrypted output of the previous block K1 - AES Encryption Key K1 K2 - derived key from K1. Encryption - AES Encryption The above is explained in RFC 3566 in section 4 . My Doubt: As per RFC 2402 - AH Protocol, if the IP packet length does not match the blocksize of the auth algorithm, implicit padding is done with zeros. 1) Hence if AES-XCBCMAC is chosen in AH then , is it that always Case 1 occurs?? Kindly clarify my understanding. 2) When will Case 2 occur? thanks in advance. navin _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 11:41:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BIfwHh075342; Wed, 11 Aug 2004 11:41:59 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buxsp-0004mT-NP; Wed, 11 Aug 2004 14:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuxrA-0004QP-R7 for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 14:29:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24462 for ; Wed, 11 Aug 2004 14:29:47 -0400 (EDT) From: saroddy@nsa.gov Received: from mummy.ncsc.mil ([144.51.88.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buxvx-0004e4-Mc for ipsec@ietf.org; Wed, 11 Aug 2004 14:34:46 -0400 Received: from bigmail.ncsc.mil (jazzhorn.ncsc.mil [144.51.5.9]) by mummy.ncsc.mil (8.12.10/8.12.10) with ESMTP id i7BISdep009138 for ; Wed, 11 Aug 2004 18:28:39 GMT Received: by bigmail.ncsc.mil with Internet Mail Service (5.5.2657.72) id <342GGK7P>; Wed, 11 Aug 2004 14:29:16 -0400 Message-ID: <7B7C37072FBDFC4FAE6F6B86025A47E303426B4E@bigmail.ncsc.mil> To: ipsec@ietf.org Date: Wed, 11 Aug 2004 14:29:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] HTTP question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I'm posting a potentially ignorant question and I apologize in advance. However, I cannot seem to find any data to support the consideration or examination of bandwidth consumption when using HTTP vs. OCSP in validating digital certificates. Has there been any effort in this area to also indicate what requirements are subsequently imposed on the end users to support HTTP vs. OCSP? Thanks _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 12:05:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BJ5Arp078101; Wed, 11 Aug 2004 12:05:11 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuyDg-000284-TF; Wed, 11 Aug 2004 14:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buy7C-0007GH-OQ for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 14:46:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26239 for ; Wed, 11 Aug 2004 14:46:21 -0400 (EDT) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuyBz-00055K-JR for ipsec@ietf.org; Wed, 11 Aug 2004 14:51:20 -0400 Received: from MMyersLapTop (dslstat-ppp-106.fastq.com [65.39.92.106]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id i7BIkA878566; Wed, 11 Aug 2004 11:46:10 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: , Subject: RE: [Ipsec] HTTP question Date: Wed, 11 Aug 2004 11:45:15 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <7B7C37072FBDFC4FAE6F6B86025A47E303426B4E@bigmail.ncsc.mil> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Sandi, Your question is a little bit confusing. OCSP typically rides over HTTP. Mike -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of saroddy@nsa.gov Sent: Wednesday, August 11, 2004 11:29 AM To: ipsec@ietf.org Subject: [Ipsec] HTTP question I'm posting a potentially ignorant question and I apologize in advance. However, I cannot seem to find any data to support the consideration or examination of bandwidth consumption when using HTTP vs. OCSP in validating digital certificates. Has there been any effort in this area to also indicate what requirements are subsequently imposed on the end users to support HTTP vs. OCSP? Thanks _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 14:22:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLM2SO092026; Wed, 11 Aug 2004 14:22:03 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Hb-0000No-F7; Wed, 11 Aug 2004 17:05:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buyoc-00018l-RF for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 15:31:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01885 for ; Wed, 11 Aug 2004 15:31:12 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuytN-0006NT-2F for ipsec@ietf.org; Wed, 11 Aug 2004 15:36:13 -0400 Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7BJUZ7b005408; Wed, 11 Aug 2004 15:30:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Wed, 11 Aug 2004 15:30:18 -0400 To: Navin Kumar From: Stephen Kent Subject: Re: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC 3566) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipsec@ietf.org, howard.c.herbert@intel.com, sheila.frankel@nist.gov X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:18 PM +0530 8/11/04, Navin Kumar wrote: > > >My Doubt: > >As per RFC 2402 - AH Protocol, if the IP packet length does not >match the blocksize of the auth algorithm, implicit padding is done with >zeros. > >1) Hence if AES-XCBCMAC is chosen in AH then , is it that always Case 1 >occurs?? > Kindly clarify my understanding. The authors described a generic padding mechanism for use of the algorithm, not one tailored to use in the AH context. So, I'd say the right answer is to interpret this as CASE 1, i.e., the implicit padding provided by AH makes the input to the algorithm always appear as a full, final block. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 14:28:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLSETm092451; Wed, 11 Aug 2004 14:28:15 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Ic-0000uj-AK; Wed, 11 Aug 2004 17:06:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buz8o-0000JN-IR for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 15:52:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04001 for ; Wed, 11 Aug 2004 15:52:04 -0400 (EDT) Received: from 206-169-193-40.gen.twtelecom.net ([206.169.193.40] helo=ProgressiveComputingLLC.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BuzDZ-0006wF-TR for ipsec@ietf.org; Wed, 11 Aug 2004 15:57:05 -0400 content-class: urn:content-classes:message Subject: RE: [Ipsec] HTTP question MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Aug 2004 12:51:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2D0CA64CDC33E14DA7AB043B8CC4D2BB023255C6@svr-exc.domain.com> Thread-Topic: [Ipsec] HTTP question Thread-Index: AcR/0vn61M/XqMyVRrSlhIsqXUnIEQACOIKQ From: "Thomas Gal" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i7BLSETm092451 Maybe you mean OCSP versus CRL? They are just 2 different ways of authenticating network resources using PKI. If that's what your talking about then CRL uses a lot more bandwidth notionally then OCSP because the client has to maintain a local list of resource-certificate pairings that must be updated frequently instead of just querying on an as needed basis. T Thomas Gal Developer LumenVox LLC 3615 Kearny Villa Rd #202 San Diego, CA 92123 thomasgal@lumenvox.com 707-0707x135 -----Original Message----- From: saroddy@nsa.gov [mailto:saroddy@nsa.gov] Sent: Wednesday, August 11, 2004 11:29 AM To: ipsec@ietf.org Subject: [Ipsec] HTTP question I'm posting a potentially ignorant question and I apologize in advance. However, I cannot seem to find any data to support the consideration or examination of bandwidth consumption when using HTTP vs. OCSP in validating digital certificates. Has there been any effort in this area to also indicate what requirements are subsequently imposed on the end users to support HTTP vs. OCSP? Thanks _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 14:31:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLVnGN092741; Wed, 11 Aug 2004 14:31:54 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Vh-0005e3-Qj; Wed, 11 Aug 2004 17:19:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Buzim-00052y-Vx for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 16:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10501 for ; Wed, 11 Aug 2004 16:29:14 -0400 (EDT) Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Buznb-0000m7-Ie for ipsec@ietf.org; Wed, 11 Aug 2004 16:34:16 -0400 Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i7BKPdg04875 for ; Wed, 11 Aug 2004 16:25:39 -0400 (EDT) Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i7BKLI7Z009338; Wed, 11 Aug 2004 16:21:22 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16664.44629.116209.965728@fireball.kivinen.iki.fi> References: <16664.44629.116209.965728@fireball.kivinen.iki.fi> Date: Wed, 11 Aug 2004 16:21:02 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: [Ipsec] new ICMP text for 2401bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:15 PM +0300 8/10/04, Tero Kivinen wrote: >Stephen Kent writes: >> 6.1 ICMP message not protected by IPsec > >If I understood correctly this section covers the ICMP messages coming >from the "internet" side, i.e from the interface where we normally >receive ESP traffic? yes. we can clarify the scope when we insert the text. >So this section does not cover the unprotected ICMP messges coming >from the "insde" side, right? right. >Having picture here would really make things easier understand. >Something like: > > (1) (3) (5) (7) >+------+/ +---------+/ \+---------+ \+------+ >|Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B| >+------+ /+---------+ // +---------+\ +------+ > (2) // (6) > (4) // > +----------------+/ // > |IPsec HOST C(4a)|=======// > +----------------+ > > >Where Host A and B are non IPsec hosts, and SGW A and B are IPsec >Gateways, and IPsec HOST C is a host capable of talking IPsec itself >(but not a gateway). Numbers near the boxes refer to the interface at >that point. A double line "=" is used to mark IPsec connection (ESP >tunnel or similar) and number inside the box like "(3a)" refers a >traffic exiting from tunnel after decryption and authentication. > >And then say that section 6.1 covers cases (3), (4), and (5). we'll see what makes sense in terms of describing what sets of traffic is addressed by each part of section 6. based on your comments below, I'm not quite sure how to interpret (2) and (6) above, so we probably need a diagram plus some notes to clarify this complex issue. > > 6.2 ICMP messages protected by IPsec > >Especially this title is hard to understand. I think it should say >something like "6.2 ICMP messages protected by or to be protected by >IPsec". good point. > >So this section covers traffic on numbers (2) and (6). And probably >also (3a), (4a) and (5a)? the emphasis is on traffic that arrives on an SA, or that arrives on the protected side and is mapped to an SA. So, some examples of ICMP traffic that might be captured under 2 and 6 would not be included, e.g., if the traffic was outbound but addresses to the IPsec device. > >> (This section does NOT apply to ICMP traffic that is bypassed or >> consumed on the ciphertext side of the IPsec boundary.) >> >> Both the payload of an ICMP error packet, and the header of the ICMP >> packet require checking from an access control perspective. If one of >> these packets is forwarded to a host behind a security gateway, the >> receiving host IP implementation will make decisions based on the >> payload, i.e., the header of the packet that purportedly triggered >> the error response. Thus an IPsec implementation SHOULD to try to >> ensure that this header information is consistent with the IPsec peer >> that transmitted the ICMP packet. If this sort of check is not >> performed, then for example, anyone with whom the receiving IPsec >> system (A) has an active SA could send an ICMP destination dead >> message that refers to any host/net with which A is currently >> communicating, and thus effect a highly efficient DoS attack re >> communication with other peers of A. Normal IPsec receiver >> processing of traffic is not sufficient to protect against such >> attacks. > >Ok, this talks about the (3a), (4a) and (5a).... I.e. tunnel exit >checks. yes > >> If no SA exists that matches the traffic selectors associated with an >> ICMP error packet, then an IPsec implementation MUST map an outbound >> ICMP error packet to the SA that would carry the return traffic >> associated with the packet that triggered the ICMP error packet. >> (This allows an administrator to explicitly account for ICMP error >> packets in SPD entries, causing them to bypass the payload check >> noted below. This results in reduced security for hosts, as noted >> above.) This requires an IPsec implementation to detect outbound ICMP > > error packets that map to no extant SA, and treat them specially with >> regard to SA creation and lookup. The implementation extracts the >> header for the packet that triggered the error (from the ICMP message >> payload), reverses the source and destination IP address fields, >> extracts the protocol field, and reverses the port fields (if >> accessible). it them uses this extracted information to locate an >> appropriate, active outbound SA. This implies that there must be an >> active SA for that traffic. An IPsec implementation MUST NOT create a >> new SA carry ICMP traffic error packets as a result of an attempt to >> transmit such packets. > >And this talks packets coming at (2) and (6). more precisely, packets that arrive at (2) and (6) but which are destined for devices with which the IPsec implementation is communicating via SAs. > >> If an IPsec implementation receives an IMCP error packet that does > ^^^^ Typo > >> not match the SA traffic selectors, the receiver also MUST process > >I assume here "SA traffic selectors" referes to the normal traffic >selectors, like SA only for TCP 22 receiving ICMP host unreachable >with internal packet having TCP 22. it refers to whatever selectors are in the SPD-O cache (i.e. for extant SAs). it is not talking about (2) or (6) traffic that is directed to the IPsec implementation itself, from the protected side. yes, that's what I have been saying in my motes above. none of the text here talks about what to do re traffic on the protected side that is "consumed" by the Ipsec implementation, vs. being transported by that implementation. > >> the received message in a special fashion. Specifically, the receiver >> must extract the header of the triggering packet from the ICMP >> payload, and reverse fields as described above to determine if the >> packet is consistent with the selectors for the SA via which it was >> received. Only then is it safe to forward the ICMP message to the >> destination. > >And this is again for the (3a), (4a) and (5a). yes. > >> The sender and receiver MUST support the following processing when >> ICMP error packets are sent over SAs with selectors that DO NOT match >> these packets: > >"... DO NOT match these ICMP packets (but the packet inside the ICMP >message matches)"? the text below is just a restatement of the text above, in a more concise form. so, this refers to transmit and receive processing for ICMP error packets that would not otherwise be mapped to extant SAs. > >> a. If an IPsec implementation encounters an outbound ICMP >> error message for which no applicable SA exists, it >> extracts the header info from the payload, reverses the >> source and destination IP addresses, and, if accessible, >> the source and destination port fields. It uses the >> address, protocol, and port fields (if available) to >> perform an SPD lookup. If an appropriate, extant SA is >> found, the packet is transmitted via this SA. (No new SA >> will be created to carry an ICMP error packet.) If no >> suitable SA exists, the ICMP packet is dropped, an >> auditable event. > >Looks good. So this covers packets coming from (2), and (6). > >> b. If an IPsec implementation receives an ICMP error packet on >> an SA and the traffic selectors for that SA do not allow >> for the packet, a secondary check is performed. The >> receiver extracts the header info from the ICMP payload, >> reverses the source and destination IP addresses, and, if >> accessible, the source and destination port fields. The >> resulting values are compared to the selectors for the SA >> via which the ICMP packet was received. If the selectors >> match, the packet is forwarded, otherwise it it is >> discarded, and auditable event. > >And this (3a), (4a) and (5a). yes. > >> B. The following text will be added to Security Considerations: >> >> An IPsec implementation is configured to pass ICMP error packets over >> SAs based on the ICMP header values, without checking the header info >> from the ICMP packet payload. > >I think that needs some kind of rewording like "An IPsec >implementation can be configured ..." or similar. I should have said: "if an IPsec implementation is configured to pass ..." > >> For example, a tunnel may be created between two sites that uses ANY >> for protocol and port fields and IP address ranges that encompass >> all systems behind the security gateways serving each site. In such >> cases, the hosts behind the security gateways will be vulnerable to >> DoS attacks that might be launched by other peers with which there >> are active SAs. > >Perhaps we should describe the situation more here? suggestions? > >BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF >processing stuff from there (section 6 and appendix B)? Yes, Karen has not yet added back the PMTU text. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 14:41:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLfi8t093395; Wed, 11 Aug 2004 14:41:46 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0WR-0006pQ-FG; Wed, 11 Aug 2004 17:20:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BuzxU-0002JW-7v for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 16:44:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12999 for ; Wed, 11 Aug 2004 16:44:25 -0400 (EDT) Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv02E-0001Zk-ND for ipsec@ietf.org; Wed, 11 Aug 2004 16:49:27 -0400 Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id i7BKi7NR024509; Wed, 11 Aug 2004 16:44:07 -0400 Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id i7BKfeos013989; Wed, 11 Aug 2004 16:41:40 -0400 Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id i7BKfeKs013987; Wed, 11 Aug 2004 16:41:40 -0400 Received: from pcp05896235pcs.nrockv01.md.comcast.net (pcp05896235pcs.nrockv01.md.comcast.net [69.140.246.40]) by webmail.nist.gov (IMP) with HTTP for ; Wed, 11 Aug 2004 16:41:40 -0400 Message-ID: <1092256900.411a84840e4e7@webmail.nist.gov> Date: Wed, 11 Aug 2004 16:41:40 -0400 From: Sheila Frankel To: Stephen Kent Subject: Re: [Ipsec] Paddding Issue in AES-XCBC-MAC-96 with IPSEC (RFC 3566) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 69.140.246.40 X-NIST-MailScanner: Found to be clean X-MailScanner-From: sheila.frankel@nist.gov X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org, howard.c.herbert@intel.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Actually, I came to the opposite conclusion: This question is addressed in the AES-XCBC-MAC RFC; unfortunately, it appears in a different section than the algorithm definition. The AH RFC, in section 3.3.3.2.2, exempts MD5 and SHA-1 from the implicit packet padding requirements, since they have their own padding conventions. AES-XCBC-MAC was not defined when the AH RFC was written, but it is treated in the same way. Thus, the padding will be performed according to the AES-XCBC-MAC specification, and Case2 will occur when the packetsize is not a multiple of 128 bits. In fact, the AES-XCBC-MAC RFC, in section 4.2, states "with regard to 'implicit packet padding' as defined in [AH], no implicit padding is required." Sheila Frankel sheila.frankel@nist.gov Quoting Stephen Kent : > At 9:18 PM +0530 8/11/04, Navin Kumar wrote: > > > > > >My Doubt: > > > >As per RFC 2402 - AH Protocol, if the IP packet length does not > >match the blocksize of the auth algorithm, implicit padding is done with > >zeros. > > > >1) Hence if AES-XCBCMAC is chosen in AH then , is it that always Case 1 > >occurs?? > > Kindly clarify my understanding. > > The authors described a generic padding mechanism for use of the > algorithm, not one tailored to use in the AH context. So, I'd say > the right answer is to interpret this as CASE 1, i.e., the implicit > padding provided by AH makes the input to the algorithm always appear > as a full, final block. > > Steve > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Aug 11 14:43:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i7BLhVPx093515; Wed, 11 Aug 2004 14:43:32 -0700 (PDT) (envelope-from ipsec-bounces@ietf.org) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv0Wq-0007mH-GT; Wed, 11 Aug 2004 17:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bv03P-0004Lu-SH for ipsec@megatron.ietf.org; Wed, 11 Aug 2004 16:50:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14173 for ; Wed, 11 Aug 2004 16:50:33 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bv08D-0001vZ-Nh for ipsec@ietf.org; Wed, 11 Aug 2004 16:55:35 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i7BKnsJ6003619; Wed, 11 Aug 2004 13:49:54 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i7BKns86012011; Wed, 11 Aug 2004 16:49:54 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.0+Sun/8.13.0) with ESMTP id i7BKnrSH012973; Wed, 11 Aug 2004 16:49:54 -0400 (EDT) Message-Id: <200408112049.i7BKnrSH012973@thunk.east.sun.com> From: Bill Sommerfeld To: Paul Hoffman / VPNC Subject: Re: [Ipsec] RE: OCSP in IKEv2 In-Reply-To: Your message of "Tue, 10 Aug 2004 18:41:45 PDT." Date: Wed, 11 Aug 2004 16:49:53 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipsec@ietf.org, Michael Myers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: