From owner-ietf-ipsra@mail.vpnc.org Mon Oct 1 20:01:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05161 for ; Mon, 1 Oct 2001 20:01:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f91NVe124738 for ietf-ipsra-bks; Mon, 1 Oct 2001 16:31:40 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.6/8.11.3) with SMTP id f91NVdD24733 for ; Mon, 1 Oct 2001 16:31:39 -0700 (PDT) Received: (qmail 16078 invoked from network); 1 Oct 2001 23:29:36 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 1 Oct 2001 23:29:36 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for ietf-ipsra@vpnc.org; Mon, 1 Oct 2001 19:31:04 -0400 Received: from andrewk3 ([138.120.49.132]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5734; Mon, 1 Oct 2001 19:31:02 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Markus Stenberg'" , Subject: RE: Reminder: last call for PIC in the IPSRA WG Date: Mon, 1 Oct 2001 19:30:24 -0400 Message-Id: <002001c14ad1$0d7dc0d0$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal In-Reply-To: <87u1y29esg.fsf@porsas.hel.fi.ssh.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In terms of the DoS potential of the Internet, I think we've only seen the tip of the iceberg. It's definitely better to have some kind of cookie exchange. I believe William brought up the lack of DoS protection at the IETF meeting, along with a question about the hash calculation. I also wonder about the hash calculation. When Hugo was asked why we're not using the revised hash in PIC, he replied that the situation that motivated the development of revised hash in IKE doesn't exist in PIC. I guess that's true (PIC says you can't include notify or vendor id payloads until after the first hash has been sent), but I still wonder what's the point? Is there any advantage to the particular hash calcuation that is described in PIC? Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Markus Stenberg > Sent: Monday, September 17, 2001 8:35 AM > To: ietf-ipsra@vpnc.org > Subject: Re: Reminder: last call for PIC in the IPSRA WG > > > > paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > > Hi again. Just a reminder that we are in the middle of the PIC last > > call in the IPSRA WG. The last call ends at the end of September > > unless significant changes are needed to the spec. > > > > It has been pretty quiet here, and maybe that is good. > > I was also on vacation (four weeks :>), which delayed > somewhat this mail. I > didn't want to start discussion while people were still in > Finland in the > VPN workshop, and I regrettably had to leave workshop's > summary session > before I could poll it locally. > > I still personally feel that with the discussion about s-o-IKE, and > _especially_ the discussions regarding aggressive/main(/base) > mode in IPsec > WG, it might be bad idea to select aggressive-like approach for PIC. > > Why do we want to perform significant work on basis of a packet from a > source which we haven't even verified exists and really wants > to talk to > us? > > This could be circumvented (at least) by changing the > exchange from 3 to 4 > messages and styling it after base mode instead of aggressive mode. > > If someone else agrees, feel free to point it out; if it's > just me, I'll > go back to my corner :> > > > --Paul Hoffman, Director > > --VPN Consortium > > -Markus > > -- > Markus Stenberg (stenberg@ssh.com) of SSH Communications > Security (www.ssh.com) > From owner-ietf-ipsra@mail.vpnc.org Thu Oct 11 16:19:12 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24292 for ; Thu, 11 Oct 2001 16:19:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9BJZU915030 for ietf-ipsra-bks; Thu, 11 Oct 2001 12:35:30 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9BJZTD15026 for ; Thu, 11 Oct 2001 12:35:29 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23587; Thu, 11 Oct 2001 15:35:26 -0400 (EDT) Message-Id: <200110111935.PAA23587@ietf.org> To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: The IESG SUBJECT: Last Call: PIC, A Pre-IKE Credential Provisioning Protocol to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 11 Oct 2001 15:35:26 -0400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the IP Security Remote Access Working Group to consider PIC, A Pre-IKE Credential Provisioning Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by October 25, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-03.txt From owner-ietf-ipsra@mail.vpnc.org Tue Oct 16 18:57:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22562 for ; Tue, 16 Oct 2001 18:57:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GMOom10939 for ietf-ipsra-bks; Tue, 16 Oct 2001 15:24:50 -0700 (PDT) Received: from ee.technion.ac.il ([132.68.48.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GMOmD10935 for ; Tue, 16 Oct 2001 15:24:48 -0700 (PDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.10.2+Sun/8.10.2) with ESMTP id f9GMNiO04020; Wed, 17 Oct 2001 00:23:49 +0200 (IST) Date: Wed, 17 Oct 2001 00:23:44 +0200 (IST) From: Hugo Krawczyk To: Markus Stenberg cc: working group ipsra Subject: Re: Reminder: last call for PIC in the IPSRA WG In-Reply-To: <87u1y29esg.fsf@porsas.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Markus, Better later than never... One can add to PIC some DOS protection via two extra initial messages (this is what I said during the London ietf meeting when asked about it). Adding these messages is quite straightorward from the point of view of specification (the messages would carry a cookie from client to server and one from server to client -- the last one being a stateless cookie a la Karn) but it certainly adds performance and protocol complexity. Having lacked explicit requirements for such measures we settled for simplicity and less performance penalty. If you obtain consensus to add this stuff, then it is doable. As for your suggestion to use base mode: this solution would be inappropriate here. It requires a responder's state anyway and its main advantage in the context of IKE is lost here. This advantage is that the responder can do a (rleatively cheap) RSA sig verification before it performs its own signature and the g^xy DH exponentiation. However, in PIC there is no signature from the client at all, so this mechanism of base mode does not aply here. Thanks for the feedback. Hugo On 17 Sep 2001, Markus Stenberg wrote: > > paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > > Hi again. Just a reminder that we are in the middle of the PIC last > > call in the IPSRA WG. The last call ends at the end of September > > unless significant changes are needed to the spec. > > > > It has been pretty quiet here, and maybe that is good. > > I was also on vacation (four weeks :>), which delayed somewhat this mail. I > didn't want to start discussion while people were still in Finland in the > VPN workshop, and I regrettably had to leave workshop's summary session > before I could poll it locally. > > I still personally feel that with the discussion about s-o-IKE, and > _especially_ the discussions regarding aggressive/main(/base) mode in IPsec > WG, it might be bad idea to select aggressive-like approach for PIC. > > Why do we want to perform significant work on basis of a packet from a > source which we haven't even verified exists and really wants to talk to > us? > > This could be circumvented (at least) by changing the exchange from 3 to 4 > messages and styling it after base mode instead of aggressive mode. > > If someone else agrees, feel free to point it out; if it's just me, I'll > go back to my corner :> > > > --Paul Hoffman, Director > > --VPN Consortium > > -Markus > > -- > Markus Stenberg (stenberg@ssh.com) of SSH Communications Security (www.ssh.com) > From owner-ietf-ipsra@mail.vpnc.org Tue Oct 16 19:10:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22703 for ; Tue, 16 Oct 2001 19:10:53 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GMl2n11258 for ietf-ipsra-bks; Tue, 16 Oct 2001 15:47:02 -0700 (PDT) Received: from ee.technion.ac.il ([132.68.48.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9GMl0D11254 for ; Tue, 16 Oct 2001 15:47:01 -0700 (PDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.10.2+Sun/8.10.2) with ESMTP id f9GMTO104105; Wed, 17 Oct 2001 00:29:25 +0200 (IST) Date: Wed, 17 Oct 2001 00:29:24 +0200 (IST) From: Hugo Krawczyk To: Andrew Krywaniuk cc: "'Markus Stenberg'" , ietf-ipsra@vpnc.org Subject: RE: Reminder: last call for PIC in the IPSRA WG In-Reply-To: <002001c14ad1$0d7dc0d0$1e72788a@andrewk3.ca.newbridge.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Andrew, On Mon, 1 Oct 2001, Andrew Krywaniuk wrote: > > In terms of the DoS potential of the Internet, I think we've only seen the > tip of the iceberg. It's definitely better to have some kind of cookie > exchange. I believe William brought up the lack of DoS protection at the > IETF meeting, along with a question about the hash calculation. I referred to the DoS protection via cookies in my previous message to Markus. It is doable, the question is if there is consensus. > > I also wonder about the hash calculation. When Hugo was asked why we're not > using the revised hash in PIC, he replied that the situation that motivated > the development of revised hash in IKE doesn't exist in PIC. I guess that's > true (PIC says you can't include notify or vendor id payloads until after > the first hash has been sent), but I still wonder what's the point? Is there > any advantage to the particular hash calcuation that is described in PIC? In PIC we have HASH_R in the second message, and HASH in second, third and fourth messages. HASH is used to authenticate each of the EAP payloads (except payload headers -- see (*) below) so it serves for providing the cryptographic authentication of the exchanged information and does not require further complication (e.g. it does not require including packets from previous messages as suggested in the revised-hash draft). As for HASH_R we are going to include the full ISAKMP headers from both messages 1 and 2 under HASH_R which cover CKY-I and CKY-R as in IKE but also the Major and Minor numbers. ANother important change in the calculation of HASH_R in PIC is that it corrects the IKE's typo of missing SA_r from the authenticated information under HASH_R. Moreover, in PIC also SA_i is included under HASH_R so the client can verify that its SA proposals were not modified in route. Hugo (*) This, however, requires one "design disclaimer" that appears in the PIC document (end of section A.1 in the 03 draft): ``Another design decision made in order not to change the regular ISAKMP processing is to apply authentication (under the HASH payload) to base payloads only and not to payload headers. Authenticating all bits, including headers, would have been a better approach but also in this case we have favored ISAKMP compatibility. '' > > Andrew > ------------------------------------------- > Upon closer inspection, I saw that the line > dividing black from white was in fact a shade > of grey. As I drew nearer still, the grey area > grew larger. And then I was enlightened. > > > > -----Original Message----- > > From: owner-ietf-ipsra@mail.vpnc.org > > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Markus Stenberg > > Sent: Monday, September 17, 2001 8:35 AM > > To: ietf-ipsra@vpnc.org > > Subject: Re: Reminder: last call for PIC in the IPSRA WG > > > > > > > > paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > > > Hi again. Just a reminder that we are in the middle of the PIC last > > > call in the IPSRA WG. The last call ends at the end of September > > > unless significant changes are needed to the spec. > > > > > > It has been pretty quiet here, and maybe that is good. > > > > I was also on vacation (four weeks :>), which delayed > > somewhat this mail. I > > didn't want to start discussion while people were still in > > Finland in the > > VPN workshop, and I regrettably had to leave workshop's > > summary session > > before I could poll it locally. > > > > I still personally feel that with the discussion about s-o-IKE, and > > _especially_ the discussions regarding aggressive/main(/base) > > mode in IPsec > > WG, it might be bad idea to select aggressive-like approach for PIC. > > > > Why do we want to perform significant work on basis of a packet from a > > source which we haven't even verified exists and really wants > > to talk to > > us? > > > > This could be circumvented (at least) by changing the > > exchange from 3 to 4 > > messages and styling it after base mode instead of aggressive mode. > > > > If someone else agrees, feel free to point it out; if it's > > just me, I'll > > go back to my corner :> > > > > > --Paul Hoffman, Director > > > --VPN Consortium > > > > -Markus > > > > -- > > Markus Stenberg (stenberg@ssh.com) of SSH Communications > > Security (www.ssh.com) > > > > From owner-ietf-ipsra@mail.vpnc.org Tue Oct 16 20:41:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23306 for ; Tue, 16 Oct 2001 20:41:38 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9GNpIO12295 for ietf-ipsra-bks; Tue, 16 Oct 2001 16:51:18 -0700 (PDT) Received: from ns02.newbridge.com (ns02.newbridge.com [192.75.23.75]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9GNpHD12291 for ; Tue, 16 Oct 2001 16:51:17 -0700 (PDT) Received: (qmail 17821 invoked from network); 16 Oct 2001 23:49:12 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 16 Oct 2001 23:49:12 -0000 Received: from netmail1.ca.alcatel.com by kanata-mh1.ca.newbridge.com for ietf-ipsra@vpnc.org; Tue, 16 Oct 2001 19:49:03 -0400 Received: (qmail 11473 invoked from network); 16 Oct 2001 23:50:10 -0000 Received: from kanmail02.ca.alcatel.com (HELO kanmail02.ca.newbridge.com) (138.120.118.14) by netmail1.ca.alcatel.com with SMTP; 16 Oct 2001 23:50:10 -0000 Received: from andrewk3 ([138.120.114.30]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA5673; Tue, 16 Oct 2001 19:49:02 -0400 Reply-To: From: "Andrew Krywaniuk" To: "'Hugo Krawczyk'" Cc: Subject: RE: Reminder: last call for PIC in the IPSRA WG Date: Tue, 16 Oct 2001 19:48:29 -0400 Message-Id: <008601c1569d$0f4a0d10$1e72788a@andrewk3.ca.newbridge.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have no doubt that the hash as it exists in PIC is sufficient. I was merely questioning why you would want to do it this way when the revised hash method is easier. I have implemented both for IKE and the advantage of the revised method is that you can create a single function which hashes/verifies any ISAKMP packet regardless of its type. Plus, it accounts for the future use of any header flags, notify payloads, etc. which are security-sensitive. With IKE right now, you have to store parts of previous packets for future use in hash calculations. You either have to store them in raw format (which is inconvenient) or in parsed format, in which case there is potential for error when you reconstruct them. (Imagine if ESP had to selectively include different parts of the packet in order to calculate the hash... oh wait, that's AH.) Andrew ------------------------------------------- Upon closer inspection, I saw that the line dividing black from white was in fact a shade of grey. As I drew nearer still, the grey area grew larger. And then I was enlightened. > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Hugo Krawczyk > Sent: Tuesday, October 16, 2001 6:29 PM > To: Andrew Krywaniuk > Cc: 'Markus Stenberg'; ietf-ipsra@vpnc.org > Subject: RE: Reminder: last call for PIC in the IPSRA WG > > > > Dear Andrew, > > On Mon, 1 Oct 2001, Andrew Krywaniuk wrote: > > > > > In terms of the DoS potential of the Internet, I think > we've only seen the > > tip of the iceberg. It's definitely better to have some > kind of cookie > > exchange. I believe William brought up the lack of DoS > protection at the > > IETF meeting, along with a question about the hash calculation. > > I referred to the DoS protection via cookies in my previous message > to Markus. It is doable, the question is if there is consensus. > > > > > I also wonder about the hash calculation. When Hugo was > asked why we're not > > using the revised hash in PIC, he replied that the > situation that motivated > > the development of revised hash in IKE doesn't exist in > PIC. I guess that's > > true (PIC says you can't include notify or vendor id > payloads until after > > the first hash has been sent), but I still wonder what's > the point? Is there > > any advantage to the particular hash calcuation that is > described in PIC? > > In PIC we have HASH_R in the second message, and HASH in > second, third and > fourth messages. HASH is used to authenticate each of the EAP payloads > (except payload headers -- see (*) below) so it serves for > providing the > cryptographic authentication of the exchanged information and does > not require further complication (e.g. it does not require including > packets from previous messages as suggested in the > revised-hash draft). > > As for HASH_R we are going to include the full ISAKMP headers > from both > messages 1 and 2 under HASH_R which cover CKY-I and CKY-R as in IKE > but also the Major and Minor numbers. > ANother important change in the calculation of HASH_R in PIC > is that it corrects the IKE's typo of missing SA_r from > the authenticated information under HASH_R. Moreover, in PIC also > SA_i is included under HASH_R so the client can verify that its SA > proposals were not modified in route. > > Hugo > > (*) This, however, requires one "design disclaimer" that > appears in the > PIC document (end of section A.1 in the 03 draft): > > ``Another design decision made in order not to change the > regular ISAKMP > processing is to apply authentication (under the HASH payload) > to base payloads only and not to payload headers. Authenticating > all bits, including headers, would have been a better approach but > also in this case we have favored ISAKMP compatibility. '' > > > > > > > Andrew > > ------------------------------------------- > > Upon closer inspection, I saw that the line > > dividing black from white was in fact a shade > > of grey. As I drew nearer still, the grey area > > grew larger. And then I was enlightened. > > > > > > > -----Original Message----- > > > From: owner-ietf-ipsra@mail.vpnc.org > > > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of > Markus Stenberg > > > Sent: Monday, September 17, 2001 8:35 AM > > > To: ietf-ipsra@vpnc.org > > > Subject: Re: Reminder: last call for PIC in the IPSRA WG > > > > > > > > > > > > paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > > > > Hi again. Just a reminder that we are in the middle of > the PIC last > > > > call in the IPSRA WG. The last call ends at the end of September > > > > unless significant changes are needed to the spec. > > > > > > > > It has been pretty quiet here, and maybe that is good. > > > > > > I was also on vacation (four weeks :>), which delayed > > > somewhat this mail. I > > > didn't want to start discussion while people were still in > > > Finland in the > > > VPN workshop, and I regrettably had to leave workshop's > > > summary session > > > before I could poll it locally. > > > > > > I still personally feel that with the discussion about > s-o-IKE, and > > > _especially_ the discussions regarding aggressive/main(/base) > > > mode in IPsec > > > WG, it might be bad idea to select aggressive-like > approach for PIC. > > > > > > Why do we want to perform significant work on basis of a > packet from a > > > source which we haven't even verified exists and really wants > > > to talk to > > > us? > > > > > > This could be circumvented (at least) by changing the > > > exchange from 3 to 4 > > > messages and styling it after base mode instead of > aggressive mode. > > > > > > If someone else agrees, feel free to point it out; if it's > > > just me, I'll > > > go back to my corner :> > > > > > > > --Paul Hoffman, Director > > > > --VPN Consortium > > > > > > -Markus > > > > > > -- > > > Markus Stenberg (stenberg@ssh.com) of SSH Communications > > > Security (www.ssh.com) > > > > > > > > > > > From owner-ietf-ipsra@mail.vpnc.org Wed Oct 17 14:40:44 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03123 for ; Wed, 17 Oct 2001 14:40:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9HHuIh16984 for ietf-ipsra-bks; Wed, 17 Oct 2001 10:56:18 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9HHuCD16980 for ; Wed, 17 Oct 2001 10:56:12 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Oct 2001 10:56:04 -0700 Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Oct 2001 10:56:04 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Oct 2001 10:56:03 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 17 Oct 2001 10:56:03 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3541.1); Wed, 17 Oct 2001 10:55:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 content-class: urn:content-classes:message Subject: RE: Reminder: last call for PIC in the IPSRA WG Date: Wed, 17 Oct 2001 10:55:32 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102533B29@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Reminder: last call for PIC in the IPSRA WG Thread-Index: AcFWlPGSJMqLbvt+QSi4hTgfNSGZGAALaw2g From: "William Dixon" To: "Hugo Krawczyk" , "Markus Stenberg" Cc: "working group ipsra" , "Bernard Aboba" , "Anton Krantz" X-OriginalArrivalTime: 17 Oct 2001 17:55:33.0285 (UTC) FILETIME=[EAD55550:01C15734] Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hugo, et. al. I have a couple of clarifications to ask. Also, I provide a review of EAP-TLS inside PIC which is my exercise to be sure that it should work, but I haven't implemented this. I think the 12 exchanges required provides a good example where revised hash makes things _much_ easier. While I don't see any hard reason stopping PIC from last call WG, I couldn't implement it without the operational additions of NAT traversal and DOS prevention. We do see solid customer requirements for more than just a password hash response to a challenge to authenticate users, even requiring additional organizational data, such as office phone or manager's name before the certificate is issued. This would be provided either as extensions to an EAP method or in the opaque cert request, depending on which backend component validates the information. If it happens in EAP, then certainly the number of message exchanges will extend possibly beyond your stated limit of 10 (repeats of messages 3 & 4). I assume VENDOR-ID payloads are allowed to advertise extension capability as they become needed ala IKE. Reference http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-03.txt Addition #1 - make sure nobody fails the use of private use Type values. The text already does say: "All other Type-Subtype combinations are undefined. They MUST NOT be sent, and MUST be rejected if received." which I think is meant "out of the Types that are defined that are not in the private use range." I'd like a very clear statement in section 4.3.2 and 4.3.3 that payloads containing private use Type values MUST be ignored, not rejected in a way that fails the negotiation. The issue is that a PIC client must try to include all information in the (1) message that the responder will accept, not knowing the version or vendor of the responder. If anything in the initial message causes the negotiation to fail (say a rejected payload), then there is nothing staying the AS MUST reply. Of course we probably want to silently discard. So I want to be sure that AS's won't accidentally reject extra private use payload types. Most implementers of IKE have been pretty good about ignoring vendor-specific attributes or payloads. But not all. Also, I don't see a way to fail the client and notify him to use a different request type. How would that be done ? I assume that VENDOR-ID payloads are allowed in (1) and (2) ? Addition #2 - Use Revised Hash I really wish this was adopted from IKE as a lesson learned. But also, using the revised hash is very practical when PIC is involved in long exchanges, like the 12 round EAP-TLS example below. Clarification #1 So that I'm clear, please confirm the statement "Each of messages 3 and 4 MUST NOT be repeated more than 10 times." is not violated by the EAP-TLS example below, where message 3 is used 6 times. Clarification #2 In section 4.5.2, it says "message (3) is always followed by message (4)". Should there be a specification of when the AS can delete it's SA ? It may suffice to say that the PIC SA management MUST NOT prevent EAP MUST messages from being sent or received. I haven't found a case where it does, and obviously reason prevails. Clarification #3 - add examples of EAP-MD5 and EAP-TLS if we do rev the draft For clarity, and thus for clear interop purposes, I would like to see the actual EAP message sequence for userid/password using MD5-Challenge and an EAP-TLS using client cert authentication be diagrammed. I have done this for EAP-TLS below, please feel free to use it, and hopefully someone will verify this. First let me explain why EAP-TLS when we originally did EAP for legacy authentication. Because the AS itself may not be able to fully authenticate the user locally, rather the AS uses Radius to remote the authentication. EAP-TLS may in fact use a legacy auth method after Radius server authentication. Because I don't want to require legacy authentication when I have a stronger method available with a user certificate. Because PIC may be used by an administrator to request credentials for others and I want to use the admin cert. You might think I as an end user could use my user cert for IKE for the VPN in the first place, but not so, as we have never formally clarified exactly what credential MUST be used for IKE doing remote access VPN, and what that certificate contains. The gateway defines what is acceptable to it, therefore a generic credential (like my USDOD employee cert) may be needed to obtain a more specific credential for VPN access. Certainly if I need a machine credential for IKE to negotiate a security association for L2TP, then I should be able to get it with a user certificate if I have one. And it would appear that PIC may be used in other more general contexts for cert retrieval, outside of it's original purpose of credentialing an IKE negotiation of an IPsec tunnel. As an exercise, I think this is the PIC message sequence for EAP-TLS following RFC 2716, section 3.1 (* means encrypted, "" means I just copied the text from the RFC): (1) no EAP message to avoid clear identification of client userid (2) <---- [EAP-Request/Identity] (3*) [EAP-Response/Identity (userid)] -----> (4*) <---- [EAP-TLS/Start] "this is an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data" (5*) [EAP-Response with EAP-Type=EAP-TLS] -----> "the data field of that packet will encapsulate one or more TLS records in TLS record layer format, containing a TLS client_hello handshake message" (6*) <---- [EAP-Request] "contains a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message. If the EAP server is resuming a previously established session, then it MUST include only a TLS change_cipher_spec message and a TLS finished handshake message after the server_hello message. The finished message contains the EAP server's authentication response to the peer." (7*) [EAP-Response] ------> "data field of this packet will encapsulate one or more TLS records containing a TLS change_cipher_spec message and finished handshake message, and possibly certificate, certificate_verify and/or client_key_exchange handshake messages. If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet indicated the resumption of a previous session, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message contains the peer's authentication response to the EAP server." (8*) <----- [EAP-Request] If the peer's authentication is unsuccessful, the EAP server SHOULD send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS record containing the appropriate TLS alert message. The EAP server SHOULD send a TLS alert message rather immediately terminating the conversation so as to allow the peer to inform the user of the cause of the failure and possibly allow for a restart of the conversation. To ensure that the peer receives the TLS alert message, the EAP server MUST wait for the peer to reply with an EAP-Response packet. (9*) [EAP-Response] -----> "The EAP-Response packet sent by the peer MAY encapsulate a TLS client_hello handshake message" (10*) <----- [EAP-Response] [EAP-Failure] "or it MAY contain an EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case the EAP-Server MUST send an EAP-Failure packet, and terminate the conversation. It is up to the EAP server whether to allow restarts, and if so, how many times the conversation can be restarted. (10*) <----- [EAP-Request] "in which case the EAP server MAY allow the EAP-TLS conversation to be restarted,... An EAP Server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial of service attacks. If the peers authenticates successfully, the EAP server MUST respond with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in the case of a new TLS session one or more TLS records containing TLS change_cipher_spec and finished handshke messages." (11*) [EAP-Request] -----> If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator. To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP-Server to reply before terminating the conversation (12*) <---- [EAP-Response] As an exercise, I think this is the PIC message sequence for EAP-TLS following RFC 2716, section 3.1 (* means encrypted, "" means I just copied the text from the RFC): (1) no EAP message to avoid clear identification of client userid (2) <---- [EAP-Request/Identity] (3*) [EAP-Response/Identity (userid)] -----> (4*) <---- [EAP-TLS/Start] "this is an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data" (5*) [EAP-Response with EAP-Type=EAP-TLS] -----> "the data field of that packet will encapsulate one or more TLS records in TLS record layer format, containing a TLS client_hello handshake message" (6*) <---- [EAP-Request] "contains a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message. If the EAP server is resuming a previously established session, then it MUST include only a TLS change_cipher_spec message and a TLS finished handshake message after the server_hello message. The finished message contains the EAP server's authentication response to the peer." (7*) [EAP-Response] ------> "data field of this packet will encapsulate one or more TLS records containing a TLS change_cipher_spec message and finished handshake message, and possibly certificate, certificate_verify and/or client_key_exchange handshake messages. If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet indicated the resumption of a previous session, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message contains the peer's authentication response to the EAP server." (8*) <----- [EAP-Request] If the peer's authentication is unsuccessful, the EAP server SHOULD send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS record containing the appropriate TLS alert message. The EAP server SHOULD send a TLS alert message rather immediately terminating the conversation so as to allow the peer to inform the user of the cause of the failure and possibly allow for a restart of the conversation. To ensure that the peer receives the TLS alert message, the EAP server MUST wait for the peer to reply with an EAP-Response packet. (9*) [EAP-Response] -----> "The EAP-Response packet sent by the peer MAY encapsulate a TLS client_hello handshake message" (10*) <----- [EAP-Response] [EAP-Failure] "or it MAY contain an EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case the EAP-Server MUST send an EAP-Failure packet, and terminate the conversation. It is up to the EAP server whether to allow restarts, and if so, how many times the conversation can be restarted. (10*) <----- [EAP-Request] "in which case the EAP server MAY allow the EAP-TLS conversation to be restarted,... An EAP Server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial of service attacks. If the peers authenticates successfully, the EAP server MUST respond with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in the case of a new TLS session one or more TLS records containing TLS change_cipher_spec and finished handshke messages." (11*) [EAP-Response, TLS Alert] -----> If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator. To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP-Server to reply before terminating the conversation (12*) <----- [EAP-Failure] The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition or (11*) [EAP-Response] ----------> If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=EAP-TLS, and no data. (12*) <----- [EAP-Success] The EAP-Server then MUST respond with an EAP-Success message Other general comments: I was at least one at the IPSRA meeting who voiced concern about the DOS potential of PIC, particularly given that it is obviously intended for Internet deployment. I was also concerned about NAT transparency for clients behind NATs. And I was concerned about the required fragmentation when passing cert payloads. But our beloved IKE has the same issues. And issues that we have had to implement solutions to for realistic deployment. I think NAT traversal is the most significant real deployment blocker, followed by fragmentation, followed by DOS. Getting the cert and it's chain of course is limited to maximum UDP packet size. But practically, I've seen problems in various network components if packets extend past 4 fragments, sometimes 3. This comes from what I assume are bugs in these components, but also (improperly engineered ?) network connections where a faster link dumps onto slower links, the packet train that the fragments represent causes a fragment to be lost. Retransmissions sometimes work around the problem. And port filtering may or may not track fragments. And the simple NAT devices may have more problems with fragments. I haven't tried to size the packets in the PIC EAP-TLS exchange yet. Certainly the cert payloads can be made small by putting the CA Root or it's 1-level issuing CA as the "CA" in section 1.1. I don't know how many people wanted to use public PKI providers. From my very pitiful adhoc quick check on SSL server cert chains, they chain only to the root. But I know many corporations using at least 3 tier PKI hierarchies. Maybe for VPN, they don't use these. Or in PIC one could just retrieve the CERT package itself, and use other mechanisms to distribute the chain, like downloading it separately from an SSL protected web page link, or installation of client, etc. Wm -----Original Message----- From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] Sent: Tuesday, October 16, 2001 3:24 PM To: Markus Stenberg Cc: working group ipsra Subject: Re: Reminder: last call for PIC in the IPSRA WG Dear Markus, Better later than never... One can add to PIC some DOS protection via two extra initial messages (this is what I said during the London ietf meeting when asked about it). Adding these messages is quite straightorward from the point of view of specification (the messages would carry a cookie from client to server and one from server to client -- the last one being a stateless cookie a la Karn) but it certainly adds performance and protocol complexity. Having lacked explicit requirements for such measures we settled for simplicity nd less performance penalty. If you obtain consensus to add this stuff, then it is doable. As for your suggestion to use base mode: this solution would be inappropriate here. It requires a responder's state anyway and its main advantage in the context of IKE is lost here. This advantage is that the responder can do a (rleatively cheap) RSA sig verification before it performs its own signature and the g^xy DH exponentiation. However, in PIC there is no signature from the client at all, so this mechanism of base mode does not aply here. Thanks for the feedback. Hugo On 17 Sep 2001, Markus Stenberg wrote: > > paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > > Hi again. Just a reminder that we are in the middle of the PIC last > > call in the IPSRA WG. The last call ends at the end of September > > unless significant changes are needed to the spec. > > > > It has been pretty quiet here, and maybe that is good. > > I was also on vacation (four weeks :>), which delayed somewhat this > mail. I didn't want to start discussion while people were still in > Finland in the VPN workshop, and I regrettably had to leave workshop's > summary session before I could poll it locally. > > I still personally feel that with the discussion about s-o-IKE, and > _especially_ the discussions regarding aggressive/main(/base) mode in > IPsec WG, it might be bad idea to select aggressive-like approach for > PIC. > > Why do we want to perform significant work on basis of a packet from a > source which we haven't even verified exists and really wants to talk > to us? > > This could be circumvented (at least) by changing the exchange from 3 > to 4 messages and styling it after base mode instead of aggressive > mode. > > If someone else agrees, feel free to point it out; if it's just me, > I'll go back to my corner :> > > > --Paul Hoffman, Director > > --VPN Consortium > > -Markus > > -- > Markus Stenberg (stenberg@ssh.com) of SSH Communications Security > (www.ssh.com) > From owner-ietf-ipsra@mail.vpnc.org Fri Oct 19 17:38:52 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02439 for ; Fri, 19 Oct 2001 17:38:51 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9JKxTc10352 for ietf-ipsra-bks; Fri, 19 Oct 2001 13:59:29 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9JKxQD10347 for ; Fri, 19 Oct 2001 13:59:26 -0700 (PDT) Received: (qmail 30308 invoked by uid 0); 19 Oct 2001 20:59:17 -0000 Received: from unknown (HELO oemcomputer) (212.150.115.168) by mail.gmx.net (mp007-rz3) with SMTP; 19 Oct 2001 20:59:17 -0000 From: "Yaron Sheffer" To: "William Dixon" , "Hugo Krawczyk" , "Markus Stenberg" Cc: "working group ipsra" , "Bernard Aboba" , "Anton Krantz" Subject: RE: Reminder: last call for PIC in the IPSRA WG Date: Fri, 19 Oct 2001 22:58:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi William, thanks for your thorough response. Regarding NAT traversal, PIC does not have the issues that full IKE needs to solve. So PIC over NAT only requires that the server not check the source port, and of course reply on that same port. See Sec. 4.1 in the draft. Regarding DOS protection. As Hugo mentioned in his recent mail, it is a simple matter to add 2 messages between messages (1) and (2), thus verifying the routability of the client. However, it is obviously not a change to be done at the last moment. Unless we can think of a better solution, the Exchange Type (Sec. 3.1) can be treated as a PIC version number, and such extensions can be added in the future. That is, if people are willing to pay for DOS protection by an additional exchange. I would appreciate any proposal of a more elegant, forward compatible mechanism. Regarding fragmentation, I share your concern. It is an issue for PIC, just as it is for IKE. As an anecdote, *TCP* port 500 is reserved for ISAKMP. Maybe that's the way to go... See more comments below, prefixed by YS. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of William Dixon Sent: Wednesday, October 17, 2001 7:56 PM To: Hugo Krawczyk; Markus Stenberg Cc: working group ipsra; Bernard Aboba; Anton Krantz Subject: RE: Reminder: last call for PIC in the IPSRA WG Hugo, et. al. I have a couple of clarifications to ask. Also, I provide a review of EAP-TLS inside PIC which is my exercise to be sure that it should work, but I haven't implemented this. I think the 12 exchanges required provides a good example where revised hash makes things _much_ easier. While I don't see any hard reason stopping PIC >from last call WG, I couldn't implement it without the operational additions of NAT traversal and DOS prevention. We do see solid customer requirements for more than just a password hash response to a challenge to authenticate users, even requiring additional organizational data, such as office phone or manager's name before the certificate is issued. This would be provided either as extensions to an EAP method or in the opaque cert request, depending on which backend component validates the information. If it happens in EAP, then certainly the number of message exchanges will extend possibly beyond your stated limit of 10 (repeats of messages 3 & 4). I assume VENDOR-ID payloads are allowed to advertise extension capability as they become needed ala IKE. YS: yes, ISAKMP notification, including VENDOR-ID are OK. Reference http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-03.txt Addition #1 - make sure nobody fails the use of private use Type values. The text already does say: "All other Type-Subtype combinations are undefined. They MUST NOT be sent, and MUST be rejected if received." which I think is meant "out of the Types that are defined that are not in the private use range." I'd like a very clear statement in section 4.3.2 and 4.3.3 that payloads containing private use Type values MUST be ignored, not rejected in a way that fails the negotiation. The issue is that a PIC client must try to include all information in the (1) message that the responder will accept, not knowing the version or vendor of the responder. If anything in the initial message causes the negotiation to fail (say a rejected payload), then there is nothing staying the AS MUST reply. Of course we probably want to silently discard. So I want to be sure that AS's won't accidentally reject extra private use payload types. Most implementers of IKE have been pretty good about ignoring vendor-specific attributes or payloads. But not all. Also, I don't see a way to fail the client and notify him to use a different request type. How would that be done ? I assume that VENDOR-ID payloads are allowed in (1) and (2) ? YS: First, please note that only one CREDENTIAL-REQUEST and one CREDENTIAL payload are allowed in a PIC exchange. We conciously avoided any negotiation here. If you insist on negotiation, you can include a VENDOR-ID in message (1), and have the server return a value of None for the Type field in the CRED payload. The client can then try something else. But as you mentioned, the server is not obligated to reply at all. Addition #2 - Use Revised Hash I really wish this was adopted from IKE as a lesson learned. But also, using the revised hash is very practical when PIC is involved in long exchanges, like the 12 round EAP-TLS example below. YS: we simply didn't want to do it before it is adopted for IKE. But maybe we shod have. Clarification #1 So that I'm clear, please confirm the statement "Each of messages 3 and 4 MUST NOT be repeated more than 10 times." is not violated by the EAP-TLS example below, where message 3 is used 6 times. YS: confirmed. 6 <= 10 :-) Clarification #2 In section 4.5.2, it says "message (3) is always followed by message (4)". Should there be a specification of when the AS can delete it's SA ? It may suffice to say that the PIC SA management MUST NOT prevent EAP MUST messages from being sent or received. I haven't found a case where it does, and obviously reason prevails. YS: I don't understand your point. Could you please explain? Clarification #3 - add examples of EAP-MD5 and EAP-TLS if we do rev the draft For clarity, and thus for clear interop purposes, I would like to see the actual EAP message sequence for userid/password using MD5-Challenge and an EAP-TLS using client cert authentication be diagrammed. I have done this for EAP-TLS below, please feel free to use it, and hopefully someone will verify this. First let me explain why EAP-TLS when we originally did EAP for legacy authentication. Because the AS itself may not be able to fully authenticate the user locally, rather the AS uses Radius to remote the authentication. EAP-TLS may in fact use a legacy auth method after Radius server authentication. Because I don't want to require legacy authentication when I have a stronger method available with a user certificate. Because PIC may be used by an administrator to request credentials for others and I want to use the admin cert. You might think I as an end user could use my user cert for IKE for the VPN in the first place, but not so, as we have never formally clarified exactly what credential MUST be used for IKE doing remote access VPN, and what that certificate contains. The gateway defines what is acceptable to it, therefore a generic credential (like my USDOD employee cert) may be needed to obtain a more specific credential for VPN access. Certainly if I need a machine credential for IKE to negotiate a security association for L2TP, then I should be able to get it with a user certificate if I have one. And it would appear that PIC may be used in other more general contexts for cert retrieval, outside of it's original purpose of credentialing an IKE negotiation of an IPsec tunnel. YS: while I agree with your ideas, PIC only provides a partial solution, and was certainly not conceived as a general credential provisioning protocol. There is only so much you can do without negotiation of credential policy, for example. The PIC protocol is ignorant of the actual credentials that it transports. As an exercise, I think this is the PIC message sequence for EAP-TLS following RFC 2716, section 3.1 (* means encrypted, "" means I just copied the text from the RFC): (1) no EAP message to avoid clear identification of client userid YS: note that PIC does not allow an EAP payload in message (1). On the other hand, there is an optional ID payload, which you're obviously not sending. (2) <---- [EAP-Request/Identity] (3*) [EAP-Response/Identity (userid)] -----> (4*) <---- [EAP-TLS/Start] "this is an EAP-Request packet with EAP-Type=EAP-TLS, the Start (S) bit set, and no data" (5*) [EAP-Response with EAP-Type=EAP-TLS] -----> "the data field of that packet will encapsulate one or more TLS records in TLS record layer format, containing a TLS client_hello handshake message" (6*) <---- [EAP-Request] "contains a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message. If the EAP server is resuming a previously established session, then it MUST include only a TLS change_cipher_spec message and a TLS finished handshake message after the server_hello message. The finished message contains the EAP server's authentication response to the peer." (7*) [EAP-Response] ------> "data field of this packet will encapsulate one or more TLS records containing a TLS change_cipher_spec message and finished handshake message, and possibly certificate, certificate_verify and/or client_key_exchange handshake messages. If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet indicated the resumption of a previous session, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message contains the peer's authentication response to the EAP server." (8*) <----- [EAP-Request] If the peer's authentication is unsuccessful, the EAP server SHOULD send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS record containing the appropriate TLS alert message. The EAP server SHOULD send a TLS alert message rather immediately terminating the conversation so as to allow the peer to inform the user of the cause of the failure and possibly allow for a restart of the conversation. To ensure that the peer receives the TLS alert message, the EAP server MUST wait for the peer to reply with an EAP-Response packet. (9*) [EAP-Response] -----> "The EAP-Response packet sent by the peer MAY encapsulate a TLS client_hello handshake message" (10*) <----- [EAP-Response] [EAP-Failure] "or it MAY contain an EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case the EAP-Server MUST send an EAP-Failure packet, and terminate the conversation. It is up to the EAP server whether to allow restarts, and if so, how many times the conversation can be restarted. YS: the above would necessarily terminate the PIC exchange, so it MUST include an empty CREDENTIAL payload. Actually, we shouldn't require this payload in the case of authentication failure. I will change the text accordingly. (10*) <----- [EAP-Request] "in which case the EAP server MAY allow the EAP-TLS conversation to be restarted,... An EAP Server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial of service attacks. If the peers authenticates successfully, the EAP server MUST respond with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in the case of a new TLS session one or more TLS records containing TLS change_cipher_spec and finished handshke messages." (11*) [EAP-Response, TLS Alert] -----> If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator. To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP-Server to reply before terminating the conversation (12*) <----- [EAP-Failure] The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition or (11*) [EAP-Response] ----------> If the EAP server authenticates successfully, the peer MUST send an EAP-Response packet of EAP-Type=EAP-TLS, and no data. (12*) <----- [EAP-Success] The EAP-Server then MUST respond with an EAP-Success message Other general comments: I was at least one at the IPSRA meeting who voiced concern about the DOS potential of PIC, particularly given that it is obviously intended for Internet deployment. I was also concerned about NAT transparency for clients behind NATs. And I was concerned about the required fragmentation when passing cert payloads. But our beloved IKE has the same issues. And issues that we have had to implement solutions to for realistic deployment. I think NAT traversal is the most significant real deployment blocker, followed by fragmentation, followed by DOS. Getting the cert and it's chain of course is limited to maximum UDP packet size. But practically, I've seen problems in various network components if packets extend past 4 fragments, sometimes 3. This comes from what I assume are bugs in these components, but also (improperly engineered ?) network connections where a faster link dumps onto slower links, the packet train that the fragments represent causes a fragment to be lost. Retransmissions sometimes work around the problem. And port filtering may or may not track fragments. And the simple NAT devices may have more problems with fragments. I haven't tried to size the packets in the PIC EAP-TLS exchange yet. Certainly the cert payloads can be made small by putting the CA Root or it's 1-level issuing CA as the "CA" in section 1.1. I don't know how many people wanted to use public PKI providers. From my very pitiful adhoc quick check on SSL server cert chains, they chain only to the root. But I know many corporations using at least 3 tier PKI hierarchies. Maybe for VPN, they don't use these. Or in PIC one could just retrieve the CERT package itself, and use other mechanisms to distribute the chain, like downloading it separately from an SSL protected web page link, or installation of client, etc. Wm -----Original Message----- From: Hugo Krawczyk [mailto:hugo@ee.technion.ac.il] Sent: Tuesday, October 16, 2001 3:24 PM To: Markus Stenberg Cc: working group ipsra Subject: Re: Reminder: last call for PIC in the IPSRA WG Dear Markus, Better later than never... One can add to PIC some DOS protection via two extra initial messages (this is what I said during the London ietf meeting when asked about it). Adding these messages is quite straightorward from the point of view of specification (the messages would carry a cookie from client to server and one from server to client -- the last one being a stateless cookie a la Karn) but it certainly adds performance and protocol complexity. Having lacked explicit requirements for such measures we settled for simplicity nd less performance penalty. If you obtain consensus to add this stuff, then it is doable. As for your suggestion to use base mode: this solution would be inappropriate here. It requires a responder's state anyway and its main advantage in the context of IKE is lost here. This advantage is that the responder can do a (rleatively cheap) RSA sig verification before it performs its own signature and the g^xy DH exponentiation. However, in PIC there is no signature from the client at all, so this mechanism of base mode does not aply here. Thanks for the feedback. Hugo On 17 Sep 2001, Markus Stenberg wrote: > > paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > > Hi again. Just a reminder that we are in the middle of the PIC last > > call in the IPSRA WG. The last call ends at the end of September > > unless significant changes are needed to the spec. > > > > It has been pretty quiet here, and maybe that is good. > > I was also on vacation (four weeks :>), which delayed somewhat this > mail. I didn't want to start discussion while people were still in > Finland in the VPN workshop, and I regrettably had to leave workshop's > summary session before I could poll it locally. > > I still personally feel that with the discussion about s-o-IKE, and > _especially_ the discussions regarding aggressive/main(/base) mode in > IPsec WG, it might be bad idea to select aggressive-like approach for > PIC. > > Why do we want to perform significant work on basis of a packet from a > source which we haven't even verified exists and really wants to talk > to us? > > This could be circumvented (at least) by changing the exchange from 3 > to 4 messages and styling it after base mode instead of aggressive > mode. > > If someone else agrees, feel free to point it out; if it's just me, > I'll go back to my corner :> > > > --Paul Hoffman, Director > > --VPN Consortium > > -Markus > > -- > Markus Stenberg (stenberg@ssh.com) of SSH Communications Security > (www.ssh.com) > From owner-ietf-ipsra@mail.vpnc.org Fri Oct 19 22:19:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13097 for ; Fri, 19 Oct 2001 22:19:36 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id f9K1ga116418 for ietf-ipsra-bks; Fri, 19 Oct 2001 18:42:36 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9K1gZD16414 for ; Fri, 19 Oct 2001 18:42:35 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id SAA15470; Fri, 19 Oct 2001 18:34:13 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 19 Oct 2001 18:34:13 -0700 (PDT) From: Bernard Aboba To: Yaron Sheffer cc: William Dixon , Hugo Krawczyk , Markus Stenberg , working group ipsra , Bernard Aboba , Anton Krantz Subject: RE: Reminder: last call for PIC in the IPSRA WG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Regarding fragmentation, I share your concern. It is an issue for PIC, just > as it is for IKE. As an anecdote, *TCP* port 500 is reserved for ISAKMP. > Maybe that's the way to go... > The IKE fragmentation problem is in practice a *major* issue -- because long cert chains cause IKE to frag and most routers can't properly filter the frags. The reason that this hasn't gotten more visiblity is that the vast majority of IPsec implementations use shared secrets. But of course, the whole point of PIC is to enable cert enrollment, so we cannot avoid it. For my two cents, I believe that PIC should run over TCP by default. From owner-ietf-ipsra@mail.vpnc.org Tue Oct 30 14:25:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12246 for ; Tue, 30 Oct 2001 14:25:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9UIdeR12186 for ietf-ipsra-bks; Tue, 30 Oct 2001 10:39:40 -0800 (PST) Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UIdc812179 for ; Tue, 30 Oct 2001 10:39:38 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Tue, 30 Oct 2001 10:39:36 -0800 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Moving PIC forwards Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There was some substantiative points raised during the IETF last call. William Dixon made some requests for clarification that Yaron agreed were good. Yaron/Hugo: will there be a new draft soon with these clarifications? There were a few people who felt that the protocol needed to be changed to prevent denial-of-service attacks. Hugo said that was pretty easy (add a round trip with a cookie at the beginning of the exchanges), and a few people said they wanted this, but not many people spoke up. So, I would like to do a short straw poll of the group. There are three choices: (a) leave the protocol as it is (b) add DOS protection as Hugo described (c) something else Choice (a) is easier and will get the protocol done sooner. Choice (b) adds some protection but requires a new round of the document and a new round of people reading the document. If you choose choice (c), please say what it is you want. Please express your interest on the list or to me in private, and do so within a week (before November 7). Thanks! --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Tue Oct 30 15:05:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13277 for ; Tue, 30 Oct 2001 15:05:59 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9UJKME13508 for ietf-ipsra-bks; Tue, 30 Oct 2001 11:20:22 -0800 (PST) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9UJKK813501; Tue, 30 Oct 2001 11:20:20 -0800 (PST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA38719; Tue, 30 Oct 2001 11:11:34 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 30 Oct 2001 11:11:33 -0800 (PST) From: Bernard Aboba To: Paul Hoffman / VPNC cc: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > (c) something else > > If you choose choice (c), > please say what it is you want. > I'd like the protocol to run over TCP, so that we can handle large certificate payloads without fragmentation. In practice, fragmentation of IKE cert payloads has turned out to be a headache, because many existing router code loads cannot handle fragment filtering very well. It would be much easier if PIC could just be installed in a network without having to upgrade the routers. From owner-ietf-ipsra@mail.vpnc.org Tue Oct 30 17:47:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16526 for ; Tue, 30 Oct 2001 17:47:23 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9ULnNF19169 for ietf-ipsra-bks; Tue, 30 Oct 2001 13:49:23 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9ULnL819163; Tue, 30 Oct 2001 13:49:21 -0800 (PST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9ULnO912492; Tue, 30 Oct 2001 13:49:24 -0800 (PST) Received: from janpc-home.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f9ULnIb01127; Tue, 30 Oct 2001 13:49:18 -0800 (PST) Date: Tue, 30 Oct 2001 13:49:17 -0800 (PST) From: Jan Vilhuber To: Bernard Aboba cc: Paul Hoffman / VPNC , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Of course that opens up TCP RST attacks and such... But I agree with the fragmentation issues... jan On Tue, 30 Oct 2001, Bernard Aboba wrote: > > > (c) something else > > > > If you choose choice (c), > > please say what it is you want. > > > > I'd like the protocol to run over TCP, so that we can handle large > certificate payloads without fragmentation. In practice, fragmentation of > IKE cert payloads has turned out to be a headache, because many > existing router code loads cannot handle fragment filtering very well. > > It would be much easier if PIC could just be installed in a network > without having to upgrade the routers. > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 03:09:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08720 for ; Wed, 31 Oct 2001 03:09:16 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9V79aU03926 for ietf-ipsra-bks; Tue, 30 Oct 2001 23:09:36 -0800 (PST) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9V79Y803921 for ; Tue, 30 Oct 2001 23:09:34 -0800 (PST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f9V79cf12527 for ; Wed, 31 Oct 2001 09:09:38 +0200 (EET) Received: (qmail 4758 invoked from network); 31 Oct 2001 07:09:37 -0000 Received: from unknown (HELO porsas.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 31 Oct 2001 07:09:37 -0000 Received: by porsas.hel.fi.ssh.com (Postfix, from userid 1000) id 8CFBB2ACD7; Wed, 31 Oct 2001 09:09:27 +0200 (EET) To: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards References: Organization: SSH Communications Security From: Markus Stenberg Date: 31 Oct 2001 09:09:27 +0200 In-Reply-To: Message-ID: <87pu748evs.fsf@porsas.hel.fi.ssh.com> Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes: > (b) add DOS protection as Hugo described My vote goes for [b]. And then, to continue discussion.. ,---- | I'd like the protocol to run over TCP, so that we can handle large | certificate payloads without fragmentation. In practice, fragmentation of | IKE cert payloads has turned out to be a headache, because many | existing router code loads cannot handle fragment filtering very well. | | It would be much easier if PIC could just be installed in a network | without having to upgrade the routers. `---- Considering world seems to be full of routers with broken PMTU / filtered icmp-unreachable functionality, we're bound see lots of fragmented IPsec packets in any case. Can we therefore assume that those are gone, too? I'm not too happy with the conclusion.. (But still, I think that the TCP _would_ be worth it but not this close to actually deploying PIC; maybe in son-of-PIC :>) Now, son-of-IKE's another matter; I think TCP'd make some things _much_ easier (considering in _all_ interops I've been to, I've ran at implementations with such basic features as proper packet resends broken). -Markus -- Markus Stenberg of SSH Communications Security (www.ssh.com) From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 06:03:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09932 for ; Wed, 31 Oct 2001 06:03:36 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9VAA9G02787 for ietf-ipsra-bks; Wed, 31 Oct 2001 02:10:09 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VAA5802767; Wed, 31 Oct 2001 02:10:05 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VAA3C16473; Wed, 31 Oct 2001 11:10:03 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VAA3B11161; Wed, 31 Oct 2001 12:10:03 +0200 (EET) Message-ID: <3BDFCDFB.F6C7FBE1@lmf.ericsson.se> Date: Wed, 31 Oct 2001 12:10:03 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba CC: Paul Hoffman / VPNC , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >I'd like the protocol to run over TCP, so that we >can handle large certificate payloads without fragmentation. A concern with PIC is the added RTTs, which are a pain in cellular networks. Making the protocol run over TCP would make things worse. I suggest that we still keep the UDP bearer and deal with the routers that may exist in between. Besides, for the problem to occur you must have a firewalling router between the businessman's PC and the corporate PIC node /VPN gateway. How likely is that? Network operators hopefully shouldn't be filtering your traffic, so that leaves the corporate network border routers possibly in front of the PIC/VPN nodes. If they can't handle fragmented UDP packets, the network manager can upgrade the routers at the same time he installs PIC. Or? Jari From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 09:29:02 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19691 for ; Wed, 31 Oct 2001 09:29:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VDkme16921 for ietf-ipsra-bks; Wed, 31 Oct 2001 05:46:48 -0800 (PST) Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VDkh816912; Wed, 31 Oct 2001 05:46:46 -0800 (PST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 678767C01; Wed, 31 Oct 2001 08:45:39 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: Jari Arkko Cc: Bernard Aboba , Paul Hoffman / VPNC , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 31 Oct 2001 08:45:39 -0500 Message-Id: <20011031134539.678767C01@berkshire.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In message <3BDFCDFB.F6C7FBE1@lmf.ericsson.se>, Jari Arkko writes: > >Besides, for the problem to occur you must have >a firewalling router between the businessman's >PC and the corporate PIC node /VPN gateway. How >likely is that? Network operators hopefully shouldn't >be filtering your traffic, so that leaves the >corporate network border routers possibly in front >of the PIC/VPN nodes. If they can't handle fragmented >UDP packets, the network manager can upgrade the >routers at the same time he installs PIC. Or? > One cause of the fragmentation problem is PPPoE. You may not like PPPoE (I certainly don't), but there's a lot of it out there on DSL lines. None of which, of course, says that we need to break our protocol to deal with it. But v6 doesn't even have router-based fragmentation, so we may want to plan ahead. Do we want to go as far as to recommend intentional fragmentation at some rational threshhold? --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 09:45:29 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20345 for ; Wed, 31 Oct 2001 09:45:29 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9VE97617645 for ietf-ipsra-bks; Wed, 31 Oct 2001 06:09:07 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VE95817634; Wed, 31 Oct 2001 06:09:05 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f9VE8vf00775; Wed, 31 Oct 2001 15:08:57 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f9VE8tB21097; Wed, 31 Oct 2001 16:08:55 +0200 (EET) Message-ID: <3BE005F7.647CBE7D@lmf.ericsson.se> Date: Wed, 31 Oct 2001 16:08:55 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Bernard Aboba , Paul Hoffman / VPNC , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards References: <20011031134539.678767C01@berkshire.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >One cause of the fragmentation problem is PPPoE. >... >But v6 doesn't even have router-based fragmentation, so >we may want to plan ahead >... Fragmentation as such isn't sufficient to cause a problem. You also need a firewalling router or something like that to drop all fragments packets, because they weren't programmed to deal with that. IPv6 still allows up to 2^16 (or even 2^32) bytes long UDP packets. The place of the fragmentation is different, though, it's e2e. But let's turn back to Bernard's original problem. He said "I'd like the protocol to run over TCP, so that we can handle large certificate payloads without fragmentation. In practice, fragmentation of IKE cert payloads has turned out to be a headache..." So, let's assume our setup is (a) PIC to node 1 in a corporate network followed by (b) IKE+IPSEC to a node 2 in a corporate network. PIC has long payloads, and so does IKE where certs are used. Then we also assume there's a broken router somewhere that doesn't do fragment filtering correctly. So, what would be the effect of providing improved TCP PIC? Step a could then be accomplished, but no communication could be established because Step b would break at the router. In conclusion, it seems that TCP PIC isn't useful until IKE runs over TCP too. In the mean time we have to ensure our routers and firewalls do the right thing. TCP PIC doesn't help. But, Bernard, is the problem the same in PIC as it is in IKE cert payloads, or is it bigger? If we rarely hit the problem in IKE but would hit it all the time in PIC, then it might make sense think more about it. Jari From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 10:30:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21718 for ; Wed, 31 Oct 2001 10:30:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9VEiig20173 for ietf-ipsra-bks; Wed, 31 Oct 2001 06:44:44 -0800 (PST) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VEih820166; Wed, 31 Oct 2001 06:44:43 -0800 (PST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA40130; Wed, 31 Oct 2001 06:35:47 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 31 Oct 2001 06:35:47 -0800 (PST) From: Bernard Aboba To: "Steven M. Bellovin" cc: Jari Arkko , Paul Hoffman / VPNC , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards In-Reply-To: <20011031134539.678767C01@berkshire.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > One cause of the fragmentation problem is PPPoE. You may not like > PPPoE (I certainly don't), but there's a lot of it out there on DSL > lines. From what I've seen, the issue is due to large cert payloads, so that the fragmentation occurs at the endpoint, not in the middle of the network. > None of which, of course, says that we need to break our protocol to > deal with it. But v6 doesn't even have router-based fragmentation, so > we may want to plan ahead. Do we want to go as far as to recommend > intentional fragmentation at some rational threshhold? The fragmentation I've observed is already intentional. If people aren't up for TCP, then another alternative would be support of a "continuation" mechanism to spread the cert payload across multiple UDP packets. From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 10:30:06 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21730 for ; Wed, 31 Oct 2001 10:30:06 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9VEfvW20121 for ietf-ipsra-bks; Wed, 31 Oct 2001 06:41:57 -0800 (PST) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VEfu820115; Wed, 31 Oct 2001 06:41:56 -0800 (PST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA40123; Wed, 31 Oct 2001 06:33:01 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 31 Oct 2001 06:33:01 -0800 (PST) From: Bernard Aboba To: Jari Arkko cc: Paul Hoffman / VPNC , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards In-Reply-To: <3BDFCDFB.F6C7FBE1@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Besides, for the problem to occur you must have > a firewalling router between the businessman's > PC and the corporate PIC node /VPN gateway. How > likely is that? If the PIC node is not deployed on a router, then from what I've seen, this is the default configuration. > If they can't handle fragmented > UDP packets, the network manager can upgrade the > routers at the same time he installs PIC. Or? In the customer base I've talked to there are no immediate plans for such upgrades -- since that would require more memory and ROM in the affected routers, and that's not in the budget. In general, they don't like operating with very different code loads in different sections of the network, so this is more likely to be seen as part of a wider upgrade. Even in those cases where the upgrade is feasible, customers often don't want to do it because they are afraid of side effects such as enabling fragment attacks. From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 10:33:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21851 for ; Wed, 31 Oct 2001 10:33:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9VEn7D20340 for ietf-ipsra-bks; Wed, 31 Oct 2001 06:49:07 -0800 (PST) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VEn5820328; Wed, 31 Oct 2001 06:49:05 -0800 (PST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA40141; Wed, 31 Oct 2001 06:40:09 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 31 Oct 2001 06:40:09 -0800 (PST) From: Bernard Aboba To: Jari Arkko cc: "Steven M. Bellovin" , Paul Hoffman / VPNC , ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards In-Reply-To: <3BE005F7.647CBE7D@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > In conclusion, it seems that TCP PIC isn't useful > until IKE runs over TCP too. In the mean time > we have to ensure our routers and firewalls > do the right thing. TCP PIC doesn't help. But, > Bernard, is the problem the same in PIC as it is > in IKE cert payloads, or is it bigger? If we rarely > hit the problem in IKE but would hit it all the time > in PIC, then it might make sense think more about it. It depends on how big the cert payloads are. The particular circumstances I've seen occur with certificate chains. You are correct that IKE will also fragment -- but often the IKE negotiation will occur on a specialized VPN box that can can include the right fragment filtering functionality, whereas the PIC node seems more likely to be a host that will need a filtering router in front of it. From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 13:08:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26507 for ; Wed, 31 Oct 2001 13:08:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VHFWm06151 for ietf-ipsra-bks; Wed, 31 Oct 2001 09:15:32 -0800 (PST) Received: from fw.hel.fi.ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VHFT806146 for ; Wed, 31 Oct 2001 09:15:29 -0800 (PST) Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.27) with SMTP id f9VHFUf20783 for ; Wed, 31 Oct 2001 19:15:30 +0200 (EET) Received: (qmail 28474 invoked from network); 31 Oct 2001 17:15:29 -0000 Received: from unknown (HELO porsas.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 31 Oct 2001 17:15:29 -0000 Received: by porsas.hel.fi.ssh.com (Postfix, from userid 1000) id AC3C62AD15; Wed, 31 Oct 2001 19:15:18 +0200 (EET) To: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards References: Organization: SSH Communications Security From: Markus Stenberg Date: 31 Oct 2001 19:15:18 +0200 In-Reply-To: Message-ID: <87itcv4tp5.fsf@porsas.hel.fi.ssh.com> Lines: 35 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: aboba@internaut.com (Bernard Aboba) writes: > The fragmentation I've observed is already intentional. If people aren't > up for TCP, then another alternative would be support of a > "continuation" mechanism to spread the cert payload across multiple UDP > packets. What MTU should we use then? 576? Doesn't this triple+ number of packets in normal case and it'd happen only thanks to braindead routers? [ one can argue that 1500-byte packets are de facto, but one can also argue that is using ADSL+PPPoE with low MTU.. ] (Secondary alternative, own PMTU-detection scheme by trial-and-error, I won't even go to.. nor user configuration :P) Is the problem _really_ out there? I personally haven't encountered it much, but my cert chains have been mostly on short side. - If the problem is broken configuration of a firewall (i.e. I know of firewalls that have been configured with insanely low number of fragments to keep / time to keep them), then it can be amended (hopefully) by cluebrick. - If it's matter of product, we should just embrace some form of 'IPsec compatible' term to differentiate between broken and working firewalls. Admittedly, I know firsthand the pain of "we do not want to change " in organizations, but still, I find it interesting that some parties in IETF push for weird (and of course useful) stuff like IPv6 which requires total change of hardware et al, and others (like us, it seems) are mostly concerned in getting SOMETHING working by kludging around existing crap out there. (and to be politically correct, no offense, for the humor impaired that happen to have/work on firewall which is broken) -Markus From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 14:21:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28557 for ; Wed, 31 Oct 2001 14:21:13 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id f9VIRSs07990 for ietf-ipsra-bks; Wed, 31 Oct 2001 10:27:28 -0800 (PST) Received: from internaut.com ([64.38.134.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VIRR807986 for ; Wed, 31 Oct 2001 10:27:27 -0800 (PST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA40619; Wed, 31 Oct 2001 10:18:29 -0800 (PST) (envelope-from aboba@internaut.com) Date: Wed, 31 Oct 2001 10:18:29 -0800 (PST) From: Bernard Aboba To: Markus Stenberg cc: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards In-Reply-To: <87itcv4tp5.fsf@porsas.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > (Secondary alternative, own PMTU-detection scheme by trial-and-error, I > won't even go to.. nor user configuration :P) Going to minimum MTU all the time is not a good strategy, I'd agree. Not sure that PMTU discovery would be so bad though -- could be made fairly simple. For example, set the DF bit, and if fragmentation is encountered move down in large increments. In any of these cases, you'd need the "continuation" capability, though. > Is the problem _really_ out there? I personally haven't encountered it > much, but my cert chains have been mostly on short side. The problem is very common among organizations that have deployed LDAP-based directories. IT organizations often have sophisticated directory structures, and the chain of trust is reflective of their organizational hierarchy. So the Swedish branch office would be under Europe, which is part of Products Group, which is within the Automotive Division, and this results in a long cert chain. > - If it's matter of product, we should just embrace some form of 'IPsec > compatible' term to differentiate between broken and working firewalls. Not easy to do when *most* existing routers do not support fragment filtering very well. Remember, fragments don't necessary have a header/port present, so you have keep state in order to handle this correctly. > and others (like us, it seems) are mostly concerned in getting SOMETHING > working by kludging around existing crap out there. Yup. Have been working on IPsec since 1996 now, and am still struggling to get a wide spread cert-based deployment going. At this point, believe it or not, the IKE fragmentation issue is probably a bigger headache than getting the PKI infrastructure up, and even deploying smartcards and directories. From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 16:41:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03653 for ; Wed, 31 Oct 2001 16:41:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VKs6A14555 for ietf-ipsra-bks; Wed, 31 Oct 2001 12:54:06 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f9VKs5814550 for ; Wed, 31 Oct 2001 12:54:05 -0800 (PST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f9VKplM05864; Wed, 31 Oct 2001 12:51:47 -0800 (PST) Received: from sfanninglaptop (dhcp-171-69-39-3.cisco.com [171.69.39.3]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id ACM52238; Wed, 31 Oct 2001 12:44:21 -0800 (PST) Message-ID: <00f501c1624f$934e5f90$032745ab@sfanninglaptop> From: "Scott Fanning" To: "Bernard Aboba" , "Markus Stenberg" Cc: References: Subject: Re: Moving PIC forwards Date: Wed, 31 Oct 2001 13:04:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just another data point. I have seen some fragmentation issues even with large (4k) key sizes. I agree that this is a real issue. Scott ----- Original Message ----- From: "Bernard Aboba" To: "Markus Stenberg" Cc: Sent: Wednesday, October 31, 2001 10:18 AM Subject: Re: Moving PIC forwards > > > (Secondary alternative, own PMTU-detection scheme by trial-and-error, I > > won't even go to.. nor user configuration :P) > > Going to minimum MTU all the time is not a good strategy, I'd agree. Not > sure that PMTU discovery would be so bad though -- could be made fairly > simple. For example, set the DF bit, and if fragmentation is encountered > move down in large increments. In any of these cases, you'd need the > "continuation" capability, though. > > > Is the problem _really_ out there? I personally haven't encountered it > > much, but my cert chains have been mostly on short side. > > The problem is very common among organizations that have deployed > LDAP-based directories. > > IT organizations often have sophisticated directory structures, and the > chain of trust is reflective of their organizational hierarchy. So the > Swedish branch office would be under Europe, which is part of Products > Group, which is within the Automotive Division, and this results in a long > cert chain. > > > - If it's matter of product, we should just embrace some form of 'IPsec > > compatible' term to differentiate between broken and working firewalls. > > Not easy to do when *most* existing routers do not support fragment > filtering very well. Remember, fragments don't necessary have a > header/port present, so you have keep state in order to handle this > correctly. > > > and others (like us, it seems) are mostly concerned in getting SOMETHING > > working by kludging around existing crap out there. > > Yup. Have been working on IPsec since 1996 now, and am still struggling to > get a wide spread cert-based deployment going. At this point, believe it > or not, the IKE fragmentation issue is probably a bigger headache than > getting the PKI infrastructure up, and even deploying smartcards and > directories. > From owner-ietf-ipsra@mail.vpnc.org Wed Oct 31 19:17:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05950 for ; Wed, 31 Oct 2001 19:17:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f9VNaXo17934 for ietf-ipsra-bks; Wed, 31 Oct 2001 15:36:33 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.11.6/8.11.3) with SMTP id f9VNaV817929 for ; Wed, 31 Oct 2001 15:36:31 -0800 (PST) Received: (qmail 17946 invoked by uid 0); 31 Oct 2001 23:36:25 -0000 Received: from bzq-139-253.pop.bezeqint.net (HELO oemcomputer) (212.179.139.253) by mail.gmx.net (mp020-rz3) with SMTP; 31 Oct 2001 23:36:25 -0000 From: "Yaron Sheffer" To: "Markus Stenberg" , Subject: RE: Moving PIC forwards Date: Thu, 1 Nov 2001 01:35:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <87itcv4tp5.fsf@porsas.hel.fi.ssh.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Actually, "kludging around existing crap" is very much in line with what we've been doing. After all, the whole point of IPSRA is to use *legacy* authentication methods... More to the point, a bare-bones PIC exchange is 2 RTT. For example, if you're only doing a simple challenge-response. Adding the DOS prevention round bring us to 3 RTT. While a TCP implementation adds 2 RTT for connection setup, bringing the number to 4 - TCP takes care of ensuring the originating address can be routed to, and you don't need a dedicated mechanism. An advantage of TCP is the well defined retry mechanism, compared with the fuzzy definition in ISAKMP (Sec. 5.1 of the RFC has some minimal details. The rest is left to your imagination.) A disadvantage is the complexity of dealing with TCP disconnects. But in our case we can simply drop the whole exchange. DOS-resistance is more of an issue. Nobody is going to implement a DOS-resistant TCP package on their hardware VPN, just to accommodate PIC. It all boils down to whether we expect separate PIC and IKE endpoints (in which case IKE/UDP with PIC/TCP make sense) or we expect them to be collocated. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Markus Stenberg Sent: Wednesday, October 31, 2001 7:15 PM To: ietf-ipsra@vpnc.org Subject: Re: Moving PIC forwards aboba@internaut.com (Bernard Aboba) writes: > The fragmentation I've observed is already intentional. If people aren't > up for TCP, then another alternative would be support of a > "continuation" mechanism to spread the cert payload across multiple UDP > packets. What MTU should we use then? 576? Doesn't this triple+ number of packets in normal case and it'd happen only thanks to braindead routers? [ one can argue that 1500-byte packets are de facto, but one can also argue that is using ADSL+PPPoE with low MTU.. ] (Secondary alternative, own PMTU-detection scheme by trial-and-error, I won't even go to.. nor user configuration :P) Is the problem _really_ out there? I personally haven't encountered it much, but my cert chains have been mostly on short side. - If the problem is broken configuration of a firewall (i.e. I know of firewalls that have been configured with insanely low number of fragments to keep / time to keep them), then it can be amended (hopefully) by cluebrick. - If it's matter of product, we should just embrace some form of 'IPsec compatible' term to differentiate between broken and working firewalls. Admittedly, I know firsthand the pain of "we do not want to change " in organizations, but still, I find it interesting that some parties in IETF push for weird (and of course useful) stuff like IPv6 which requires total change of hardware et al, and others (like us, it seems) are mostly concerned in getting SOMETHING working by kludging around existing crap out there. (and to be politically correct, no offense, for the humor impaired that happen to have/work on firewall which is broken) -Markus