From owner-ipsec-policy@mail.vpnc.org Tue Jun 5 09:26:50 2001 Received: from above.proper.com ([208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAB19831 for ; Tue, 5 Jun 2001 09:26:49 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id FAA10479 for ipsec-policy-bks; Tue, 5 Jun 2001 05:24:05 -0700 (PDT) Received: from h0001027441c5.ne.mediaone.net (h0001027441c5.ne.mediaone.net [24.128.60.72]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA10472 for ; Tue, 5 Jun 2001 05:23:58 -0700 (PDT) Received: from europa-h0001027441c5.ne.mediaone.net (europa [192.168.20.40]) by h0001027441c5.ne.mediaone.net (8.9.3/8.8.7) with ESMTP id IAA02793; Tue, 5 Jun 2001 08:28:43 -0400 Received: from jdscons.com (localhost [127.0.0.1]) by europa-h0001027441c5.ne.mediaone.net (8.9.3+Sun/8.9.3) with ESMTP id IAA09404; Tue, 5 Jun 2001 08:22:59 -0400 (EDT) Message-Id: <200106051222.IAA09404@europa-h0001027441c5.ne.mediaone.net> To: Wes Hardaker cc: Ricky Charlet , caseycarr@usa.com, IPSec Policy WG Subject: Re: FW: TDomain in IPSEC-POLICY-MIB From: Jon Saperia In-reply-to: Your message of 31 May 2001 12:39:02 -0700. Date: Tue, 05 Jun 2001 08:22:59 -0400 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wes, bottom line 2 based on my read of your summary makes most sense. go for it:-) /jon > > Since no one responded to my queries about the following, I'll > probably pick #2 (shortly, as I'll be working on the MIB this week and > next) unless someone argues otherwise. > > >>>>> On 25 Apr 2001 15:40:08 -0700, Wes Hardaker said: > > Wes> 1) use current existing TDomain style definitions, which (as pointed > Wes> out) don't really fit our needs. > > Wes> 2) Use the above IpsecDoiIdentType definition, and then define how the > Wes> value half of that is specified, um, somewhere? Should we then > Wes> make a IpsecDoiIdentValue TC that has an extremely long description > Wes> clause spelling out the value formating of the OCTETSTRING that its > Wes> made of? > > Wes> 3) Define our own set of 11 or so TDomains to match the above and > Wes> continue to use TAddress as the value specifier. > > Wes> There are also issues revolving around how they should be used. In > Wes> the case of specifying an endpoint that is supposed to be singular > Wes> (open a connection to "here"), should the description clause of every > Wes> object dictate which is legal for that column and which isn't? Or > Wes> should that definition be defined in the TC (I'd vote for the TC, but > Wes> common MIB practice is to cut-n-paste it everywhere to make sure its > Wes> visible and not missed because they didn't follow the TC reference). > > Wes> I've started converting the other pieces of the MIB to use the other > Wes> TCs defined in the previously mentioned draft, but this is the case > Wes> that truly needs more thoughts. > > Wes> Opinions? I'm leaning towards #2 above I guess. > > Wes> -- > Wes> Wes Hardaker > Wes> NAI Labs > Wes> Network Associates > > > -- > Wes Hardaker > NAI Labs > Network Associates > Thanks, /jon -- Jon Saperia saperia@jdscons.com Phone: 617-744-1079 Fax: 617-249-0874 http://www.jdscons.com/ From owner-ipsec-policy@mail.vpnc.org Wed Jun 6 22:44:47 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 WAA14172 for ; Wed, 6 Jun 2001 22:44:46 -0400 (EDT) Received: by above.proper.com (8.9.3/8.9.3) id SAA13609 for ipsec-policy-bks; Wed, 6 Jun 2001 18:51:14 -0700 (PDT) Received: from longmail2.lboard.com ([63.109.116.89]) by above.proper.com (8.9.3/8.9.3) with ESMTP id SAA13599 for ; Wed, 6 Jun 2001 18:51:00 -0700 (PDT) Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Jun 2001 21:50:37 -0400 Message-ID: From: Ed Ellesson To: "'ipsec-policy@vpnc.org'" Cc: "'Wijnen, Bert (Bert)'" , "'Joel M. Halpern'" Subject: IPsec WG Notice: Policy Terminology Last Call is now complete Date: Wed, 6 Jun 2001 21:50:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, IPsec WG: We apologize to those of you who receive more than one copy of this notice. The extended working group last call is now completed, for the draft titled "Terminology" (draft-ietf-policy-terminology-03.txt), which is being re-titled as "Terminology for Policy-Based Management". This extended last call provided an opportunity for the following working groups to comment on the draft, and discuss proposed changes on the Policy Framework WG mailing list. Working groups participating in the extended working group last call for this draft: Policy DiffServ RAP IPSP SNMPCONF AAA AAAArch (IRTF) RSVP MPLS Comments resulting from this extended multiple working group last call were discussed and accepted on the policy framework working group mailing list. The document will be revised in accordance with the results of that discussion. The Policy Framework working group will then submit it to the IESG to request their review and approval for publication as an Informational RFC. Thanks to all of you who participated in this successful extended working group last call, and a special thanks to Andrea Westerinen, who edited the draft, engaged in the discussion of the comments, and who will update it per the discussion results. Ed Ellesson, with Joel Halpern, Co-chairs, Policy Framework WG From owner-ipsec-policy@mail.vpnc.org Tue Jun 12 11:53:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18122 for ; Tue, 12 Jun 2001 11:53:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5CE9El26968 for ipsec-policy-bks; Tue, 12 Jun 2001 07:09:14 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5CE99J26959 for ; Tue, 12 Jun 2001 07:09:09 -0700 (PDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5CE9A811967 for ; Tue, 12 Jun 2001 09:09:10 -0500 (CDT) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 12 Jun 2001 09:09:08 -0500 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 12 Jun 2001 09:09:08 -0500 Message-ID: From: Man.M.Li@nokia.com To: pierrick.morand@rd.francetelecom.fr, ipsec-policy@vpnc.org Cc: yoann.noisette@rd.francetelecom.fr, wilfrid.rabot@rd.francetelecom.fr Subject: RE: COPS-PR security general issues Date: Tue, 12 Jun 2001 09:09:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, COPS-PR is designed to push down various types of policy. Some are security related and some are not. In cases where one is reasonably confident that his private network is secure, he may push down QOS policy with COPS-PR without additional security protection for example. Your comments about pushing down shared secrets is interesting. People have made similar comments about the IPsec PIB. My first reaction has been that shared secrets are not policy. But including them inside the policy does provide convenience, provided COPS-PR is protected securely. Any comments on this from the group? Man Li Nokia 5 Wayside Road, Burlington, MA 01803 man.m.li@nokia.com phone 1-781-993-3923 GSM 1-781-492-2850 -----Original Message----- From: ext MORAND Pierrick FTRD/DMI/CAE [mailto:pierrick.morand@rd.francetelecom.fr] Sent: Thursday, May 31, 2001 8:08 AM To: IPSEC-POLICY (E-mail); RAP (E-mail) Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE Subject: COPS-PR security general issues We are currently working on the general theme of provisioning. We are considering COPS-PR with attention and would bring to the attention of RAP and IPSP experts the following remarks and questions with our apologizes if these issues have already been debated. In a general way, COPS-PR has been designed to provision configuration policies for various functional domains such as IPSec, L2TP, MPLS, AAA, Routing, TE .... Considering for instance, IPSec, AAA and L2TP, provisioning of those functions leads to exchange with the equipment sensitive information such as shared secrets (L2TP-Tunnel-password, users password, radius secret and so on). Within COPS there is an optional security mechanisms, which only guarantees the integrity of the COPS messages. There is no general mechanisms allowing to cipher some particular sensitive fields. Do these security issues shall conduct an implementer or an operator to systematically make use of IPSec to secure exchanges between a PEP and a PDP so that it becomes possible to provision sensitive security information without having to defined ciphered fields in the PIBs for which no generic mechanisms have currently been defined ? If IPSec is used to secure COPS-PR exchanges what would become the utility of the integrity mechanisms defined within COPS and more especially when used within COPS-PR ? Additionally, the IPSec PIB which is currently in its definition phase, allows to define IKE rules specifying pre-shared key as Ike proposal authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with presharedKey(1) as possible value]method but does not allow to provision those secrets. This means that the provisioning of those secrets shall be done by an other way and in that case advantages of COPS-PR in case of pre-shared authentication becomes greatly reduced since this shall be achieved by hand or using an other mechanism. In a same way if L2TP or AAA PIBs were to be defined how secrets (and more generally sensitive information) should be provisioned ? -In clear : not reasonable -Ciphered : there is no generic mechanisms -Protected by IPSec, SSL... : should work fine, but the RFC should precise that usage of a particular client type, defining sensitive information MUST make use of an external mechanisms in order to secure those sensitive information.. To conclude it seams that we can have the two possible approaches in order to allow the exchange of sensible security information between a PEP an a PDP : 1-systematicaly make use of an underlying security layer (IPSec for instance) to secure exchanges between PEP and PDP. In that case the COPS integrity mechanism is no more necessary. This approach implies that the PEP has to support a security communication layer which might not be the case in all situation. 2-defines a generic COPS ciphering mechanism which allows to protect some sensitive fields. Security is embedded in the COPS protocol and must be supported. If this issue was solved, could IPSP experts extend the PIB so that shared secret can be exchanged or is the reason for which it is not currently supported more fundamental ? Thanks in advance for your answers and comments. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@francetelecom.com From owner-ipsec-policy@mail.vpnc.org Wed Jun 13 18:21:08 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02635 for ; Wed, 13 Jun 2001 18:21:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5DKtIE07595 for ipsec-policy-bks; Wed, 13 Jun 2001 13:55:18 -0700 (PDT) Received: from email2.it.west.unispherenetworks.com ([65.194.140.138]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5DKtGJ07587 for ; Wed, 13 Jun 2001 13:55:17 -0700 (PDT) Received: by mailhost2.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Jun 2001 16:55:14 -0400 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F03533A5D@mailhost2.unispherenetworks.com> From: "Moisand, Jerome" To: "'IPSEC-POLICY (E-mail)'" , "'RAP (E-mail)'" Subject: RE: COPS-PR security general issues Date: Wed, 13 Jun 2001 16:54:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry if it's a duplicate, sounds that I got filtered first time I sent this e-mail. Tx Jerome -----Original Message----- From: Moisand, Jerome Sent: Wednesday, June 13, 2001 11:19 AM To: 'MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail); RAP (E-mail) Subject: RE: COPS-PR security general issues I support the concern described by the e-mail quoted below, which resonates quite well with what I heard from multiple service providers during COPS-related discussions. I would suggest that the topic is discussed during the next IETF meeting in the context of the "rap" group since the point is essentially to secure the COPS/COPS-PR interactions, irrespective of the type of policies being managed. In this context, among other alternatives, I would also suggest to discuss the following internet-draft: http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt Tx Jerome =========================================== Jerome P. Moisand Senior Product Manager Unisphere Networks mailto:jmoisand@UnisphereNetworks.com -----Original Message----- From: MORAND Pierrick FTRD/DMI/CAE [mailto:pierrick.morand@rd.francetelecom.fr] Sent: Thursday, May 31, 2001 8:08 AM To: IPSEC-POLICY (E-mail); RAP (E-mail) Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE Subject: COPS-PR security general issues We are currently working on the general theme of provisioning. We are considering COPS-PR with attention and would bring to the attention of RAP and IPSP experts the following remarks and questions with our apologizes if these issues have already been debated. In a general way, COPS-PR has been designed to provision configuration policies for various functional domains such as IPSec, L2TP, MPLS, AAA, Routing, TE .... Considering for instance, IPSec, AAA and L2TP, provisioning of those functions leads to exchange with the equipment sensitive information such as shared secrets (L2TP-Tunnel-password, users password, radius secret and so on). Within COPS there is an optional security mechanisms, which only guarantees the integrity of the COPS messages. There is no general mechanisms allowing to cipher some particular sensitive fields. Do these security issues shall conduct an implementer or an operator to systematically make use of IPSec to secure exchanges between a PEP and a PDP so that it becomes possible to provision sensitive security information without having to defined ciphered fields in the PIBs for which no generic mechanisms have currently been defined ? If IPSec is used to secure COPS-PR exchanges what would become the utility of the integrity mechanisms defined within COPS and more especially when used within COPS-PR ? Additionally, the IPSec PIB which is currently in its definition phase, allows to define IKE rules specifying pre-shared key as Ike proposal authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with presharedKey(1) as possible value]method but does not allow to provision those secrets. This means that the provisioning of those secrets shall be done by an other way and in that case advantages of COPS-PR in case of pre-shared authentication becomes greatly reduced since this shall be achieved by hand or using an other mechanism. In a same way if L2TP or AAA PIBs were to be defined how secrets (and more generally sensitive information) should be provisioned ? -In clear : not reasonable -Ciphered : there is no generic mechanisms -Protected by IPSec, SSL... : should work fine, but the RFC should precise that usage of a particular client type, defining sensitive information MUST make use of an external mechanisms in order to secure those sensitive information.. To conclude it seams that we can have the two possible approaches in order to allow the exchange of sensible security information between a PEP an a PDP : 1-systematicaly make use of an underlying security layer (IPSec for instance) to secure exchanges between PEP and PDP. In that case the COPS integrity mechanism is no more necessary. This approach implies that the PEP has to support a security communication layer which might not be the case in all situation. 2-defines a generic COPS ciphering mechanism which allows to protect some sensitive fields. Security is embedded in the COPS protocol and must be supported. If this issue was solved, could IPSP experts extend the PIB so that shared secret can be exchanged or is the reason for which it is not currently supported more fundamental ? Thanks in advance for your answers and comments. Pierrick Morand france telecom R&D/DMI/SIR/IPI Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 Email :pierrick.morand@francetelecom.com From owner-ipsec-policy@mail.vpnc.org Thu Jun 14 10:55:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01507 for ; Thu, 14 Jun 2001 10:55:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5EDMWs08201 for ipsec-policy-bks; Thu, 14 Jun 2001 06:22:32 -0700 (PDT) Received: from email2.it.west.unispherenetworks.com ([65.194.140.138]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5EDMVJ08192 for ; Thu, 14 Jun 2001 06:22:31 -0700 (PDT) Received: by mailhost2.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Jun 2001 09:22:27 -0400 Message-ID: <9DCB6C9DC7C3D311B835009027DE069F03533A78@mailhost2.unispherenetworks.com> From: "Moisand, Jerome" To: "'IPSEC-POLICY (E-mail)'" , "'RAP (E-mail)'" Subject: RE: COPS-PR security general issues Date: Thu, 14 Jun 2001 09:20:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Personally, I also have sympathy for the "simple is beautiful" COPS/TLS solution. But didn't want to jump to conclusions too fast. So I was simply suggesting that it's probably worth going through a good open discussion on this security topic, try to reach a good consensus and then possibly enhance/clarify the existing COPS-related material with specific recommendations. Makes sense? Jerome -----Original Message----- From: Durham, David [mailto:david.durham@intel.com] Sent: Wednesday, June 13, 2001 8:32 PM To: Moisand, Jerome; 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)' Subject: RE: COPS-PR security general issues The basic integrity mechanisms of the COPS protocol are required to be implemented, thus ensuring they will be universally available... but are optionally used. So this means other security mechanisms can be used instead of or to augment the integrity object. For privately exchanging information using COPS, TLS/SSL is the preferred security mechanism since COPS already runs over TCP. Specific client-types can be defined that *require* a specific additional security mechanism must be used, such as TLS. This is done by simply stating as much in the security considerations section of the corresponding document. Given TLS, do you see any reason to implement per-attribute security via Diffie-Hellman exchanges or some other mechanism? TLS seems more than sufficient for COPS messaging given the persistent TCP connection & single master control. -Dave > -----Original Message----- > From: Moisand, Jerome [mailto:jmoisand@unispherenetworks.com] > Sent: Wednesday, June 13, 2001 1:54 PM > To: 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)' > Subject: RE: COPS-PR security general issues > > > > Sorry if it's a duplicate, sounds that I got filtered first > time I sent this > e-mail. > > Tx > Jerome > > -----Original Message----- > From: Moisand, Jerome > Sent: Wednesday, June 13, 2001 11:19 AM > To: 'MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail); > RAP (E-mail) > Subject: RE: COPS-PR security general issues > > > > I support the concern described by the e-mail quoted below, > which resonates > quite well with what I heard from multiple service providers during > COPS-related discussions. > > I would suggest that the topic is discussed during the next > IETF meeting in > the context of the "rap" group since the point is essentially > to secure the > COPS/COPS-PR interactions, irrespective of the type of policies being > managed. > > In this context, among other alternatives, I would also > suggest to discuss > the following internet-draft: > http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt > > Tx > Jerome > > =========================================== > Jerome P. Moisand > Senior Product Manager > Unisphere Networks > mailto:jmoisand@UnisphereNetworks.com > > > > > -----Original Message----- > From: MORAND Pierrick FTRD/DMI/CAE > [mailto:pierrick.morand@rd.francetelecom.fr] > Sent: Thursday, May 31, 2001 8:08 AM > To: IPSEC-POLICY (E-mail); RAP (E-mail) > Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE > Subject: COPS-PR security general issues > > > We are currently working on the general theme of provisioning. We are > considering COPS-PR with attention and would bring to the > attention of RAP > and IPSP experts the following remarks and questions with our > apologizes if > these issues have already been debated. > > In a general way, COPS-PR has been designed to provision configuration > policies for various functional domains such as IPSec, L2TP, > MPLS, AAA, > Routing, TE .... > > Considering for instance, IPSec, AAA and L2TP, provisioning of those > functions leads to exchange with the equipment sensitive > information such as > shared secrets (L2TP-Tunnel-password, users password, radius > secret and so > on). > > Within COPS there is an optional security mechanisms, which > only guarantees > the integrity of the COPS messages. There is no general > mechanisms allowing > to cipher some particular sensitive fields. > > Do these security issues shall conduct an implementer or an > operator to > systematically make use of IPSec to secure exchanges between > a PEP and a PDP > so that it becomes possible to provision sensitive security > information > without having to defined ciphered fields in the PIBs for > which no generic > mechanisms have currently been defined ? > > If IPSec is used to secure COPS-PR exchanges what would > become the utility > of the integrity mechanisms defined within COPS and more > especially when > used within COPS-PR ? > > Additionally, the IPSec PIB which is currently in its > definition phase, > allows to define IKE rules specifying pre-shared key as Ike proposal > authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with > presharedKey(1) as possible value]method but does not allow > to provision > those secrets. This means that the provisioning of those > secrets shall be > done by an other way and in that case advantages of COPS-PR in case of > pre-shared authentication becomes greatly reduced since this shall be > achieved by hand or using an other mechanism. > > In a same way if L2TP or AAA PIBs were to be defined how > secrets (and more > generally sensitive information) should be provisioned ? > -In clear : not reasonable > -Ciphered : there is no generic mechanisms > -Protected by IPSec, SSL... : should work fine, but the RFC > should precise > that usage of a particular client type, defining sensitive > information MUST > make use of an external mechanisms in order to secure those sensitive > information.. > > To conclude it seams that we can have the two possible > approaches in order > to allow the exchange of sensible security information > between a PEP an a > PDP : > 1-systematicaly make use of an underlying security layer (IPSec for > instance) to secure exchanges between PEP and PDP. In that > case the COPS > integrity mechanism is no more necessary. This approach > implies that the PEP > has to support a security communication layer which might not > be the case in > all situation. > 2-defines a generic COPS ciphering mechanism which allows to > protect some > sensitive fields. Security is embedded in the COPS protocol > and must be > supported. > > If this issue was solved, could IPSP experts extend the PIB > so that shared > secret can be exchanged or is the reason for which it is not currently > supported more fundamental ? > > Thanks in advance for your answers and comments. > > Pierrick Morand > france telecom R&D/DMI/SIR/IPI > Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 > Email :pierrick.morand@francetelecom.com > > > > From owner-ipsec-policy@mail.vpnc.org Wed Jun 20 13:27:56 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 NAA15080 for ; Wed, 20 Jun 2001 13:27:54 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5KG7Nq28184 for ipsec-policy-bks; Wed, 20 Jun 2001 09:07:23 -0700 (PDT) Received: from rebma.mikesoffice.com (adsl-63-195-146-66.dsl.scrm01.pacbell.net [63.195.146.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5KG7Lk28180 for ; Wed, 20 Jun 2001 09:07:22 -0700 (PDT) Received: (from baerm@localhost) by rebma.mikesoffice.com (8.9.3/8.9.3) id JAA20040; Wed, 20 Jun 2001 09:08:36 -0700 X-Authentication-Warning: rebma.mikesoffice.com: baerm set sender to baerm@mikesoffice.com using -f To: ipsec-policy@vpnc.org Subject: draft-ietf-ipsp-config-policy-model-02: SAStaticAction From: Michael Baer Date: 20 Jun 2001 09:08:36 -0700 Message-ID: <86ithrb0cb.fsf@rebma.mikesoffice.com> Lines: 15 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I'm trying to map the SAStaticAction classes over to the IPSEC-POLICY-MIB and I came across a property I don't understand the location of. In the class definition for SAStaticAction, it has the property of LifetimeSeconds. I don't see much use for it though for the sub-classes of Bypass, Discard, or Reject Actions. Shouldn't this property be moved to the PreconfiguredSAAction class (where LifetimeKilobytes is also located)? Mike -- Michael Baer NAI Labs From owner-ipsec-policy@mail.vpnc.org Thu Jun 21 12:26:15 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 MAA05088 for ; Thu, 21 Jun 2001 12:26:14 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5LFA8b01765 for ipsec-policy-bks; Thu, 21 Jun 2001 08:10:08 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5LFA5k01761 for ; Thu, 21 Jun 2001 08:10:05 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA14370 for ; Thu, 21 Jun 2001 11:06:46 -0400 Received: from lmr (dyn9-37-49-222.raleigh.ibm.com [9.37.49.222]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA23772 for ; Thu, 21 Jun 2001 11:09:49 -0400 Message-ID: <003d01c0fa63$a3602f70$de312509@lmr> From: "Lee Rafalow" To: References: <86ithrb0cb.fsf@rebma.mikesoffice.com> Subject: Re: draft-ietf-ipsp-config-policy-model-02: SAStaticAction Date: Thu, 21 Jun 2001 11:05:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think the reason was that one might have rules that have time of day contraints (using PolicyTimePeriodCondition) and that any SA set up during a particular period needed to expire at some point. For example, during normal business hours a rule permits certain traffic to bypass but in the evening it's blocked. The bypass SA is established with a lifetime seconds. ----- Original Message ----- From: "Michael Baer" To: Sent: Wednesday, June 20, 2001 12:08 PM Subject: draft-ietf-ipsp-config-policy-model-02: SAStaticAction > > Hi, > > I'm trying to map the SAStaticAction classes over to the > IPSEC-POLICY-MIB and I came across a property I don't understand the > location of. In the class definition for SAStaticAction, it has the > property of LifetimeSeconds. I don't see much use for it though for > the sub-classes of Bypass, Discard, or Reject Actions. Shouldn't this > property be moved to the PreconfiguredSAAction class (where > LifetimeKilobytes is also located)? > > Mike > > -- > Michael Baer > NAI Labs From owner-ipsec-policy@mail.vpnc.org Mon Jun 25 15:47:54 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 PAA25444 for ; Mon, 25 Jun 2001 15:47:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5PIbFg17588 for ipsec-policy-bks; Mon, 25 Jun 2001 11:37:15 -0700 (PDT) Received: from lntril01.tril-inc.com (73-67-51-66.reonbroadband.com [66.51.67.73] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5PIbDk17583 for ; Mon, 25 Jun 2001 11:37:13 -0700 (PDT) To: ipsec-policy@vpnc.org Subject: Credential Filter Entry MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: pjkirner@tril-inc.com Date: Mon, 25 Jun 2001 14:42:39 -0400 X-MIMETrack: Serialize by Router on lntril01/Servers/Trilogy(Release 5.0.6a |January 17, 2001) at 06/25/2001 02:42:48 PM, Serialize complete at 06/25/2001 02:42:48 PM Content-Type: multipart/alternative; boundary="=_alternative 00666C0785256A76_=" Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multipart message in MIME format. --=_alternative 00666C0785256A76_= Content-Type: text/plain; charset="us-ascii" Can someone please help me understand intended use of the CredentialFilterEntry, and possible give me examples of MatchFieldName and MatchField Value pairs? One possible use I see is to reject or accept credentials based on some criteria like the RSA key size must be greater than 1024 bits or something similar for X.509 certs? Are there any others or do I have the wrong interpretation? Thanks. PJ Kirner Trilogy, Inc. --=_alternative 00666C0785256A76_= Content-Type: text/html; charset="us-ascii"
Can someone please help me understand intended use of the CredentialFilterEntry, and possible give me examples of MatchFieldName and MatchField Value pairs?   One possible use I see is to reject or accept credentials based on some criteria like the RSA key size must be greater than 1024 bits or something similar for X.509 certs?  Are there any others or do I have the wrong interpretation?  Thanks.

PJ Kirner
Trilogy, Inc. --=_alternative 00666C0785256A76_=-- From owner-ipsec-policy@mail.vpnc.org Wed Jun 27 21:50:05 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 VAA16428 for ; Wed, 27 Jun 2001 21:50:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5S02J203256 for ipsec-policy-bks; Wed, 27 Jun 2001 17:02:19 -0700 (PDT) Received: from rebma (dns1.hardaker.davis.ca.us [168.150.190.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5S02Hm03252 for ; Wed, 27 Jun 2001 17:02:17 -0700 (PDT) Received: (from baerm@localhost) by rebma (8.9.3/8.9.3) id RAA17962; Wed, 27 Jun 2001 17:03:35 -0700 X-Authentication-Warning: rebma: baerm set sender to baerm@mikesoffice.com using -f To: "Lee Rafalow" Cc: Subject: Re: draft-ietf-ipsp-config-policy-model-02: SAStaticAction References: <86ithrb0cb.fsf@rebma.mikesoffice.com> <003d01c0fa63$a3602f70$de312509@lmr> From: Michael Baer Organization: NAI Labs Date: 27 Jun 2001 17:03:35 -0700 In-Reply-To: <003d01c0fa63$a3602f70$de312509@lmr> ("Lee Rafalow"'s message of "Thu, 21 Jun 2001 11:05:40 -0400") Message-ID: <86ithh8o88.fsf@rebma.mikesoffice.com> Lines: 42 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Lee" == Lee Rafalow writes: Lee> I think the reason was that one might have rules that have Lee> time of day contraints (using PolicyTimePeriodCondition) and Lee> that any SA set up during a particular period needed to Lee> expire at some point. For example, during normal business Lee> hours a rule permits certain traffic to bypass but in the Lee> evening it's blocked. The bypass SA is established with a Lee> lifetime seconds. After looking over the IPsec spec, I see where this fits (I could already see where it could be practically useful). But for the sake of consistency, shouldn't lifetime kilobytes then also be a property of the SAStaticAction class (i.e. move it up from the PreconfiguredSAAction class) so as to be available for the deny, reject, and bypass static actions. I think that between the two, lifetime seconds would get used more often, but it seems to me that both lifetimeSec and lifetimeKB provide a very similar capability and should be available at the same class level. >> >> Hi, >> >> I'm trying to map the SAStaticAction classes over to the >> IPSEC-POLICY-MIB and I came across a property I don't >> understand the location of. In the class definition for >> SAStaticAction, it has the property of LifetimeSeconds. I don't >> see much use for it though for the sub-classes of Bypass, >> Discard, or Reject Actions. Shouldn't this property be moved to >> the PreconfiguredSAAction class (where LifetimeKilobytes is >> also located)? >> >> Mike >> >> -- Michael Baer NAI Labs -- Michael Baer baerm@mikesoffice.com NAI Labs From owner-ipsec-policy@mail.vpnc.org Wed Jun 27 22:03:29 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 WAA26047 for ; Wed, 27 Jun 2001 22:03:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5S0aSE03940 for ipsec-policy-bks; Wed, 27 Jun 2001 17:36:28 -0700 (PDT) Received: from rebma (dns1.hardaker.davis.ca.us [168.150.190.1]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5S0aRm03936 for ; Wed, 27 Jun 2001 17:36:27 -0700 (PDT) Received: (from baerm@localhost) by rebma (8.9.3/8.9.3) id RAA18048; Wed, 27 Jun 2001 17:38:05 -0700 X-Authentication-Warning: rebma: baerm set sender to baerm@mikesoffice.com using -f To: ipsec-policy@vpnc.org Subject: more ipsp-config-policy-mode-02 Q's/comments From: Michael Baer Organization: NAI Labs Date: 27 Jun 2001 17:38:04 -0700 Message-ID: <86els58mmr.fsf@rebma.mikesoffice.com> Lines: 18 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Looking over the DoActionLogging and DoPacketLogging properties in the SAAction class, I think the description for DoActionLogging should be re-phrased from 'when the action is performed' to something like 'when an attempt is made to establish the SA'. I believe this more explicitly what is really meant anyway. My understanding of the IPsec spec, RFC 2401, is that the action being performed may not just be the creation of the SA, but could also be the routing of a packet through an existing SA (although an implementation might handle this differently for efficiency). Assuming that the desired logging for DoActionLogging is just for the attempted creation of the SA, the re-phrase would be clearer. -- Michael Baer baerm@mikesoffice.com NAI Labs From owner-ipsec-policy@mail.vpnc.org Thu Jun 28 09:48:42 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 JAA12692 for ; Thu, 28 Jun 2001 09:48:40 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5SCcsE23203 for ipsec-policy-bks; Thu, 28 Jun 2001 05:38:54 -0700 (PDT) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SCcrm23199 for ; Thu, 28 Jun 2001 05:38:53 -0700 (PDT) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA15442; Thu, 28 Jun 2001 14:38:41 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010628142730.0c399ee8@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 14:32:08 +0200 To: Michael Baer From: Eric Vyncke Subject: Re: more ipsp-config-policy-mode-02 Q's/comments Cc: ipsec-policy@vpnc.org In-Reply-To: <86els58mmr.fsf@rebma.mikesoffice.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Michael, Some comments: 1) the DoActionLogging controls whether a single log event is generated (either upon success or failure). If I understood correctly your proposal, at least two log events would be generated: one when starting/attempting the action and another one upon success or failure. While I do see benefits in your proposal, I wonder whether it is really useful. 2) the point about generating a log event when a packet is forwarded through an IPSec, actually this is the purpose of the DoPacketLogging. Comments are of course welcome Regards -eric At 17:38 27/06/2001 -0700, Michael Baer wrote: >Looking over the DoActionLogging and DoPacketLogging properties in the >SAAction class, I think the description for DoActionLogging should be >re-phrased from 'when the action is performed' to something like 'when >an attempt is made to establish the SA'. > >I believe this more explicitly what is really meant anyway. My >understanding of the IPsec spec, RFC 2401, is that the action being >performed may not just be the creation of the SA, but could also be >the routing of a packet through an existing SA (although an >implementation might handle this differently for efficiency). Assuming >that the desired logging for DoActionLogging is just for the attempted >creation of the SA, the re-phrase would be clearer. > >-- >Michael Baer >baerm@mikesoffice.com >NAI Labs From owner-ipsec-policy@mail.vpnc.org Thu Jun 28 09:48:57 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 JAA12858 for ; Thu, 28 Jun 2001 09:48:55 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5SCcoJ23198 for ipsec-policy-bks; Thu, 28 Jun 2001 05:38:50 -0700 (PDT) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SCcnm23194 for ; Thu, 28 Jun 2001 05:38:49 -0700 (PDT) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA15456; Thu, 28 Jun 2001 14:38:42 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010628143619.0c394f10@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 14:38:39 +0200 To: pjkirner@tril-inc.com From: Eric Vyncke Subject: Re: Credential Filter Entry Cc: ipsec-policy@vpnc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: You are correct, the CredentialFilterEntry can be used to accept/reject Kerberos credential, or some specific issuer in the case of X.509 certificate, hash or signature algorithms or key sizes, ... But, I do expect that the most common use will be about the SubjectName of a X.509 certificate. Hope this helps -eric At 14:42 25/06/2001 -0400, pjkirner@tril-inc.com wrote: >Can someone please help me understand intended use of the >CredentialFilterEntry, and possible give me examples of MatchFieldName and >MatchField Value pairs? One possible use I see is to reject or accept >credentials based on some criteria like the RSA key size must be greater >than 1024 bits or something similar for X.509 certs? Are there any others >or do I have the wrong interpretation? Thanks. > >PJ Kirner >Trilogy, Inc. From owner-ipsec-policy@mail.vpnc.org Thu Jun 28 09:59:01 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 JAA19919 for ; Thu, 28 Jun 2001 09:59:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5SCcmh23193 for ipsec-policy-bks; Thu, 28 Jun 2001 05:38:48 -0700 (PDT) Received: from strange-brew.cisco.com (odd-brew.cisco.com [144.254.15.119]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SCclm23188 for ; Thu, 28 Jun 2001 05:38:47 -0700 (PDT) Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170]) by strange-brew.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA15416; Thu, 28 Jun 2001 14:38:39 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010628142020.0c46aee8@brussels.cisco.com> X-Sender: evyncke@brussels.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Jun 2001 14:21:28 +0200 To: "Moisand, Jerome" From: Eric Vyncke Subject: RE: COPS-PR security general issues Cc: "'IPSEC-POLICY (E-mail)'" , "'RAP (E-mail)'" In-Reply-To: <9DCB6C9DC7C3D311B835009027DE069F03533A78@mailhost2.unisphe renetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Even TLS needs to be provisioned on both sides of COPS in order to provide mutual authentication... Secure authentication is always difficult to bootstrap. TLS and IPSec are quite similar regarding bootstraping -eric At 09:20 14/06/2001 -0400, Moisand, Jerome wrote: >Personally, I also have sympathy for the "simple is beautiful" COPS/TLS >solution. But didn't want to jump to conclusions too fast. > >So I was simply suggesting that it's probably worth going through a good >open discussion on this security topic, try to reach a good consensus and >then possibly enhance/clarify the existing COPS-related material with >specific recommendations. > >Makes sense? > >Jerome > >-----Original Message----- >From: Durham, David [mailto:david.durham@intel.com] >Sent: Wednesday, June 13, 2001 8:32 PM >To: Moisand, Jerome; 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)' >Subject: RE: COPS-PR security general issues > > >The basic integrity mechanisms of the COPS protocol are required to be >implemented, thus ensuring they will be universally available... but are >optionally used. So this means other security mechanisms can be used instead >of or to augment the integrity object. For privately exchanging information >using COPS, TLS/SSL is the preferred security mechanism since COPS already >runs over TCP. Specific client-types can be defined that *require* a >specific additional security mechanism must be used, such as TLS. This is >done by simply stating as much in the security considerations section of the >corresponding document. > >Given TLS, do you see any reason to implement per-attribute security via >Diffie-Hellman exchanges or some other mechanism? TLS seems more than >sufficient for COPS messaging given the persistent TCP connection & single >master control. > >-Dave > > > -----Original Message----- > > From: Moisand, Jerome [mailto:jmoisand@unispherenetworks.com] > > Sent: Wednesday, June 13, 2001 1:54 PM > > To: 'IPSEC-POLICY (E-mail)'; 'RAP (E-mail)' > > Subject: RE: COPS-PR security general issues > > > > > > > > Sorry if it's a duplicate, sounds that I got filtered first > > time I sent this > > e-mail. > > > > Tx > > Jerome > > > > -----Original Message----- > > From: Moisand, Jerome > > Sent: Wednesday, June 13, 2001 11:19 AM > > To: 'MORAND Pierrick FTRD/DMI/CAE'; IPSEC-POLICY (E-mail); > > RAP (E-mail) > > Subject: RE: COPS-PR security general issues > > > > > > > > I support the concern described by the e-mail quoted below, > > which resonates > > quite well with what I heard from multiple service providers during > > COPS-related discussions. > > > > I would suggest that the topic is discussed during the next > > IETF meeting in > > the context of the "rap" group since the point is essentially > > to secure the > > COPS/COPS-PR interactions, irrespective of the type of policies being > > managed. > > > > In this context, among other alternatives, I would also > > suggest to discuss > > the following internet-draft: > > http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-tls-00.txt > > > > Tx > > Jerome > > > > =========================================== > > Jerome P. Moisand > > Senior Product Manager > > Unisphere Networks > > mailto:jmoisand@UnisphereNetworks.com > > > > > > > > > > -----Original Message----- > > From: MORAND Pierrick FTRD/DMI/CAE > > [mailto:pierrick.morand@rd.francetelecom.fr] > > Sent: Thursday, May 31, 2001 8:08 AM > > To: IPSEC-POLICY (E-mail); RAP (E-mail) > > Cc: NOISETTE Yoann FTRD/DMI/CAE; RABOT Wilfrid FTRD/DMI/CAE > > Subject: COPS-PR security general issues > > > > > > We are currently working on the general theme of provisioning. We are > > considering COPS-PR with attention and would bring to the > > attention of RAP > > and IPSP experts the following remarks and questions with our > > apologizes if > > these issues have already been debated. > > > > In a general way, COPS-PR has been designed to provision configuration > > policies for various functional domains such as IPSec, L2TP, > > MPLS, AAA, > > Routing, TE .... > > > > Considering for instance, IPSec, AAA and L2TP, provisioning of those > > functions leads to exchange with the equipment sensitive > > information such as > > shared secrets (L2TP-Tunnel-password, users password, radius > > secret and so > > on). > > > > Within COPS there is an optional security mechanisms, which > > only guarantees > > the integrity of the COPS messages. There is no general > > mechanisms allowing > > to cipher some particular sensitive fields. > > > > Do these security issues shall conduct an implementer or an > > operator to > > systematically make use of IPSec to secure exchanges between > > a PEP and a PDP > > so that it becomes possible to provision sensitive security > > information > > without having to defined ciphered fields in the PIBs for > > which no generic > > mechanisms have currently been defined ? > > > > If IPSec is used to secure COPS-PR exchanges what would > > become the utility > > of the integrity mechanisms defined within COPS and more > > especially when > > used within COPS-PR ? > > > > Additionally, the IPSec PIB which is currently in its > > definition phase, > > allows to define IKE rules specifying pre-shared key as Ike proposal > > authentication [ipSecIkeProposalAutenticationMethod OBJET-TYPE with > > presharedKey(1) as possible value]method but does not allow > > to provision > > those secrets. This means that the provisioning of those > > secrets shall be > > done by an other way and in that case advantages of COPS-PR in case of > > pre-shared authentication becomes greatly reduced since this shall be > > achieved by hand or using an other mechanism. > > > > In a same way if L2TP or AAA PIBs were to be defined how > > secrets (and more > > generally sensitive information) should be provisioned ? > > -In clear : not reasonable > > -Ciphered : there is no generic mechanisms > > -Protected by IPSec, SSL... : should work fine, but the RFC > > should precise > > that usage of a particular client type, defining sensitive > > information MUST > > make use of an external mechanisms in order to secure those sensitive > > information.. > > > > To conclude it seams that we can have the two possible > > approaches in order > > to allow the exchange of sensible security information > > between a PEP an a > > PDP : > > 1-systematicaly make use of an underlying security layer (IPSec for > > instance) to secure exchanges between PEP and PDP. In that > > case the COPS > > integrity mechanism is no more necessary. This approach > > implies that the PEP > > has to support a security communication layer which might not > > be the case in > > all situation. > > 2-defines a generic COPS ciphering mechanism which allows to > > protect some > > sensitive fields. Security is embedded in the COPS protocol > > and must be > > supported. > > > > If this issue was solved, could IPSP experts extend the PIB > > so that shared > > secret can be exchanged or is the reason for which it is not currently > > supported more fundamental ? > > > > Thanks in advance for your answers and comments. > > > > Pierrick Morand > > france telecom R&D/DMI/SIR/IPI > > Tel : +33 2 31 75 91 79 - Fax : +33 2 31 73 56 26 > > Email :pierrick.morand@francetelecom.com > > > > > > > > From owner-ipsec-policy@mail.vpnc.org Thu Jun 28 13:26:04 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 NAA15107 for ; Thu, 28 Jun 2001 13:26:03 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5SGEws07076 for ipsec-policy-bks; Thu, 28 Jun 2001 09:14:58 -0700 (PDT) Received: from rebma.mikesoffice.com (adsl-63-195-146-66.dsl.scrm01.pacbell.net [63.195.146.66]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5SGEvm07068 for ; Thu, 28 Jun 2001 09:14:57 -0700 (PDT) Received: (from baerm@localhost) by rebma.mikesoffice.com (8.9.3/8.9.3) id JAA18355; Thu, 28 Jun 2001 09:16:06 -0700 X-Authentication-Warning: rebma.mikesoffice.com: baerm set sender to baerm@mikesoffice.com using -f To: Eric Vyncke Cc: ipsec-policy@vpnc.org Subject: Re: more ipsp-config-policy-mode-02 Q's/comments References: <4.3.2.7.2.20010628142730.0c399ee8@brussels.cisco.com> From: Michael Baer Organization: NAI Labs Date: 28 Jun 2001 09:16:06 -0700 In-Reply-To: <4.3.2.7.2.20010628142730.0c399ee8@brussels.cisco.com> (Eric Vyncke's message of "Thu, 28 Jun 2001 14:32:08 +0200") Message-ID: <86ae2s8trt.fsf@rebma.mikesoffice.com> Lines: 37 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric> Michael, Some comments: Eric> 1) the DoActionLogging controls whether a single log event Eric> is Eric> generated (either upon success or failure). If I understood Eric> correctly your proposal, at least two log events would be Eric> generated: one when starting/attempting the action and another one Eric> upon success or failure. While I do see benefits in your proposal, Eric> I wonder whether it is really useful. No, that's not quite what I meant. I'm not proposing adding more logging events. I don't think I'm actually proposing changing the intended meaning of DoActionLogging at all, just re-wording the description to make the meaning clearer. The description of DoActionLogging in the 02 draft is to log 'when an action is performed'. But in my understanding of the IPsec RFC 2401, an action could be either routing through an existing SA or attempting SA creation. (Although some implementations may always have the action be SA creation). So if you logged 'when the action is performed' and that action was to route to an existing SA, DoActionLogging and DoPacketLogging would be redundant. I don't think this is the intended meaning of DoActionLogging though. In order to make it more explicit, I'm suggesting changing the wording in the description of DoActionLogging from 'when an action is performed' to something like, ' when an attempt is made to establish the SA', which I think is what is really meant by DoActionLogging. Hope I was clearer Mike -- Michael Baer baerm@mikesoffice.com NAI Labs From owner-ipsec-policy@mail.vpnc.org Fri Jun 29 01:46:15 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 BAA10383 for ; Fri, 29 Jun 2001 01:46:13 -0400 (EDT) Received: by above.proper.com (8.11.3/8.11.3) id f5T4NiU05461 for ipsec-policy-bks; Thu, 28 Jun 2001 21:23:44 -0700 (PDT) Received: from smtp5.uk1.bibliotech.net (smtp5.uk1.bibliotech.net [212.57.34.104]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5T4Ngm05457 for ; Thu, 28 Jun 2001 21:23:43 -0700 (PDT) Received: from pmweb5.uk1.bibliotech.net (pmweb5.uk1.bibliotech.net [212.57.34.100]) by smtp5.uk1.bibliotech.net (8.9.3/8.9.3) with ESMTP id FAA24366 for ; Fri, 29 Jun 2001 05:23:40 +0100 Received: (from pmweb@localhost) by pmweb5.uk1.bibliotech.net (8.9.3/8.9.3) id FAA22831; Fri, 29 Jun 2001 05:23:40 +0100 Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 X-Mailer: MIME-tools 4.104 (Entity 4.117) From: "Amey Gokhale" Subject: Placement of IKE To: ipsec-policy@vpnc.org Date: Fri, 29 Jun 2001 05:23:40 +0100 X-Postmaster: Sent from Postmaster http://www.postmaster.co.uk/, the world's premier free web-based email service, based in London, England. X-Postmaster-Trace: Account name: agokhale; Local time: Fri Jun 29 05:23:40 2001; Local host: pmweb5.uk1.bibliotech.net; Remote host: 202.54.40.40; Referer site: www.postmaster.co.uk X-Complaints-To: Administrator@postmaster.co.uk Message-Id: Sender: owner-ipsec-policy@mail.vpnc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello all, I am working on developing a VPN gateway. It;s in the design phase. Most of the products which i studied are having IKE engine in the user space. Being in the detailed design phase, i want to know the reasons of placing IKE engine in the user space as i don;t want to blindly follow what other products are giving. I will be using only one authentication method for IKE SA establishment i.e. Pre-shared Keys. So I am thinking of putting IKE in kernel space. As considerable time will be spent between communication of IKE engine if placed in user space and kernel space IPSEC engine. So can anyone throw some light on it?? waiting for ur replies. Thanks in advance Amey.