From owner-ietf-ipsra@mail.vpnc.org Thu Dec 7 05:32:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24374 for ; Thu, 7 Dec 2000 05:32:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA26991 for ietf-ipsra-bks; Thu, 7 Dec 2000 01:24:01 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26985 for ; Thu, 7 Dec 2000 01:23:58 -0800 (PST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA12202 for ; Thu, 7 Dec 2000 10:25:38 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA06956 for ; Thu, 7 Dec 2000 10:26:06 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 10:26:05 +0100 Message-ID: <1D82815C322BD41196EA00508B951F7B08A197@MCHH265E> From: Bungert Michael To: ietf-ipsra@vpnc.org Subject: AW: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt Date: Thu, 7 Dec 2000 10:25:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA26987 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id BAA26991 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA24374 Two questions on the dhcp draft: On pg. 7 the draft says: If a new IPSEC tunnel is required, the remote host establishes a tunnel mode SA to the security gateway in a quick mode exchange. In this case, the new address assigned via DHCPv4 MUST be used in the quick mode ID. On pg. 10: After processing of the DHCPACK, the intranet interface is configured and the internet interface can establish a new IPSEC tunnel mode SA to the security gateway. The IDci of the quick mode exchange used to establish the new IPSEC tunnel mode SA should be the address of the intranet interface as obtained via DHCPv4. Questions: Is it a MUST or a should and why is it a MUST/a should ? Michael > -----Urspr> üngliche Nachricht----- > Von: Paul Hoffman / VPNC [SMTP:paul.hoffman@vpnc.org] > Gesendet am: Mittwoch, 29. November 2000 18:02 > An: ietf-ipsra@vpnc.org > Betreff: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt > > This is the beginning of a three-week WG last call on > draft-ietf-ipsec-dhcp-08.txt. You can find a copy at > . > > This draft will be discussed in San Diego, but it would be really > grand if everyone can look at it sooner and comment on the mailing > list. Doing so will make the discussion in San Diego more focused, > and allows the authors to respond to requests for changes both on the > list and in the face-to-face meeting. > > And, for those of you who are sticklers on procedure, this draft is > not officially part of the IPSRA WG work, but it has been > unofficially moved to us because of its content. This is a minor > status issue and will not affect our discussion nor its eventual > standardization status. > > --Paul Hoffman, Director > --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Thu Dec 7 20:26:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23655 for ; Thu, 7 Dec 2000 20:26:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA06397 for ietf-ipsra-bks; Thu, 7 Dec 2000 16:34:36 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA06366; Thu, 7 Dec 2000 16:34:22 -0800 (PST) Received: from cyphers.net ([161.69.248.229]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id G5870B00.356; Thu, 7 Dec 2000 17:33:47 -0800 Message-ID: <3A302D14.EEA97DF@cyphers.net> Date: Thu, 07 Dec 2000 16:36:33 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.75 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-xauth@vpnc.org, ietf-ipsra@vpnc.org Subject: Call for implementation list XAuth 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 This is a repeat of my prior message to collect data on all xauth implementations. I have received a number of responses, but I'm certain there are many more. Please send a reply to this message titled "XAUTH DATA" with your response to the questions below. I will collate the information and post it back to the xauth list: Product Name Version Company XAuth Version Send xauth vendor ID (5 or 6?) Understand xauth vendor ID? Minimum XAuth version supported Maximum XAuth version supported Gateway or client Date shipping since or date expected to ship Supports hybrid auth extensions? Thanks! -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ietf-ipsra@mail.vpnc.org Fri Dec 8 03:53:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09385 for ; Fri, 8 Dec 2000 03:53:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA27403 for ietf-ipsra-bks; Thu, 7 Dec 2000 23:58:35 -0800 (PST) Received: from gate.internaut.com (IDENT:root@[64.38.134.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27396 for ; Thu, 7 Dec 2000 23:58:33 -0800 (PST) Received: from e1kj2 ([64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id eB87Y1G03158; Thu, 7 Dec 2000 23:34:01 -0800 From: "Bernard Aboba" To: "Bungert Michael" , Subject: RE: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt Date: Thu, 7 Dec 2000 23:35:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <1D82815C322BD41196EA00508B951F7B08A197@MCHH265E> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id XAA27403 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA09385 I think it is a MUST (thanks for catching the error). The idea was to make sure that there is a binding between the newly assigned address and the QM SA. -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Bungert Michael Sent: Thursday, December 07, 2000 1:26 AM To: ietf-ipsra@vpnc.org Subject: AW: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt Two questions on the dhcp draft: On pg. 7 the draft says: If a new IPSEC tunnel is required, the remote host establishes a tunnel mode SA to the security gateway in a quick mode exchange. In this case, the new address assigned via DHCPv4 MUST be used in the quick mode ID. On pg. 10: After processing of the DHCPACK, the intranet interface is configured and the internet interface can establish a new IPSEC tunnel mode SA to the security gateway. The IDci of the quick mode exchange used to establish the new IPSEC tunnel mode SA should be the address of the intranet interface as obtained via DHCPv4. Questions: Is it a MUST or a should and why is it a MUST/a should ? Michael > -----Urspr> üngliche Nachricht----- > Von: Paul Hoffman / VPNC [SMTP:paul.hoffman@vpnc.org] > Gesendet am: Mittwoch, 29. November 2000 18:02 > An: ietf-ipsra@vpnc.org > Betreff: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt > > This is the beginning of a three-week WG last call on > draft-ietf-ipsec-dhcp-08.txt. You can find a copy at > . > > This draft will be discussed in San Diego, but it would be really > grand if everyone can look at it sooner and comment on the mailing > list. Doing so will make the discussion in San Diego more focused, > and allows the authors to respond to requests for changes both on the > list and in the face-to-face meeting. > > And, for those of you who are sticklers on procedure, this draft is > not officially part of the IPSRA WG work, but it has been > unofficially moved to us because of its content. This is a minor > status issue and will not affect our discussion nor its eventual > standardization status. > > --Paul Hoffman, Director > --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Dec 8 10:25:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27986 for ; Fri, 8 Dec 2000 10:25:59 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA05670 for ietf-ipsra-bks; Fri, 8 Dec 2000 06:06:07 -0800 (PST) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05664 for ; Fri, 8 Dec 2000 06:06:05 -0800 (PST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA11059; Fri, 8 Dec 2000 15:08:14 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA17495; Fri, 8 Dec 2000 15:08:15 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 15:08:14 +0100 Message-ID: <1D82815C322BD41196EA00508B951F7B08A19C@MCHH265E> From: Bungert Michael To: "'Bernard Aboba'" Cc: ietf-ipsra@vpnc.org Subject: AW: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt Date: Fri, 8 Dec 2000 15:08:03 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA05666 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id GAA05670 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA27986 Hi Bernard, thank you for your quick response. I'm not convinced that the QM IDs are the appropriate solution for the binding of newly assigned address and QM SA. It is my understanding that the QM IDs should be used to determine the security requirements for the association based on the security policy and I'm not sure if these assigned addresses are always appropriate for that. Moreover, since the SGW learns the address assigned to the client during the DHCP SA the information is already available. Michael > -----Urspr> üngliche Nachricht----- > Von: Bernard Aboba [SMTP:aboba@internaut.com] > Gesendet am: Freitag, 8. Dezember 2000 08:36 > An: Bungert Michael; ietf-ipsra@vpnc.org > Betreff: RE: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt > > I think it is a MUST (thanks for catching the error). The idea was > to make sure that there is a binding between the newly assigned > address and the QM SA. > > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Bungert Michael > Sent: Thursday, December 07, 2000 1:26 AM > To: ietf-ipsra@vpnc.org > Subject: AW: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt > > > Two questions on the dhcp draft: > On pg. 7 the draft says: If a new IPSEC tunnel is required, the remote host > establishes > a tunnel mode SA to the security gateway in a quick mode exchange. > In this case, the new address assigned via DHCPv4 MUST be used > in the quick mode ID. > On pg. 10: After processing of the DHCPACK, the intranet interface is > configured > and the internet interface can establish a new IPSEC tunnel mode SA to > the security gateway. The IDci of the quick mode exchange used to > establish the new IPSEC tunnel mode SA should be the address of the > intranet interface as obtained via DHCPv4. > > Questions: Is it a MUST or a should and why is it a MUST/a should ? > > Michael > > > > -----Urspr> üngliche Nachricht----- > > Von: Paul Hoffman / VPNC [SMTP:paul.hoffman@vpnc.org] > > Gesendet am: Mittwoch, 29. November 2000 18:02 > > An: ietf-ipsra@vpnc.org > > Betreff: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt > > > > This is the beginning of a three-week WG last call on > > draft-ietf-ipsec-dhcp-08.txt. You can find a copy at > > . > > > > This draft will be discussed in San Diego, but it would be really > > grand if everyone can look at it sooner and comment on the mailing > > list. Doing so will make the discussion in San Diego more focused, > > and allows the authors to respond to requests for changes both on the > > list and in the face-to-face meeting. > > > > And, for those of you who are sticklers on procedure, this draft is > > not officially part of the IPSRA WG work, but it has been > > unofficially moved to us because of its content. This is a minor > > status issue and will not affect our discussion nor its eventual > > standardization status. > > > > --Paul Hoffman, Director > > --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Fri Dec 8 15:42:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18183 for ; Fri, 8 Dec 2000 15:42:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA04015 for ietf-ipsra-bks; Fri, 8 Dec 2000 11:42:57 -0800 (PST) Received: from gate.internaut.com (IDENT:root@[64.38.134.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA04007 for ; Fri, 8 Dec 2000 11:42:54 -0800 (PST) Received: from e1kj2 ([64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id eB8JIRG09822; Fri, 8 Dec 2000 11:18:27 -0800 From: "Bernard Aboba" To: "Bungert Michael" Cc: Subject: RE: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt Date: Fri, 8 Dec 2000 11:20:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <1D82815C322BD41196EA00508B951F7B08A19C@MCHH265E> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Well, the other alternative is to use the Internet address used in the outer header. Are you suggesting that the assigned address SHOULD be used? MAY be used? Anyone else have an argument one way or the other? -----Original Message----- From: Bungert Michael [mailto:Michael.Bungert@icn.siemens.de] Sent: Friday, December 08, 2000 6:08 AM To: 'Bernard Aboba' Cc: ietf-ipsra@vpnc.org Subject: AW: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt Hi Bernard, thank you for your quick response. I'm not convinced that the QM IDs are the appropriate solution for the binding of newly assigned address and QM SA. It is my understanding that the QM IDs should be used to determine the security requirements for the association based on the security policy and I'm not sure if these assigned addresses are always appropriate for that. Moreover, since the SGW learns the address assigned to the client during the DHCP SA the information is already available. Michael From owner-ietf-ipsra@mail.vpnc.org Fri Dec 8 17:26:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15214 for ; Fri, 8 Dec 2000 17:26:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA09654 for ietf-ipsra-bks; Fri, 8 Dec 2000 13:12:35 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA09649 for ; Fri, 8 Dec 2000 13:12:33 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Dec 2000 13:14:21 -0800 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YB6J38N1; Fri, 8 Dec 2000 13:14:13 -0800 From: "Scott G. Kelly" To: Bungert Michael Cc: "'Bernard Aboba'" , ietf-ipsra@vpnc.org Message-ID: <3A315DF6.3460C856@redcreek.com> Date: Fri, 08 Dec 2000 14:17:26 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: AW: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt References: <1D82815C322BD41196EA00508B951F7B08A19C@MCHH265E> 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 Hi Michael, Bungert Michael wrote: > > Hi Bernard, > > thank you for your quick response. I'm not convinced that the QM IDs are the > appropriate solution for the binding of newly assigned address and QM SA. It is > my understanding that the QM IDs should be used to determine the security > requirements for the association based on the security policy and I'm not sure > if these assigned addresses are always appropriate for that. Moreover, since > the SGW learns the address assigned to the client during the DHCP SA the > information is already available. > > Michael While I agree in principle that the qm id could be used to determine the security attributes of the phase 2 sa, in practice it is the phase 1 IDs which are used for this. Typically, current implementations use flow identifiers as the phase 2 IDs. Scott From owner-ietf-ipsra@mail.vpnc.org Sat Dec 9 13:06:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29796 for ; Sat, 9 Dec 2000 13:06:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17698 for ietf-ipsra-bks; Sat, 9 Dec 2000 09:12:19 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17678; Sat, 9 Dec 2000 09:12:17 -0800 (PST) Message-Id: <200012091712.JAA17678@ns.secondary.com> From: Mail Sender To: ietf-fyiup-request@imc.org CC: ietf-imapext@imc.org, ietf-imapext-request@imc.org, ietf-info@ietf.org, ietf-ipsra@vpnc.org, ietf-ipsra-request@vpnc.org Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 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: www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-ipsra@mail.vpnc.org Mon Dec 11 17:21:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19782 for ; Mon, 11 Dec 2000 17:21:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA06917 for ietf-ipsra-bks; Mon, 11 Dec 2000 13:32:58 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06913 for ; Mon, 11 Dec 2000 13:32:55 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 13:35:02 -0800 Received: from redcreek.com (SKELLYLAPTOP [209.125.38.85]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YB6JPAJD; Mon, 11 Dec 2000 13:34:51 -0800 From: "Scott G. Kelly" To: Michael.Bungert@icn.siemens.de Cc: ietf-ipsra@vpnc.org, Bernard Aboba Message-ID: <3A3548F8.16530674@redcreek.com> Date: Mon, 11 Dec 2000 13:36:56 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: RE: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt 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 spoke with Michael this morning, and as a result, would like to amend my position. Michael's point is that ipsec offers considerable flexibility in terms of endpoint IDs. Restricting what can be in the QM ID payload to the IP address only (by specifying MUST) is too restrictive. As a practical matter, most vpn devices will put the assigned IP address in the ID payload. However, I don't think that they MUST. Scott From owner-ietf-ipsra@mail.vpnc.org Mon Dec 11 18:54:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07131 for ; Mon, 11 Dec 2000 18:54:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08695 for ietf-ipsra-bks; Mon, 11 Dec 2000 14:57:34 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@relay.hq.tis.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08691 for ; Mon, 11 Dec 2000 14:57:33 -0800 (PST) Received: by sentry.gw.tislabs.com; id SAA25965; Mon, 11 Dec 2000 18:03:02 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma025959; Mon, 11 Dec 00 18:02:56 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id RAA29296 for ietf-ipsra@vpnc.org; Mon, 11 Dec 2000 17:59:14 -0500 (EST) Date: Mon, 11 Dec 2000 17:59:14 -0500 (EST) From: "David M. Balenson" Message-Id: <200012112259.RAA29296@clipper.gw.tislabs.com> To: ietf-ipsra@vpnc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-ipsra@mail.vpnc.org Tue Dec 12 04:05:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24140 for ; Tue, 12 Dec 2000 04:05:41 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA03320 for ietf-ipsra-bks; Tue, 12 Dec 2000 00:12:45 -0800 (PST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03314 for ; Tue, 12 Dec 2000 00:12:40 -0800 (PST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id AAA19891; Tue, 12 Dec 2000 00:15:14 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA01229; Tue, 12 Dec 00 00:37:17 -0800 Date: Tue, 12 Dec 2000 00:37:16 -0800 (GMT-0800) From: "Bernard D. Aboba" To: "Scott G. Kelly" Cc: Michael.Bungert@icn.siemens.de, ietf-ipsra@vpnc.org Subject: RE: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt In-Reply-To: <3A3548F8.16530674@redcreek.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: OK. So do you think it is a SHOULD? a MAY? On Mon, 11 Dec 2000, Scott G. Kelly wrote: > I spoke with Michael this morning, and as a result, would like to amend > my position. Michael's point is that ipsec offers considerable > flexibility in terms of endpoint IDs. Restricting what can be in the QM > ID payload to the IP address only (by specifying MUST) is too > restrictive. > > As a practical matter, most vpn devices will put the assigned IP address > in the ID payload. However, I don't think that they MUST. > > Scott > From owner-ietf-ipsra@mail.vpnc.org Tue Dec 12 14:56:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01935 for ; Tue, 12 Dec 2000 14:56:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06848 for ietf-ipsra-bks; Tue, 12 Dec 2000 10:49:37 -0800 (PST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06837; Tue, 12 Dec 2000 10:49:36 -0800 (PST) Date: Tue, 12 Dec 2000 10:49:36 -0800 (PST) Message-Id: <200012121849.KAA06837@ns.secondary.com> To: byfraser@cisco.com, to@ns.secondary.com, ietf-ipsra@ns.secondary.com From: Majordomo@imc.org Subject: Confirmation for subscribe ietf-ipsra Reply-To: Majordomo@imc.org Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "ietf-ipsra@imc.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@imc.org": auth e18fd087 subscribe ietf-ipsra \ byfraser@cisco.com to ietf-ipsra (Yes, this is on two lines with a \ character at the end of the first line. That's the best way to get majordomo to do the right thing for authorization.) If you do not want to this action taken, just ignore this message and no action will be taken. If you have any questions about the policy of the list owner, please contact "ietf-ipsra-approval@imc.org". Thanks! Majordomo@imc.org From owner-ietf-ipsra@mail.vpnc.org Wed Dec 13 10:45:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05026 for ; Wed, 13 Dec 2000 10:45:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA21173 for ietf-ipsra-bks; Wed, 13 Dec 2000 06:41:32 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA21169 for ; Wed, 13 Dec 2000 06:41:30 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.vpnc.org [208.184.76.50]) with SMTP; 13 Dec 2000 14:43:44 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA24715 for ; Wed, 13 Dec 2000 09:44:10 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Dec 2000 09:44:09 -0500 Message-ID: From: "Linn, John" To: ietf-ipsra@vpnc.org Subject: SecurID(r) tokens and multi-step authentication exchanges Date: Wed, 13 Dec 2000 09:43:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As an input to the ongoing comparison between PIC and getcert, I'd like to point out an aspect which may not be widely recognized. RSA Security's SecurID tokens have certain operational cases (e.g., token resynchronization, PIN changes) where a user is prompted for and must provide a series of inputs in order to complete a single authentication transaction. In order to fully support these tokens, therefore, it's necessary to be able to carry multi-step transactions, even though these cases arise only on infrequent occasions in ordinary use. Informational RFC-2808 provides more explanation and examples, in the context of SASL integration for the tokens. --jl From owner-ietf-ipsra@mail.vpnc.org Wed Dec 13 14:50:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10546 for ; Wed, 13 Dec 2000 14:50:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA12306 for ietf-ipsra-bks; Wed, 13 Dec 2000 10:53:47 -0800 (PST) Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12302 for ; Wed, 13 Dec 2000 10:53:45 -0800 (PST) Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id UAA02148; Wed, 13 Dec 2000 20:56:26 +0200 (EET) Received: (from kivinen@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id UAA27820; Wed, 13 Dec 2000 20:56:20 +0200 (EET) Date: Wed, 13 Dec 2000 20:56:20 +0200 (EET) Message-Id: <200012131856.UAA27820@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Linn, John" Cc: ietf-ipsra@vpnc.org Subject: SecurID(r) tokens and multi-step authentication exchanges In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 18 min X-Total-Time: 41 min Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Linn, John writes: > As an input to the ongoing comparison between PIC and getcert, I'd like to > point out an aspect which may not be widely recognized. RSA Security's > SecurID tokens have certain operational cases (e.g., token > resynchronization, PIN changes) where a user is prompted for and must > provide a series of inputs in order to complete a single authentication > transaction. In order to fully support these tokens, therefore, it's > necessary to be able to carry multi-step transactions, even though these > cases arise only on infrequent occasions in ordinary use. Informational > RFC-2808 provides more explanation and examples, in the context of SASL > integration for the tokens. If we allow html-forms authentication in the getcert, then it is easy to do. In that case we have session that looks like this: First html page: http://www.foo.bar.ex/cgi-bin/getcert ---------------------------------------------------------------------- ...... You are about to log in the foo.bar company's VPN, unauthorized use forbidden ... Username: [ ] SecurID code: [ ] ---------------------------------------------------------------------- The html code would be: ---------------------------------------------------------------------- ...
Username:
SecurID code:
... ---------------------------------------------------------------------- Now when the user fills this in (or the program which knows that this host is using username/securidcode will directly go to page http://www.foo.bar.ex/cgi-bin/getcert?username=kivinen&securidcode=123456 they will get back next page saying: ---------------------------------------------------------------------- Your ping code is out of sync, give another. Username: kivinen SecurID code: [ ] ---------------------------------------------------------------------- Again the html code is something that is similar, except now the securidcode name is propably different. If the program received this page it would search for the input fields and seeing that the name is "nextpin" instead of securidcode, it knows it needs to ask next pin instead. Parsing the html file is quite easy when you just need to find out the form field names is quite easy, because you don't really need to completely parse the file, you can just do quick "partial" parse through the file and find out the name attributes in the input tags. For example the following perl code will do it: ---------------------------------------------------------------------- #!/usr/local/bin/perl -w undef $/; # Split the page to text,,text,,text,...,,text list @page = split(/(<[^>]*>)/, <>); $len = $#page; # Loop through all tags, odd numbers in the array are tags, even are # the text itself. for($i = 1; $i <= $len; $i += 2) { # remove < from the beginning and > at the end $item = $page[$i]; $item =~ s/^$//g; # Find the input tag and name attribute from it if ($item =~ /input.*\s+name=(?:\"([^\"]*)\"|\'([^\']*)\'|(\S+))/i) { $name = $1 if (defined($1)); $name = $2 if (defined($2)); $name = $3 if (defined($3)); print("name = $name\n"); } } -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ipsra@mail.vpnc.org Thu Dec 14 12:11:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02479 for ; Thu, 14 Dec 2000 12:11:34 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA26972 for ietf-ipsra-bks; Thu, 14 Dec 2000 08:02:03 -0800 (PST) Received: from proxy.radguard.com (red-guard.co.il [192.114.145.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA26951 for ; Thu, 14 Dec 2000 08:01:59 -0800 (PST) Received: from hellman.radguard.com (hellman.radguard.com [192.114.33.100]) by proxy.radguard.com (8.9.3/8.8.7) with ESMTP id SAA17607; Thu, 14 Dec 2000 18:04:42 +0200 Received: from yaron by hellman.radguard.com (8.8.8+Sun/SMI-SVR4) id SAA15221; Thu, 14 Dec 2000 18:02:03 +0200 (IST) From: "Yaron Sheffer" To: "Tero Kivinen" , "Linn, John" Cc: Subject: RE: SecurID(r) tokens and multi-step authentication exchanges Date: Thu, 14 Dec 2000 08:04:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200012131856.UAA27820@torni.hel.fi.ssh.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Tero, in my opinion your proposal reduces the security of getcert, in that it now relies on ASP scripts, not just TLS and HTTP authentication. I think from a security point of view, it is better to support the majority of authentication methods and "most" of SecureID functionality, than to introduce such a major hole. Just to clarify: EAP, the authentication method underlying PIC, does support multiple rounds, and thus could be used for the SecureID Next PIN mode, etc. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Tero Kivinen Sent: Wednesday, December 13, 2000 8:56 PM To: Linn, John Cc: ietf-ipsra@vpnc.org Subject: SecurID(r) tokens and multi-step authentication exchanges Linn, John writes: > As an input to the ongoing comparison between PIC and getcert, I'd like to > point out an aspect which may not be widely recognized. RSA Security's > SecurID tokens have certain operational cases (e.g., token > resynchronization, PIN changes) where a user is prompted for and must > provide a series of inputs in order to complete a single authentication > transaction. In order to fully support these tokens, therefore, it's > necessary to be able to carry multi-step transactions, even though these > cases arise only on infrequent occasions in ordinary use. Informational > RFC-2808 provides more explanation and examples, in the context of SASL > integration for the tokens. If we allow html-forms authentication in the getcert, then it is easy to do. In that case we have session that looks like this: First html page: http://www.foo.bar.ex/cgi-bin/getcert ---------------------------------------------------------------------- ...... You are about to log in the foo.bar company's VPN, unauthorized use forbidden ... Username: [ ] SecurID code: [ ] ---------------------------------------------------------------------- The html code would be: ---------------------------------------------------------------------- ...
Username:
SecurID code:
... ---------------------------------------------------------------------- Now when the user fills this in (or the program which knows that this host is using username/securidcode will directly go to page http://www.foo.bar.ex/cgi-bin/getcert?username=kivinen&securidcode=123456 they will get back next page saying: ---------------------------------------------------------------------- Your ping code is out of sync, give another. Username: kivinen SecurID code: [ ] ---------------------------------------------------------------------- Again the html code is something that is similar, except now the securidcode name is propably different. If the program received this page it would search for the input fields and seeing that the name is "nextpin" instead of securidcode, it knows it needs to ask next pin instead. Parsing the html file is quite easy when you just need to find out the form field names is quite easy, because you don't really need to completely parse the file, you can just do quick "partial" parse through the file and find out the name attributes in the input tags. For example the following perl code will do it: ---------------------------------------------------------------------- #!/usr/local/bin/perl -w undef $/; # Split the page to text,,text,,text,...,,text list @page = split(/(<[^>]*>)/, <>); $len = $#page; # Loop through all tags, odd numbers in the array are tags, even are # the text itself. for($i = 1; $i <= $len; $i += 2) { # remove < from the beginning and > at the end $item = $page[$i]; $item =~ s/^$//g; # Find the input tag and name attribute from it if ($item =~ /input.*\s+name=(?:\"([^\"]*)\"|\'([^\']*)\'|(\S+))/i) { $name = $1 if (defined($1)); $name = $2 if (defined($2)); $name = $3 if (defined($3)); print("name = $name\n"); } } -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ipsra@mail.vpnc.org Thu Dec 14 13:27:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11676 for ; Thu, 14 Dec 2000 13:27:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01964 for ietf-ipsra-bks; Thu, 14 Dec 2000 09:21:17 -0800 (PST) Received: from itesec.hsc.fr (itesec.hsc.fr [192.70.106.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01960 for ; Thu, 14 Dec 2000 09:21:16 -0800 (PST) Received: from gandalf (itesec.hsc.fr [192.70.106.33]) by itesec.hsc.fr (Postfix) with SMTP id BB2EA10F07 for ; Thu, 14 Dec 2000 18:23:31 +0100 (CET) From: Ghislaine Labouret To: Subject: Re: SecurID(r) tokens and multi-step authentication exchanges Date: Thu, 14 Dec 2000 09:23:53 -0800 Organization: HSC (Herve Schauer Consultants) References: <200012131856.UAA27820@torni.hel.fi.ssh.com> In-Reply-To: X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Message-Id: <20001214172331.BB2EA10F07@itesec.hsc.fr> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id JAA01964 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA11676 On Thu, 14 Dec 2000 08:04:03 +0200, Yaron Sheffer wrote: > in my opinion your proposal reduces the security of getcert, in that it now > relies on ASP scripts, not just TLS and HTTP authentication. Who said it had to be done with ASP scripts? The server can implement SecurID authentication in various ways (more or less secure, depending on the programmer's skills). For example, there is an implementation of SecurID auth using HTTP/HTML, as an Apache module : http://persoweb.francenet.fr/~pasty/mod_securid/ > -----Original Message----- > From: owner-ietf-ipsra@mail.vpnc.org > [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Tero Kivinen [...] > If we allow html-forms authentication in the getcert, then it is easy > to do. The current GETCERT spec is, apparently deliberately, not very specific about how the various legacy authentication schemes can be accommodated. The "Authentication Techniques" paragraph (reproduced below) insists, in my opinion, too much on classical HTTP authentication and RADIUS: the back-end server could be an LDAP one for example, cookies or CGI parameters could be used to convey the user's auth data, and the process could be composed of more than 2 phases. Without mandating any scheme, couldn't the draft give examples/pointers or recommendations on how various legacy authentication schemes could be implemented? | 5. Authentication Techniques | | Although this document is carefully agnostic about the user | authentication techniques to be used, there are two underlying | assumptions. First, we assume that the authentication is actually | being performed by a back-end RADIUS server, over the TLS HTTP | connection, with its accompanying database. Second, we wish to | support a variety of common authentication techniques, including | ordinary passwords, time-varying tokens, and challenge/response | tokens. All are believed to be accommodated by this framework. | Finally, we rely on this client and server authentication so that the | SCEP assumptions on CA root certificate distribution and subjectName | checking are automated. | | Requests for certificates must be authenticated. Since we prescribe | HTTP, HTTP authentication mechanisms -- under protection of TLS -- | MUST be used. Specifically, the request will generally include an | appropriate Authorization: line, using whatever form of | authentication is locally preferred. If it does not, the server MUST | return a 401 error line, per [RFC2616] and [RFC2617]; the client MUST | then resubmit the request with the appropriate Authentication: line. | (This two-phase process is permitted in order to support | challenge/response forms of authentication.) -- Ghislaine Labouret, Network security consultant Hervé Schauer Consultants (HSC) - http://www.hsc.fr/ Phone (+33)-141-409-700 - Fax (+33)-141-409-709 From owner-ietf-ipsra@mail.vpnc.org Thu Dec 14 14:27:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23341 for ; Thu, 14 Dec 2000 14:27:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02448 for ietf-ipsra-bks; Thu, 14 Dec 2000 09:46:47 -0800 (PST) Received: from ssh.com (fw.hel.fi.ssh.com [193.64.193.124]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02439 for ; Thu, 14 Dec 2000 09:46:45 -0800 (PST) Received: from torni.hel.fi.ssh.com (torni.hel.fi.ssh.com [10.1.0.43]) by ssh.com (8.9.3/8.9.3/SSH-1.16) with ESMTP id TAA13302; Thu, 14 Dec 2000 19:49:27 +0200 (EET) Received: (from kivinen@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.17) id TAA13974; Thu, 14 Dec 2000 19:49:27 +0200 (EET) Date: Thu, 14 Dec 2000 19:49:27 +0200 (EET) Message-Id: <200012141749.TAA13974@torni.hel.fi.ssh.com> X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: "Yaron Sheffer" Cc: "Linn, John" , Subject: RE: SecurID(r) tokens and multi-step authentication exchanges In-Reply-To: References: <200012131856.UAA27820@torni.hel.fi.ssh.com> X-Mailer: VM 6.34 under Emacs 20.7.2 Organization: SSH Communications Security Oy X-Edit-Time: 10 min X-Total-Time: 9 min Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yaron Sheffer writes: > in my opinion your proposal reduces the security of getcert, in that it now > relies on ASP scripts, not just TLS and HTTP authentication. I think from a ASP scripts? I didn't mention anything about APS scripts. I was talking about the server sending web page and processing normal form with normal methods available for it. I myself definately would not use ASP for this kind of system. Anyways, I propably wouldn't trust normal web-server either for this kind of service, but I would use minimal web-server instead. > security point of view, it is better to support the majority of > authentication methods and "most" of SecureID functionality, than to > introduce such a major hole. If sending forms to the web-server is a security hole, then I think you should use some other web-server. I is used by all web banking systems I have seen, it is used by almost all other web system that requires authentication too. Nobody is using http-authentication anymore. I don't even remember when I last time saw real http-authentication request anywhere. > Just to clarify: EAP, the authentication method underlying PIC, does support > multiple rounds, and thus could be used for the SecureID Next PIN mode, etc. But it needs much bigger piece of code than is needed to be made secure than that small piece of code that is required to parse and verify the password sent in the html-form. If you do not trust that people can write secure ~50 line program parsing and checking the html-form, how can you trust they can write ~5000 line program to run PIC? -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ipsra@mail.vpnc.org Thu Dec 14 14:37:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25515 for ; Thu, 14 Dec 2000 14:37:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05635 for ietf-ipsra-bks; Thu, 14 Dec 2000 10:14:29 -0800 (PST) Received: from dfmail.f-secure.com (dfmail.f-secure.com [194.252.6.39]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA05628 for ; Thu, 14 Dec 2000 10:14:27 -0800 (PST) Received: (qmail 15291 invoked by uid 0); 14 Dec 2000 18:17:11 -0000 Received: from fsinterface.f-secure.com (HELO fsfwfi01) (194.252.6.33) by dfmail.f-secure.com with SMTP; 14 Dec 2000 18:17:11 -0000 Received: (qmail 13690 invoked from network); 14 Dec 2000 18:14:18 -0000 Received: from info.f-secure.com (HELO F-Secure.com) (194.197.29.11) by dfintra.f-secure.com with SMTP; 14 Dec 2000 18:14:18 -0000 Message-ID: <3A390E2E.ACF98FEC@F-Secure.com> Date: Thu, 14 Dec 2000 20:15:10 +0200 From: Ari Huttunen Organization: F-Secure Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipsra Subject: Question about N-factor auth? 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 Scott mentioned in the meeting that requirements for N-factor authentication were added to the requirements document. Does this include a case where the machine is identified with a machine certificate, and the user is identified with, let's say, a Secur-ID card? I do not wish to discuss whether an unnamed, out-of-scope out-of-scope out-of-scope thing, accomplishes this, but rather whether doing such a thing is actually a requirement for this WG. My view is that it's relevant, to account for the worry voiced by the Microsoft guys about using an untrusted terminal to access company secrets. (The client certificate could also be an SSL certificate.) Ari -- Ari Huttunen phone: +358 9 2520 0700 Senior Software Engineer fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-ipsra@mail.vpnc.org Thu Dec 14 14:42:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26633 for ; Thu, 14 Dec 2000 14:42:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA06618 for ietf-ipsra-bks; Thu, 14 Dec 2000 10:28:29 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA06610 for ; Thu, 14 Dec 2000 10:28:27 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 10:30:45 -0800 Received: from redcreek.com (SKELLYLAPTOP [209.125.38.97]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id YB6JP2F4; Thu, 14 Dec 2000 10:30:39 -0800 From: "Scott G. Kelly" To: Ari Huttunen Cc: ipsra Message-ID: <3A39124E.B5D0CD14@redcreek.com> Date: Thu, 14 Dec 2000 10:32:46 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Question about N-factor auth? References: <3A390E2E.ACF98FEC@F-Secure.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 Hi Ari, We discussed this in Pittsburgh, and the general consensus there was that n-factor authentication should be supported by whatever mechanism we choose. It appears that both getcert and pic can support n-factor authentication, although it is not yet clear how a machine cert would be folded into the authentication process. However, one could envision a challenge to the client which was signed by the private key and returned in response, possibly along with the associated cert. Scott Ari Huttunen wrote: > > Scott mentioned in the meeting that requirements for N-factor authentication > were added to the requirements document. > > Does this include a case where the machine is identified with a machine certificate, > and the user is identified with, let's say, a Secur-ID card? > > I do not wish to discuss whether an unnamed, out-of-scope out-of-scope out-of-scope thing, > accomplishes this, but rather whether doing such a thing is actually a requirement for this WG. > My view is that it's relevant, to account for the worry voiced by the Microsoft guys about > using an untrusted terminal to access company secrets. (The client certificate could also > be an SSL certificate.) > > Ari > > -- > Ari Huttunen phone: +358 9 2520 0700 > Senior Software Engineer fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F-Secure products: Integrated Solutions for Enterprise Security From owner-ietf-ipsra@mail.vpnc.org Thu Dec 14 16:55:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27967 for ; Thu, 14 Dec 2000 16:55:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA15293 for ietf-ipsra-bks; Thu, 14 Dec 2000 13:01:17 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA15289 for ; Thu, 14 Dec 2000 13:01:16 -0800 (PST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 1BC0B4CE54; Thu, 14 Dec 2000 16:04:03 -0500 (EST) Received: from smb.research.att.com (secure.research.att.com [135.207.24.10]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id QAA05018; Thu, 14 Dec 2000 16:03:58 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id D5DA735DC2; Thu, 14 Dec 2000 13:00:39 -0800 (PST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "Scott G. Kelly" Cc: Ari Huttunen , ipsra Subject: Re: Question about N-factor auth? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Dec 2000 13:00:29 -0800 Message-Id: <20001214210040.D5DA735DC2@smb.research.att.com> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In message <3A39124E.B5D0CD14@redcreek.com>, "Scott G. Kelly" writes: >Hi Ari, > >We discussed this in Pittsburgh, and the general consensus there was >that n-factor authentication should be supported by whatever mechanism >we choose. It appears that both getcert and pic can support n-factor >authentication, although it is not yet clear how a machine cert would be >folded into the authentication process. However, one could envision a >challenge to the client which was signed by the private key and returned >in response, possibly along with the associated cert. > Or, as Ari noted, a machine-specific certificate could be used to authenticate the TLS session used in getcert. --Steve Bellovin From owner-ietf-ipsra@mail.vpnc.org Thu Dec 14 22:28:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA29533 for ; Thu, 14 Dec 2000 22:28:34 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id SAA24560 for ietf-ipsra-bks; Thu, 14 Dec 2000 18:50:36 -0800 (PST) Received: from proxy.radguard.com (red-guard.co.il [192.114.145.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24555 for ; Thu, 14 Dec 2000 18:50:34 -0800 (PST) Received: from hellman.radguard.com (hellman.radguard.com [192.114.33.100]) by proxy.radguard.com (8.9.3/8.8.7) with ESMTP id EAA22898; Fri, 15 Dec 2000 04:52:33 +0200 Received: from yaron by hellman.radguard.com (8.8.8+Sun/SMI-SVR4) id EAA14514; Fri, 15 Dec 2000 04:49:55 +0200 (IST) From: "Yaron Sheffer" To: "Tero Kivinen" Cc: "Linn, John" , Subject: RE: SecurID(r) tokens and multi-step authentication exchanges Date: Thu, 14 Dec 2000 18:51:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200012141749.TAA13974@torni.hel.fi.ssh.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Tero, I'm not sure I want to be drawn into a theological discussion, but anyway. For a security protocol, you want to use: 1. Standard building blocks. 2. Building blocks that are (or have been) implemented with security in mind. (1) would point you towards SASL or EAP, rather than HTTP plus CGI scripting. (2) implies you want to reduce your reliance on "general" standards that may have hidden security problems, either in protocol or implementation. You can reasonably expect that a typical *implementation* of IKE is more secure than a typical implementation of HTTP. There is no reason why EAP should be more complex than any XAuth implementation. They are semantically equivalent. Both are probably worth much less than 5,000 lines of code. Thanks, Yaron -----Original Message----- From: Tero Kivinen [mailto:kivinen@ssh.fi] Sent: Thursday, December 14, 2000 7:49 PM To: Yaron Sheffer Cc: Linn, John; ietf-ipsra@vpnc.org Subject: RE: SecurID(r) tokens and multi-step authentication exchanges Yaron Sheffer writes: > in my opinion your proposal reduces the security of getcert, in that it now > relies on ASP scripts, not just TLS and HTTP authentication. I think from a ASP scripts? I didn't mention anything about APS scripts. I was talking about the server sending web page and processing normal form with normal methods available for it. I myself definately would not use ASP for this kind of system. Anyways, I propably wouldn't trust normal web-server either for this kind of service, but I would use minimal web-server instead. > security point of view, it is better to support the majority of > authentication methods and "most" of SecureID functionality, than to > introduce such a major hole. If sending forms to the web-server is a security hole, then I think you should use some other web-server. I is used by all web banking systems I have seen, it is used by almost all other web system that requires authentication too. Nobody is using http-authentication anymore. I don't even remember when I last time saw real http-authentication request anywhere. > Just to clarify: EAP, the authentication method underlying PIC, does support > multiple rounds, and thus could be used for the SecureID Next PIN mode, etc. But it needs much bigger piece of code than is needed to be made secure than that small piece of code that is required to parse and verify the password sent in the html-form. If you do not trust that people can write secure ~50 line program parsing and checking the html-form, how can you trust they can write ~5000 line program to run PIC? -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ietf-ipsra@mail.vpnc.org Mon Dec 18 13:45:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12917 for ; Mon, 18 Dec 2000 13:45:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12720 for ietf-ipsra-bks; Mon, 18 Dec 2000 08:45:30 -0800 (PST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12715 for ; Mon, 18 Dec 2000 08:45:28 -0800 (PST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.9.3+Sun/8.9.3) with ESMTP id SAA26966; Mon, 18 Dec 2000 18:47:48 +0200 (IST) Date: Mon, 18 Dec 2000 18:47:47 +0200 (IST) From: Hugo Krawczyk To: "Scott G. Kelly" cc: ipsra Subject: Re: Question about N-factor auth? In-Reply-To: <3A39124E.B5D0CD14@redcreek.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: On Thu, 14 Dec 2000, Scott G. Kelly wrote: > Hi Ari, > > We discussed this in Pittsburgh, and the general consensus there was > that n-factor authentication should be supported by whatever mechanism > we choose. It appears that both getcert and pic can support n-factor > authentication, although it is not yet clear how a machine cert would be > folded into the authentication process. However, one could envision a > challenge to the client which was signed by the private key and returned > in response, possibly along with the associated cert. Adding machine authentication to PIC is straightforward: instead of a one-way authenticated "signature mode" as currently described for PIC (where only the server signs the exchange) you do a complete signature mode where the client side performs a signature based on the machine private key as part of the third PIC message. Whether support for machine certificates is needed is a diffeent question... Hugo > Scott > > Ari Huttunen wrote: > > > > Scott mentioned in the meeting that requirements for N-factor authentication > > were added to the requirements document. > > > > Does this include a case where the machine is identified with a machine certificate, > > and the user is identified with, let's say, a Secur-ID card? > > > > I do not wish to discuss whether an unnamed, out-of-scope out-of-scope out-of-scope thing, > > accomplishes this, but rather whether doing such a thing is actually a requirement for this WG. > > My view is that it's relevant, to account for the worry voiced by the Microsoft guys about > > using an untrusted terminal to access company secrets. (The client certificate could also > > be an SSL certificate.) > > > > Ari > > > > -- > > Ari Huttunen phone: +358 9 2520 0700 > > Senior Software Engineer fax : +358 9 2520 5001 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F-Secure products: Integrated Solutions for Enterprise Security > From owner-ietf-ipsra@mail.vpnc.org Mon Dec 18 17:41:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16882 for ; Mon, 18 Dec 2000 17:41:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA29337 for ietf-ipsra-bks; Mon, 18 Dec 2000 13:39:08 -0800 (PST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA29330 for ; Mon, 18 Dec 2000 13:39:06 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 18 Dec 2000 13:41:58 -0800 To: ietf-ipsra@vpnc.org From: Paul Hoffman / VPNC Subject: Preliminary minutes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Comments from those of you at the meeting about the minutes are appreciated. *Preliminary* Minutes IPSRA WG, San Diego, December 12, 2000 The agenda was approved without changes. ** IPSRA Requirements document draft-ietf-ipsra-reqmts-02.txt was posted to the mailing list after draft cutoff date. There was a quesition from the floor: why were byte counts removed as requirements? Answer: discussion from Pittburgh and the list. This led to a discussion of problems of definitons of the WG work. People who want to emphasize remote access (as compared to emphasizing security) feel that they are not being heard. Some people feel that Remote Access is how most people connect to the Internet (usually dial-in through untrusted ISP), not a connection with a fixed IP address; others disagreed. Decision: look again at the charter. ** GetCert document draft-ietf-ipsra-getcert-00.txt was presented. A comment from the floor was that SCEP was broken and should not be used; the response was that GetCert uses only a part of SCEP that isn't broken. It was pointed out that GetCert only handles half-trip or one round trip authentication, although it is not clear whether this is much of a problem in most cases. The CA must make security policy for SSL connection. The client must start with the appropriate root certificate; this may assume a public SSL root similar to the ecommerce model. ** PIC document draft-ietf-ipsra-pic-01.txt has many changes from -00. It now uses EAP (RFC 2284) instead of XAuth, it uses a new ISAKMP exchange type, and it eliminates one round trip. A comment from the floor indicated that PIC will be open to the same attacks as agressive-mode IKE. ** IKE DHCP document draft-ietf-ipsec-dhcp-08.txt is in Working Group last call. There was a discussion of MUST/SHOULD/MAY for the quick mode ID payload which needs to be resolved on the list. There was also a suggestion to add something from the user's certificate for the DHCP user ID. Steps forward: --wrap up DHCP in next two weeks, send to the IESG --choose between GetCert and PIC sometime in January Slides are available on the WG site at . --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Mon Dec 18 23:01:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23058 for ; Mon, 18 Dec 2000 23:01:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07540 for ietf-ipsra-bks; Mon, 18 Dec 2000 19:09:05 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07536 for ; Mon, 18 Dec 2000 19:09:04 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 19:11:43 -0800 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y97PM1HT; Mon, 18 Dec 2000 19:11:40 -0800 From: "Scott G. Kelly" To: Hugo Krawczyk Cc: ipsra Message-ID: <3A3EE0BB.BC0C5EE5@redcreek.com> Date: Mon, 18 Dec 2000 20:14:51 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: Question about N-factor auth? 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 Hi Hugo, Hugo Krawczyk wrote: > > On Thu, 14 Dec 2000, Scott G. Kelly wrote: > > > Hi Ari, > > > > We discussed this in Pittsburgh, and the general consensus there was > > that n-factor authentication should be supported by whatever mechanism > > we choose. It appears that both getcert and pic can support n-factor > > authentication, although it is not yet clear how a machine cert would be > > folded into the authentication process. However, one could envision a > > challenge to the client which was signed by the private key and returned > > in response, possibly along with the associated cert. > > Adding machine authentication to PIC is straightforward: instead of a > one-way authenticated "signature mode" as currently described for PIC > (where only the server signs the exchange) you do a complete signature > mode where the client side performs a signature based on the machine > private key as part of the third PIC message. Yes, this was obvious to me after Steve's post. > Whether support for machine certificates is needed is a diffeent > question... I think this requirement has been clearly indicated. There are cases where access may be permitted only from specific systems, and in these cases, the system must be reliably identified, in addition to the user. Scott From owner-ietf-ipsra@mail.vpnc.org Wed Dec 20 12:40:19 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06001 for ; Wed, 20 Dec 2000 12:40:18 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA11277 for ietf-ipsra-bks; Wed, 20 Dec 2000 08:25:50 -0800 (PST) Received: from proxy.radguard.com (red-guard.co.il [192.114.145.130] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11263; Wed, 20 Dec 2000 08:25:46 -0800 (PST) Received: from hellman.radguard.com (hellman.radguard.com [192.114.33.100]) by proxy.radguard.com (8.9.3/8.8.7) with ESMTP id SAA16122; Wed, 20 Dec 2000 18:28:19 +0200 Received: from yaron by hellman.radguard.com (8.8.8+Sun/SMI-SVR4) id SAA01553; Wed, 20 Dec 2000 18:27:17 +0200 (IST) From: "Yaron Sheffer" To: "Paul Hoffman / VPNC" , Subject: RE: Preliminary minutes Date: Wed, 20 Dec 2000 18:29:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd like to make a clarification regarding the comment on Aggressive Mode-like attacks on PIC. The two perceived issues with aggressive mode are - DoS attacks - Lack of identity protection of the responder. By requirement, PIC (or getcert) allow anonymous users to initiate a secure connection. Any protocol allowing this is open to DoS attacks. Similarly, there is no requirement for PIC or getcert to protect the identity of the server. Only the identity of user/client is protected. Thanks, Yaron -----Original Message----- From: owner-ietf-ipsra@mail.vpnc.org [mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Paul Hoffman / VPNC Sent: Monday, December 18, 2000 11:42 PM To: ietf-ipsra@vpnc.org Subject: Preliminary minutes Comments from those of you at the meeting about the minutes are appreciated. *Preliminary* Minutes IPSRA WG, San Diego, December 12, 2000 The agenda was approved without changes. ** IPSRA Requirements document draft-ietf-ipsra-reqmts-02.txt was posted to the mailing list after draft cutoff date. There was a quesition from the floor: why were byte counts removed as requirements? Answer: discussion from Pittburgh and the list. This led to a discussion of problems of definitons of the WG work. People who want to emphasize remote access (as compared to emphasizing security) feel that they are not being heard. Some people feel that Remote Access is how most people connect to the Internet (usually dial-in through untrusted ISP), not a connection with a fixed IP address; others disagreed. Decision: look again at the charter. ** GetCert document draft-ietf-ipsra-getcert-00.txt was presented. A comment from the floor was that SCEP was broken and should not be used; the response was that GetCert uses only a part of SCEP that isn't broken. It was pointed out that GetCert only handles half-trip or one round trip authentication, although it is not clear whether this is much of a problem in most cases. The CA must make security policy for SSL connection. The client must start with the appropriate root certificate; this may assume a public SSL root similar to the ecommerce model. ** PIC document draft-ietf-ipsra-pic-01.txt has many changes from -00. It now uses EAP (RFC 2284) instead of XAuth, it uses a new ISAKMP exchange type, and it eliminates one round trip. A comment from the floor indicated that PIC will be open to the same attacks as agressive-mode IKE. ** IKE DHCP document draft-ietf-ipsec-dhcp-08.txt is in Working Group last call. There was a discussion of MUST/SHOULD/MAY for the quick mode ID payload which needs to be resolved on the list. There was also a suggestion to add something from the user's certificate for the DHCP user ID. Steps forward: --wrap up DHCP in next two weeks, send to the IESG --choose between GetCert and PIC sometime in January Slides are available on the WG site at . --Paul Hoffman, Director --VPN Consortium From owner-ietf-ipsra@mail.vpnc.org Thu Dec 21 07:35:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15917 for ; Thu, 21 Dec 2000 07:35:51 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA17618 for ietf-ipsra-bks; Thu, 21 Dec 2000 03:43:33 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA17613 for ; Thu, 21 Dec 2000 03:43:31 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15050; Thu, 21 Dec 2000 06:45:58 -0500 (EST) Message-Id: <200012211145.GAA15050@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ipsra@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsra-reqmts-02.txt Date: Thu, 21 Dec 2000 06:45:58 -0500 Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Remote Access Working Group of the IETF. Title : Requirements for IPsec Remote Access Scenarios Author(s) : S. Kelly, S. Ramamoorthi Filename : draft-ietf-ipsra-reqmts-02.txt Pages : 33 Date : 20-Dec-00 IPsec offers much promise as a secure remote access mechanism. However, there are a significant number of remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsra-reqmts-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsra-reqmts-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsra-reqmts-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001220160732.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsra-reqmts-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsra-reqmts-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001220160732.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ipsra@mail.vpnc.org Thu Dec 21 13:08:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26205 for ; Thu, 21 Dec 2000 13:08:26 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09490 for ietf-ipsra-bks; Thu, 21 Dec 2000 09:15:47 -0800 (PST) Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09486 for ; Thu, 21 Dec 2000 09:15:46 -0800 (PST) Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 09:18:38 -0800 Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id Y97PMJDA; Thu, 21 Dec 2000 09:18:32 -0800 From: "Scott G. Kelly" To: ietf-ipsra@vpnc.org Message-ID: <3A424A31.D62B3732@redcreek.com> Date: Thu, 21 Dec 2000 10:21:37 -0800 Organization: RedCreek Communications X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: I-D ACTION:draft-ietf-ipsra-reqmts-02.txt References: <200012211145.GAA15050@ietf.org> 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 For clarification, this is the verion of the draft we discussed in San Diego, just now popping out of the ID editor's queue. I'm working on the next rev, and hope to have that submitted within 2 weeks. Scott From owner-ietf-ipsra@mail.vpnc.org Thu Dec 21 17:25:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03107 for ; Thu, 21 Dec 2000 17:25:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA25005 for ietf-ipsra-bks; Thu, 21 Dec 2000 13:31:24 -0800 (PST) Received: from mp.a-phys.eng.osaka-cu.ac.jp ([160.193.160.180]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24992 for ; Thu, 21 Dec 2000 13:31:14 -0800 (PST) From: hj4hj6@yahoo.com Received: by mp.a-phys.eng.osaka-cu.ac.jp id AA31402; Fri, 22 Dec 2000 06:24:25 +0900 Date: 21 Dec 00 1:39:28 PM Message-Id: <7T79fg019847isE1p0> Subject: Improve your stepfamily life Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf@mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience.