From owner-ietf-ipsra@mail.vpnc.org Sun Feb 4 04:44:46 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07565 for ; Sun, 4 Feb 2001 04:44:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA15285 for ietf-ipsra-bks; Sun, 4 Feb 2001 00:41:26 -0800 (PST) Received: from hippolyte.radguard.com ([192.117.11.9]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA15270; Sun, 4 Feb 2001 00:41:23 -0800 (PST) Received: from hellman.radguard.com (unverified) by hippolyte.radguard.com (Content Technologies SMTPRS 4.2.1) with SMTP id ; Sun, 4 Feb 2001 10:52:32 +0200 Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4) id KAA02077; Sun, 4 Feb 2001 10:47:29 +0200 (IST) Message-ID: <3A7D16A5.C9F094D9@radguard.com> Date: Sun, 04 Feb 2001 10:45:25 +0200 From: Sara Bitan Organization: RADGUARD X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IPSRA list CC: Paul Hoffman Subject: Starting the decision on PIC vs. GetCert 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 Hello all! We would like to choose one candidate between PIC and GetCert, and to have progress with the chosen one. We will have a short (two weeks) discussion on the list, followed by a straw poll. Here is a general summary that I hope will help us start the discussion. These are the general requirements PIC and GetCert were devised to answer: (From draft-ietf-ipsra-reqmts-03.txt) " In general, proposed IPsec remote access mechanisms should meet the following goals: o should provide direct support for legacy user authentication systems such as RADIUS o should encourage migration from existing low-entropy password-based systems to more secure authentication systems o if legacy support cannot be provided without some sort of migration, the impact of such migration should be minimized o user authentication information must be protected against eavesdropping and replay (including the user identity) o single sign-on capability should be provided in configurations employing load-balancing and/or redundancy o n-factor authentication mechanisms should be supported" Both PIC and GetCert answer the first five requirements. As noted in a recent discussion on the list, PIC can be modified to answer the last requirement. Both provide server side authenticated secure transport for the user authentication data, and for certificate enrollment. GetCert is using SSL/TLS as a secure transport, while PIC is using ISAKMP as a secure transport, created by server authenticated DH. (Hugo in an e-mail to the list, noted that PIC can be extended to create mutually authenticated transport) GetCert uses HTTP as the legacy authentication transport, while PIC is using EAP. GetCert uses SCEP for certificate enrollment, while PIC is using dedicated CREDENTIAL-REQUEST and CREDENTIAL payloads. I urge you all to please read the two drafts, and share your opinion with the list. Please speak soon, so we can get as much discussion as possible before we start the straw poll. Thanks, Sara From owner-ietf-ipsra@mail.vpnc.org Mon Feb 5 10:30:24 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09114 for ; Mon, 5 Feb 2001 10:30:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA08590 for ietf-ipsra-bks; Mon, 5 Feb 2001 06:41:56 -0800 (PST) Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA08583; Mon, 5 Feb 2001 06:41:53 -0800 (PST) Received: from rgm.htt-consult.com ([63.82.18.214]) by htt-consult.com ; Mon, 05 Feb 2001 09:49:06 -0500 Message-Id: <5.0.0.25.2.20010205094447.02a05b40@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 05 Feb 2001 09:48:27 -0500 To: Sara Bitan , IPSRA list From: Robert Moskowitz Subject: Re: Starting the decision on PIC vs. GetCert Cc: Paul Hoffman In-Reply-To: <3A7D16A5.C9F094D9@radguard.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:45 AM 2/4/2001 +0200, Sara Bitan wrote: >Both PIC and GetCert answer the first five requirements. As noted in a recent >discussion on the list, PIC can be modified to answer the last requirement. >Both provide server side authenticated secure transport for the user >authentication data, and for certificate enrollment. >GetCert is using SSL/TLS as a secure transport, while PIC is using ISAKMP as a >secure transport, created by server authenticated DH. >(Hugo in an e-mail to the list, noted that PIC can be extended to create >mutually authenticated transport) >GetCert uses HTTP as the legacy authentication transport, while PIC is using >EAP. >GetCert uses SCEP for certificate enrollment, while PIC is using dedicated >CREDENTIAL-REQUEST and CREDENTIAL payloads. It would be easy for me to change GETCERT to use CMP and CMP Transport over HTTP making it fully compliant with PKIX standards, just not following the Appendix B ir senario. It woudl be harder to do it with CMC. Principle reason is CMC does not call out a transport. If they were to adapt the CMP Transport, I could most likely make that work too. Now due to work requirements I am swamped until Feb 12th. Any rewrites would occur after that. But give it serious consideration. Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ietf-ipsra@mail.vpnc.org Mon Feb 5 12:57:32 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13011 for ; Mon, 5 Feb 2001 12:57:29 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18539 for ietf-ipsra-bks; Mon, 5 Feb 2001 09:09:47 -0800 (PST) Received: from gate.internaut.com ([64.38.134.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18533; Mon, 5 Feb 2001 09:09:46 -0800 (PST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f15HBWR25080; Mon, 5 Feb 2001 09:11:33 -0800 From: "Bernard Aboba" To: "Robert Moskowitz" , "Sara Bitan" , "IPSRA list" Cc: "Paul Hoffman" Subject: RE: Starting the decision on PIC vs. GetCert Date: Mon, 5 Feb 2001 09:17:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <5.0.0.25.2.20010205094447.02a05b40@localhost> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >It would be easy for me to change GETCERT to use CMP and CMP Transport over >HTTP making it fully compliant with PKIX standards, just not following the >Appendix B ir senario. Personally, I think this would be a good idea -- especially if EAP support could be added as well. This would require protection of the EAP conversation. From owner-ietf-ipsra@mail.vpnc.org Mon Feb 5 13:47:10 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14171 for ; Mon, 5 Feb 2001 13:47:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19225 for ietf-ipsra-bks; Mon, 5 Feb 2001 09:29:38 -0800 (PST) Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA19218; Mon, 5 Feb 2001 09:29:36 -0800 (PST) Received: from rgm.htt-consult.com ([63.82.18.214]) by htt-consult.com ; Mon, 05 Feb 2001 12:36:50 -0500 Message-Id: <5.0.0.25.2.20010205123520.029da5b0@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 05 Feb 2001 12:36:10 -0500 To: "Bernard Aboba" , "Sara Bitan" , "IPSRA list" From: Robert Moskowitz Subject: RE: Starting the decision on PIC vs. GetCert Cc: "Paul Hoffman" In-Reply-To: References: <5.0.0.25.2.20010205094447.02a05b40@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 09:17 AM 2/5/2001 -0800, Bernard Aboba wrote: > >It would be easy for me to change GETCERT to use CMP and CMP Transport over > >HTTP making it fully compliant with PKIX standards, just not following the > >Appendix B ir senario. > >Personally, I think this would be a good idea -- especially if EAP support >could be added as well. This would require protection of the EAP >conversation. this is a cert request, and CMP and CMC have the data structures for requesting certs. Does EAP? Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ietf-ipsra@mail.vpnc.org Mon Feb 5 14:43:14 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15796 for ; Mon, 5 Feb 2001 14:43:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23776 for ietf-ipsra-bks; Mon, 5 Feb 2001 10:47:08 -0800 (PST) Received: from gate.internaut.com ([64.38.134.108]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23770; Mon, 5 Feb 2001 10:47:07 -0800 (PST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f15ImuR30447; Mon, 5 Feb 2001 10:48:56 -0800 From: "Bernard Aboba" To: "Robert Moskowitz" , "Sara Bitan" , "IPSRA list" Cc: "Paul Hoffman" Subject: RE: Starting the decision on PIC vs. GetCert Date: Mon, 5 Feb 2001 10:54:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <5.0.0.25.2.20010205123520.029da5b0@localhost> Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >this is a cert request, and CMP and CMC have the data structures for >requesting certs. Does EAP? No. It's just a multi-round trip authentication "wrapper" (see RFC 2284 for details). So you can only use EAP for verifying the identity, but not for the cert request itself. However, since EAP doesn't provide a protected negotiation (unlike IKE or GSS_API SPNEGO), the EAP conversation should occur over a secure channel. From owner-ietf-ipsra@mail.vpnc.org Mon Feb 5 15:25:12 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16748 for ; Mon, 5 Feb 2001 15:25:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25249 for ietf-ipsra-bks; Mon, 5 Feb 2001 11:30:05 -0800 (PST) Received: from htt-consult.com ([63.82.18.210]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA25242; Mon, 5 Feb 2001 11:30:03 -0800 (PST) Received: from rgm.htt-consult.com ([63.82.18.214]) by htt-consult.com ; Mon, 05 Feb 2001 14:37:18 -0500 Message-Id: <5.0.0.25.2.20010205143548.029c4eb0@localhost> X-Sender: rgm-sec@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 05 Feb 2001 14:36:28 -0500 To: "Bernard Aboba" , "Sara Bitan" , "IPSRA list" From: Robert Moskowitz Subject: RE: Starting the decision on PIC vs. GetCert Cc: "Paul Hoffman" In-Reply-To: References: <5.0.0.25.2.20010205123520.029da5b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ipsra@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:54 AM 2/5/2001 -0800, Bernard Aboba wrote: > >this is a cert request, and CMP and CMC have the data structures for > >requesting certs. Does EAP? > >No. It's just a multi-round trip authentication "wrapper" (see >RFC 2284 for details). So you can only use EAP for verifying the >identity, but not for the cert request itself. However, since >EAP doesn't provide a protected negotiation (unlike IKE or >GSS_API SPNEGO), the EAP conversation should occur over a >secure channel. oh, yes. remeMber the discussion. perhaps you will help me with that part of GETCERT :) Robert Moskowitz ICSA Security Interest EMail: rgm-sec@htt-consult.com From owner-ietf-ipsra@mail.vpnc.org Tue Feb 6 17:16:43 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03687 for ; Tue, 6 Feb 2001 17:16:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05435 for ietf-ipsra-bks; Tue, 6 Feb 2001 13:18:52 -0800 (PST) Received: from rc_westlake.interdyn.com ([205.147.53.144]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05420; Tue, 6 Feb 2001 13:18:47 -0800 (PST) Received: by RC_WESTLAKE with Internet Mail Service (5.5.2653.19) id <1F7PC4R8>; Tue, 6 Feb 2001 13:25:31 -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 1F7LFDGR; Tue, 6 Feb 2001 13:25:12 -0800 Message-ID: <3A806B9D.51EF91D6@redcreek.com> Date: Tue, 06 Feb 2001 13:24:45 -0800 From: "Scott G. Kelly" 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 To: Sara Bitan CC: IPSRA list , Paul Hoffman Subject: Re: Starting the decision on PIC vs. GetCert References: <3A7D16A5.C9F094D9@radguard.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 I haven't come down one way or the other yet, but have made the following observations: if pic is chosen, the fact that it would be part of the ipsec subsystem makes the problem of getting the cert into the ipsec credential db transparent to the user. If getcert is used with a browser interface, this is not the case (although I know getcert could be implemented by the ipsec client code as well). Also, getcert may be susceptible to any associated tls security issues. Comments, anyone? Scott From owner-ietf-ipsra@mail.vpnc.org Wed Feb 7 15:58:34 2001 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08625 for ; Wed, 7 Feb 2001 15:58:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01781 for ietf-ipsra-bks; Wed, 7 Feb 2001 11:44:51 -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 LAA01777 for ; Wed, 7 Feb 2001 11:44:48 -0800 (PST) Received: from [192.168.7.5] by tholian.securitydynamics.com via smtpd (for mail.vpnc.org [208.184.76.50]) with SMTP; 7 Feb 2001 19:50:48 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 OAA28283; Wed, 7 Feb 2001 14:48:25 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2650.21) id <1PPSN2AA>; Wed, 7 Feb 2001 14:48:25 -0500 Message-ID: From: "Linn, John" To: "'Bernard Aboba'" , Robert Moskowitz , IPSRA list Subject: RE: Starting the decision on PIC vs. GetCert Date: Wed, 7 Feb 2001 14:48:12 -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: I'll second the motion that a change from SCEP to CMP would be a positive step for GetCert. Per EAP, PIC's choice to layer on EAP was fortunate in that it provides natively to support multi-step transactions where needed. As such, it offers another means to incorporate this capability into GetCert, alternative to the approaches that were discussed on the list at and shortly after the San Diego meeting. --jl > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, February 05, 2001 12:17 PM > To: Robert Moskowitz; Sara Bitan; IPSRA list > Cc: Paul Hoffman > Subject: RE: Starting the decision on PIC vs. GetCert > > > >It would be easy for me to change GETCERT to use CMP and CMP > Transport over > >HTTP making it fully compliant with PKIX standards, just not > following the > >Appendix B ir senario. > > Personally, I think this would be a good idea -- especially > if EAP support > could be added as well. This would require protection of the EAP > conversation. > From owner-ietf-ipsra@mail.vpnc.org Fri Feb 9 20:02:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05431 for ; Fri, 9 Feb 2001 20:02:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id QAA13020 for ietf-ipsra-bks; Fri, 9 Feb 2001 16:10:03 -0800 (PST) Received: from NEPTUNE.zucotto.com ([216.95.209.154]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA12627; Fri, 9 Feb 2001 16:02:42 -0800 (PST) Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Feb 2001 19:02:32 -0500 Message-ID: From: Kulwinder Atwal To: "'zeroconf@merit.edu'" , seamoby@cdma-2000.org, MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, "'srvloc@srvloc.org'" , "'aaa-wg@merit.edu'" , "'manet@itd.nrl.navy.mil'" , "'ipsec@lists.tislabs.com'" , "'ipsec-policy@vpnc.org'" , "'ietf-ipsra@vpnc.org'" , "'ietf-sacred@imc.org'" , "'enum@ietf.org'" , "'sigtran@standards.nortelnetworks.com'" , "'ietf@ietf.org'" , "'IETF-Announce@ietf.org'" , "'BLUETOOTH-BOF@mailbag.cps.intel.com'" Cc: "'Thomas Narten'" , Akers Ron-WRA001 Subject: BOF: IP over Bluetooth for 50th Meeting of IETF. Date: Fri, 9 Feb 2001 19:02:30 -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: Myself and Ron Akers have requested an IP over Bluetooth BOF for the 50th Meeting of the IETF in Minneapolis. The BOF will discuss the creation of a IETF Working Group to investigate the most open and efficient way to place IP over the Bluetooth Host Controller. Current work in this area within the Bluetooth SIG concentrates on defining IP over a set of other lower-layer stacks. Currently there are two options defined by the Bluetoth SIG: Option 1: IP/PPP/RFCOM/L2CAP/Host Controller Option 2: IP/PAN Profile/L2CAP/Host Controller (where the PAN Profile is a Bluetooth SIG work in progress) We are proposing that the IETF form a WG to define a more efficient way of running IP over Bluetooth. In particular, IP would run over an IETF protocol over the Host Controller without L2CAP. This option may be adopted by the Bluetooth SIG at a later date as a Profile. Since all Bluetooth SIG Profiles are optional, a customer may choose any combination of Profiles in a final product. Further, since Bluetooth Working Groups have it in their mandate to adopt protocols from other standards making bodies such as the IETF, there exists a clear path for IETF work to be adopted by the Bluetooth SIG. Whereas the last BOF was informational only and organized by the Bluetooth SIG itself, the objective of this BOF will be to foster innovation, and speed progress by placing IP related protocol development wihin the IETF and Bluetooth-specific protocol development within the Bluetooth SIG, by developing an IP over Bluetooth IETF Working Group. This effort will define its own way of running IP over Bluetooth, by carefully selecting a set of Bluetooth protocols (freely available from published specifications at http://www.bluetooth.com/developer/specification/specification.asp) on which to build IP. Please join myself, Kulwinder Atwal, and Ron Akers on the pre-BOF mailing list: This site runs version 2.0.1 of the "Mailman" list manager. The following describes commands you can send to get information about, and control your subscription to the lists at this site. Note that much of the following can also be accomplished via the World Wide Web, at: http://internet.motlabs.com/mailman/listinfo/bluetooth In particular, you can use the Web site to have your password sent to your delivery address. Email commands can be in the subject line or in the body of the message. The commands should be set to the following address: About the descriptions - words in "<>"s signify REQUIRED items and words in "[]" denote OPTIONAL items. Do not include the "<>"s or "[]"s when you use the commands. The following commands are valid: subscribe [password] [digest-option] [address=
] Subscribe to the mailing list. Your password must be given to unsubscribe or change your options. When you subscribe to the list, you'll be reminded of your password periodically. 'digest-option' may be either: 'nodigest' or 'digest' (no quotes!) If you wish to subscribe an address other than the address you send this request from, you may specify "address=" (no brackets around the email address, no quotes!) unsubscribe [address] Unsubscribe from the mailing list. Your password must match the one you gave when you subscribed. If you are trying to unsubscribe from a different address than the one you subscribed from, you may specify it in the 'address' field. who See everyone who is on this mailing list. info View the introductory information for this list. lists See what mailing lists are run by this Mailman server. help This message. set