From list@netscape.com Wed Mar 1 00:11:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11641 for ; Wed, 1 Mar 2000 00:11:26 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA04537; Tue, 29 Feb 2000 21:08:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id VAA06520; Tue, 29 Feb 2000 21:10:04 -0800 (PST) Resent-Date: Tue, 29 Feb 2000 21:10:04 -0800 (PST) X-Lotus-FromDomain: TCSDELHI From: "Girish Ahuja" To: ietf-ldapext@netscape.com Message-ID: <65256895.001C640D.00@MAILGB.delhi.tcs.co.in> Date: Wed, 1 Mar 2000 10:40:07 +0530 Subject: Sendmail & LDAP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"W42QL.A.clB.qYKv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Hi, I want to send mails to all users enlisted in LDAP server(Netscape Directory Server) using Sendmail. Can you please mail me some details how do I integrate these two? rgds, Girish Ahuja, System Administrator, TCS-GB --------------------------------------------------------------------------- "This email message and files transmitted with it are confidential, proprietary and legally privileged. If the message that is received is an error, or if there is any mistransmission, the originator must be notified immediately as the unauthorized use, dissemination, publication, transfer or any other use of the message by unauthorized person is strictly forbidden by law and prohibited. If anybody commits violation then he would be legally liable and punishable under the relevant law. The intended recipient can be rest assured that the confidentiality and privilege is not waived or lost by any such mistransmission. Internet communications are not secure unless it is protected by using strong cryptography. TCS does not accept any responsibility whatsoever for changes in the nature of modifications, additions, deletions made to the message once it is sent. TCS reserves the right to monitor all e-mail communications through its network." --------------------------------------------------------------------------- Tata Consultancy Services www.tcs.com From list@netscape.com Wed Mar 1 06:33:43 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28080 for ; Wed, 1 Mar 2000 06:33:42 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA27598; Wed, 1 Mar 2000 03:30:21 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA28571; Wed, 1 Mar 2000 03:32:28 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 03:32:28 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 01 Mar 2000 04:31:54 -0700 From: "Natarajan SK" To: Cc: "Savitha R" Subject: Changelog entries draft. Do not seem to find it. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"wceUwB.A.H-G.L_Pv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA28080 Hi , The draft-ietf-ldup-replica-req-02.txt ( LDAP V3 Replication Requirements ) draft specifies as a reference : [Changelog] Gordon Good, "Definitions of an Object Class to Hold LDAP Change records", Internet Draft, draft-ietf-asid-changelog- 00.txt, November 1996. I do not seem to find the draft anywhere. Could anyone help? Also is there any written material on LDAP changelogs otherwise? Aprpeciate anybody who can help. Regards, Natarajan S.K.Natarajan Senior Software Engineer Novell Software, Bangalore E-mail sknatarajan@novell.com Ph. no. 91-80-572-1856/58 Extn. 2213 Fx 91-80-572-1870 From list@netscape.com Wed Mar 1 09:07:19 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01892 for ; Wed, 1 Mar 2000 09:07:19 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA07164; Wed, 1 Mar 2000 06:04:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA23000; Wed, 1 Mar 2000 06:06:07 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 06:06:07 -0800 (PST) Sender: vinnie@oasis.ireland.Sun.COM Message-ID: <38BD22C7.257043B3@Ireland.Sun.COM> Date: Wed, 01 Mar 2000 14:01:43 +0000 From: Vincent Ryan Organization: Sun Microsystems X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ldap@umich.edu, ietf-ldapext@netscape.com Subject: The correct behaviour of auxiliary object classes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9rFedD.A.GnF.PPSv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I'm seeking clarification of how auxiliary object classes are supposed to operate. My understanding of auxiliary object classes is that they are designed to be mixed-in with structural object classes when particular instances of a structural object class need additional attributes. For example, 'strongAuthenticationUser' is an auxiliary class defined in RFC 2256 and it mandates the 'userCertificate' attribute. If I want to create an LDAP entry that is both an 'organizationalPerson' and a 'strongAuthenticationUser' then I should specify both class names in the object class attribute for the entry. In addition, as 'sn' is mandatory for the 'organizationalPerson' class and 'userCertificate' is mandatory for the 'strongAuthenticationUser' class then I must supply both of these attributes too. Is my understanding correct? Should this behaviour be stated explicitly in the LDAP RFCs? I notice that support for auxiliary classes in Windows 2000 Active Directory deviates from this behaviour. Auxiliary classes are (permanently) associated with specific structural classes in the Active Directory schema. The effect is that every instance of a structural class must contain the mandatory attributes of all of its associated auxiliary classes. That is, the auxiliary class is associated with every instance of the structural class. In addition, auxiliary class names must not appear as values of the object class attribute of the instance of the structural class. Can someone from Microsoft confirm that my description is correct? (Or have I misunderstood how Active Directory operates.) Do other LDAP server implementors support auxiliary classes differently? From list@netscape.com Wed Mar 1 11:07:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06276 for ; Wed, 1 Mar 2000 11:07:13 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA18058; Wed, 1 Mar 2000 08:01:49 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA21061; Wed, 1 Mar 2000 08:05:55 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 08:05:55 -0800 (PST) Date: Wed, 01 Mar 2000 10:05:01 -0600 From: Mark Wahl Subject: Re: The correct behaviour of auxiliary object classes In-reply-to: "Your message of Wed, 01 Mar 2000 14:01:43 GMT." <38BD22C7.257043B3@Ireland.Sun.COM> Sender: Mark.Wahl@INNOSOFT.COM To: Vincent Ryan Cc: ldap@umich.edu, ietf-ldapext@netscape.com Message-id: <13781.951926701@threadgill.austin.innosoft.com> MIME-version: 1.0 X-Mailer: exmh version 2.0.2 2/24/98 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"uJL_kC.A.zIF.i_Tv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > Is my understanding correct? Yes. The LDAPv3 information and operations model is defined by the following MUST statement of RFC 2251 section 3.3. 3.3. Relationship to X.500 This document defines LDAP in terms of X.500 as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500(1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface. > I notice that support for auxiliary classes in Windows 2000 > Active Directory deviates from this behaviour. Auxiliary classes > are (permanently) associated with specific structural classes in > the Active Directory schema. That sounds more like a content rule than an auxiliary class. Content rules also provide additional attributes to entries, and they are associated with structural classes. Content rules don't show up in the objectClass attribute, however. > Do other LDAP server implementors support auxiliary classes differently? At least three LDAPv3 servers implement auxiliary classes as required by RFC 2251. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Wed Mar 1 13:07:27 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09615 for ; Wed, 1 Mar 2000 13:07:26 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA06345; Wed, 1 Mar 2000 10:03:42 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA06862; Wed, 1 Mar 2000 10:05:49 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 10:05:49 -0800 (PST) Message-ID: <38BD5BA9.57715393@netscape.com> Date: Wed, 01 Mar 2000 10:04:25 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Natarajan SK CC: ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"7VEgsD.A.8qB.8vVv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit The changelog draft has expired. I believe that the reference to the changelog draft should be removed from the LDUP requirements document. The reference is made in passing, and (incorrectly) implies that the changelog draft is part of the core LDAP specifications (which it is not). Quoting from draft-ietf-ldup-replica-req-02.txt: "Currently LDAP does not define a replication mechanism and only generally mentions LDAP shadow servers (see [RFC2251] and [Changelog]) in passing. The requirements for replication are critical to the successful deployment and acceptance of LDAP in the market place." Removing the reference to [Changelog] would allow the replication requirements draft to proceed without any dependency on the changelog draft. While I'm happy to resurrect the changelog draft and discuss publishing it as a standards-track document (informational, probably), it's not going to be a part of the LDUP specification. -Gordon Natarajan SK wrote: > Hi , > The draft-ietf-ldup-replica-req-02.txt ( LDAP V3 Replication Requirements ) > draft specifies as a reference : > > [Changelog] Gordon Good, "Definitions of an Object Class to Hold > LDAP Change records", Internet Draft, draft-ietf-asid-changelog- > 00.txt, November 1996. > > I do not seem to find the draft anywhere. Could anyone help? Also is there any written material on LDAP changelogs otherwise? > > Aprpeciate anybody who can help. > > Regards, > Natarajan > > S.K.Natarajan > Senior Software Engineer > Novell Software, Bangalore > E-mail sknatarajan@novell.com > Ph. no. 91-80-572-1856/58 Extn. 2213 > Fx 91-80-572-1870 From list@netscape.com Wed Mar 1 13:31:27 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10065 for ; Wed, 1 Mar 2000 13:31:27 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA04374; Wed, 1 Mar 2000 10:25:53 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA16253; Wed, 1 Mar 2000 10:30:03 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 10:30:03 -0800 (PST) Message-Id: <3.0.5.32.20000301102956.0093fea0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 01 Mar 2000 10:29:56 -0800 To: ggood@netscape.com (Gordon Good) From: "Kurt D. Zeilenga" Subject: Re: Changelog entries draft. Do not seem to find it. Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org In-Reply-To: <38BD5BA9.57715393@netscape.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"QqF-GB.A.L9D.qGWv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:04 AM 3/1/00 -0800, Gordon Good wrote: >While I'm happy to resurrect the changelog draft and discuss publishing it as a standards-track document (informational, >probably), it's not going to be a part of the LDUP specification. I would support publication of the Changelog draft as an Informational RFC as it would document existing practices. The document would have to be amended, of course, to contain appropriate statements concerning IETF work in this area. Kurt From list@netscape.com Wed Mar 1 17:06:22 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14421 for ; Wed, 1 Mar 2000 17:06:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA15829; Wed, 1 Mar 2000 14:03:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA17214; Wed, 1 Mar 2000 14:05:13 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 14:05:13 -0800 (PST) Message-ID: <38BD944B.6E26C1BC@att.com> Date: Wed, 01 Mar 2000 17:06:03 -0500 From: Chris Apple Organization: AT&T Labs X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Gordon Good Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: <38BD5BA9.57715393@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"230DuC.A.xLE.WQZv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Lets just remove it. Chris. Gordon Good wrote: > > The changelog draft has expired. > > I believe that the reference to the changelog draft should be removed from the LDUP requirements document. The reference is made > in passing, and (incorrectly) implies that the changelog draft is part of the core LDAP specifications (which it is not). Quoting > from draft-ietf-ldup-replica-req-02.txt: > > "Currently LDAP does > not define a replication mechanism and only generally mentions LDAP > shadow servers (see [RFC2251] and [Changelog]) in passing. The > requirements for replication are critical to the successful > deployment and acceptance of LDAP in the market place." > > Removing the reference to [Changelog] would allow the replication requirements draft to proceed without any dependency on the > changelog draft. > > While I'm happy to resurrect the changelog draft and discuss publishing it as a standards-track document (informational, > probably), it's not going to be a part of the LDUP specification. > > -Gordon > > Natarajan SK wrote: > > > Hi , > > The draft-ietf-ldup-replica-req-02.txt ( LDAP V3 Replication Requirements ) > > draft specifies as a reference : > > > > [Changelog] Gordon Good, "Definitions of an Object Class to Hold > > LDAP Change records", Internet Draft, draft-ietf-asid-changelog- > > 00.txt, November 1996. > > > > I do not seem to find the draft anywhere. Could anyone help? Also is there any written material on LDAP changelogs otherwise? > > > > Aprpeciate anybody who can help. > > > > Regards, > > Natarajan > > > > S.K.Natarajan > > Senior Software Engineer > > Novell Software, Bangalore > > E-mail sknatarajan@novell.com > > Ph. no. 91-80-572-1856/58 Extn. 2213 > > Fx 91-80-572-1870 -- ------------------------------------------------------------------------ Chris Apple Business Site: AnyWho Directory Service Internet Directory Group http://www.anywho.com AT&T Labs capple@control.att.com +1 973 236 6470 Tired of slow directories? Try AnyWho. ------------------------------------------------------------------------ From list@netscape.com Wed Mar 1 19:01:02 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18172 for ; Wed, 1 Mar 2000 19:01:01 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA18045; Wed, 1 Mar 2000 15:55:33 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA04928; Wed, 1 Mar 2000 15:59:32 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 15:59:32 -0800 (PST) Message-Id: <3.0.5.32.20000301155246.0085e5e0@popd.netcom.ca> X-Sender: erikskov@popd.netcom.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 01 Mar 2000 15:52:46 -0800 To: Vincent Ryan , ldap@umich.edu, ietf-ldapext@netscape.com From: Erik Skovgaard Subject: Re: [ldap] The correct behaviour of auxiliary object classes In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"Bvenz.A.uMB.j7av4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Vincent, Auxiliary Object Classes are particularly useful where you want to add attributes to several types of Structural Object Classes. See also below. At 14:01 2000-03-01 +0000, Vincent Ryan wrote: > >I'm seeking clarification of how auxiliary object classes are >supposed to operate. My understanding of auxiliary object classes >is that they are designed to be mixed-in with structural object >classes when particular instances of a structural object class >need additional attributes. > >For example, 'strongAuthenticationUser' is an auxiliary class >defined in RFC 2256 and it mandates the 'userCertificate' attribute. >If I want to create an LDAP entry that is both an 'organizationalPerson' >and a 'strongAuthenticationUser' then I should specify both class >names in the object class attribute for the entry. In addition, >as 'sn' is mandatory for the 'organizationalPerson' class and >'userCertificate' is mandatory for the 'strongAuthenticationUser' >class then I must supply both of these attributes too. > >Is my understanding correct? Yes, you are right. In addition, an Auxiliary Object Class cannot be instantiated without a Structural Object Class. > >Should this behaviour be stated explicitly in the LDAP RFCs? Perhaps, but you could argue that lots of things should. The base documents are referenced. > >I notice that support for auxiliary classes in Windows 2000 >Active Directory deviates from this behaviour. Auxiliary classes >are (permanently) associated with specific structural classes in >the Active Directory schema. The effect is that every instance of >a structural class must contain the mandatory attributes of all >of its associated auxiliary classes. That is, the auxiliary class >is associated with every instance of the structural class. In >addition, auxiliary class names must not appear as values of the >object class attribute of the instance of the structural class. > >Can someone from Microsoft confirm that my description is correct? >(Or have I misunderstood how Active Directory operates.) > >Do other LDAP server implementors support auxiliary classes differently? Some do not implement them at all. Cheers, ....Erik. -------------------------------------- Erik Skovgaard Global Knowledge Enterprise Directory Group > >--- >You are currently subscribed to ldap@umich.edu as: [eskovgaard@geotrain.com] >To unsubscribe send email to ldap-request@umich.edu with the word UNSUBSCRIBE as the SUBJECT of the message. > > From list@netscape.com Wed Mar 1 19:20:57 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18644 for ; Wed, 1 Mar 2000 19:20:56 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA20489; Wed, 1 Mar 2000 16:14:56 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA14249; Wed, 1 Mar 2000 16:18:54 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 16:18:54 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 01 Mar 2000 17:18:07 -0700 From: "Steve Trottier" To: , Cc: , "Richard Ellis" , Subject: Re: (c.harding 38467) bug in blits Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"ErECZC.A.MeD.tNbv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA18644 I'm sorry. I was behind in my email and just read this exchange. I would agree with Vincent. IF the base DN of the search exists but nothing matches the filter, then success with zero entries returned is correct. However, if the base DN for the search doesn't exist, then the server should return "noSuchObject". >>> Vincent Ryan 02/04/00 08:26AM >>> The tests listed below all attempt to perform a search at a non-existent entry. It is correct to expect a noSuchObject error to be returned. Admittedly, the Procedure clause in each of the test specifications is a little misleading and could be replaced with: Submit a {subtree | single-level | base-level} search request where the base object does not exist. Chris Harding wrote: > > Hi - > > It seems a bit surprising that this hasn't come up before. Should we change > BLITS as suggested? > > >From: Christopher Oliva > >To: "'capple@att.com'" , > > "'c.harding@opengroup.org'" > > , > > "'ludovic.poitou@france.sun.com'" > > > >Subject: (c.harding 38467) bug in blits > >Date: Thu, 3 Feb 2000 14:26:36 -0500 > >X-Mailer: Internet Mail Service (5.5.2650.21) > >Comments: (c.harding 38467) > > > >Hi, > > > >I have a bug report for the following tests in the BLITS suite: > > > >3.3.2.9.2 > >3.3.2.9.3 > >3.3.2.9.4 > > > >They are testing the ldap server response to a search where no entries match > >the search filter. They require the "noSuchObject" error to be returned. In > >reality, this is not correct. I can tell you that from working with many > >(commercial release) directory products that none of them return this error. > >The correct response from the server is a "success" code with no matching > >search result entries i.e. there will be no matches and the search completes > >successfully. > > > >The reason is in X.500. Clause 10.2.3 of X.511 (1997) says this: > > > >The search request succeeds if the baseObject is located, regardless of > >whether there are any subordinates to return. > > > >Furthermore, noSuchObject is defined as follows in clause 12 of X.511: > > > >noSuchObject - The name supplied does not match the name of any object > > > >Applied to the search operation, this means the base object parameter of the > >search (if it cannot be located) will result in this error. > > > >This is substantiated by the description of how an LDAPResult is constructed > >in RFC 2251 4.1.10. > > > >As a result of this, I think the BLITS test should be changed. I think some > >directory implementations may code the incorrect behaviour into their > >products unless this is changed. > > > >Please let me know what you think. > > > >Chris. > > > > > > > > Regards, > > Chris > +++++ > > ------------------------------------------------------------------------- > Chris Harding > T H E Directory Program Manager > O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK > G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 > WWW: http://www.opengroup.org Fx: +44 118 950 0110 > > OSF/1, Motif, UNIX and the "X" device are registered trademarks in > the US and other countries, and IT DialTone and The Open Group are > trademarks of The Open Group. > ------------------------------------------------------------------------- From list@netscape.com Wed Mar 1 19:46:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19243 for ; Wed, 1 Mar 2000 19:46:38 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA10415; Wed, 1 Mar 2000 16:43:17 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA23820; Wed, 1 Mar 2000 16:45:24 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 16:45:24 -0800 (PST) From: rwVVK2NYg@compuserve.com DATE: 01 Mar 00 6:45:27 PM Message-ID: SUBJECT: Start Taking Credit Cards Resent-Message-ID: <"hpPwm.A.6yF.hmbv4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Merchant Status will help you increase sales by an Average 30%. Stop losing valuable sales! The increase for internet transactions is 75% up to an incredible 400%!!! Easily accept major credit cards right away! We specialize in Secure Internet Transactions! ******Act now and all App. & Processing fees waived***** Call our (888) 363-7881 now! Our courteous customer care reps. are anxious to help you get your merchant account today. With one phone call you can be: Accepting all major credit cards! Accepting checks over the net or by Fax! Accepting real time processing for member sites! Gaining customer loyalty and trust! Close the sale now. No more wondering if "The check is in the mail" We specialize in helping those entrepreneurs who are just starting out: no credit, poor credit, or even if you have great credit. Almost everyone is approved! For the next 5 days we will waive all app. and processing fees! (other companies charge $200 to $500 to set up) Call us today @ 1 (888) 363-7881 and ask for extension RGS for your free setup! Since 1992!! ************************************************************* To be removed from our list mailto: PDavis@unbounded.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTE: DON'T COMPLAIN TO UNBOUNDED.COM, AS THE ACCOUNT WILL BE SHUT DOWN, AND WE WILL NOT BE ABLE TO REMOVE YOU FROM OUR LIST. WE DON'T WANT TO MAIL THOSE WHO DO NOT WANT US TO. ************************************************************* From list@netscape.com Wed Mar 1 21:48:30 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21382 for ; Wed, 1 Mar 2000 21:48:30 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA11114; Wed, 1 Mar 2000 18:43:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA03752; Wed, 1 Mar 2000 18:47:25 -0800 (PST) Resent-Date: Wed, 1 Mar 2000 18:47:25 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 01 Mar 2000 19:47:10 -0700 From: "Brian Jarvis" To: , , Subject: Re: The correct behaviour of auxiliary object classes Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_124B9A29.27464D5B" Resent-Message-ID: <"J_xQx.A.W6.8Ydv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_124B9A29.27464D5B Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Your understanding is correct. To add an auxiliary class to an object you = add it to Object Class and simultaneously add any mandatory attributes it = has. To remove an auxiliary class from an object, you delete it from = Object Class. I don't think we need to specify this behavior every place that defines an = auxiliary class. One place will be less confusing since the specifications= invariably would differ. >>> Vincent Ryan 3/1/2000 07:06:26 >>> I'm seeking clarification of how auxiliary object classes are supposed to operate. My understanding of auxiliary object classes is that they are designed to be mixed-in with structural object classes when particular instances of a structural object class need additional attributes.=20 For example, 'strongAuthenticationUser' is an auxiliary class defined in RFC 2256 and it mandates the 'userCertificate' attribute. If I want to create an LDAP entry that is both an 'organizationalPerson' and a 'strongAuthenticationUser' then I should specify both class names in the object class attribute for the entry. In addition, as 'sn' is mandatory for the 'organizationalPerson' class and 'userCertificate' is mandatory for the 'strongAuthenticationUser' class then I must supply both of these attributes too. Is my understanding correct?=20 Should this behaviour be stated explicitly in the LDAP RFCs? I notice that support for auxiliary classes in Windows 2000 Active Directory deviates from this behaviour. Auxiliary classes are (permanently) associated with specific structural classes in the Active Directory schema. The effect is that every instance of a structural class must contain the mandatory attributes of all of its associated auxiliary classes. That is, the auxiliary class is associated with every instance of the structural class. In addition, auxiliary class names must not appear as values of the object class attribute of the instance of the structural class. Can someone from Microsoft confirm that my description is correct? (Or have I misunderstood how Active Directory operates.) Do other LDAP server implementors support auxiliary classes differently? --=_124B9A29.27464D5B Content-Type: text/plain Content-Disposition: attachment; filename="Brian Jarvis.vcf" BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:Brian Jarvis - Novell TEL;WORK:801-861-3856 ORG:;NDS Administration TEL;PREF;FAX:801-861-2292 EMAIL;WORK;PREF;NGW:BJARVIS@novell.com N:Jarvis;Brian TITLE:Software Engineer Senior X-GWUSERID:BJARVIS END:VCARD --=_124B9A29.27464D5B-- From list@netscape.com Thu Mar 2 08:39:18 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12180 for ; Thu, 2 Mar 2000 08:39:17 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id FAA01124; Thu, 2 Mar 2000 05:35:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA27596; Thu, 2 Mar 2000 05:37:15 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 05:37:15 -0800 (PST) Message-ID: <438D12915E64D2118AB10000F8C1C07802734093@zcard00e.ca.nortel.com> From: "James Benedict" To: "Kurt D. Zeilenga" , ggood@netscape.com Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 08:32:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF844B.C324378C" Resent-Message-ID: <"qjuyMD.A.6uG.K6mv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF844B.C324378C Content-Type: text/plain; charset="ISO-8859-1" Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > ------_=_NextPart_001_01BF844B.C324378C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Changelog entries draft. Do not seem to find it.

Changelogs seem to be falling between the cracks = (LDAP, LDUP,
LCUP?).  The concept of changelogs is important = to replication, but it also has many other uses.

Accountability (Who did what? When?)
Problem Tracking (Why is my email address X)
Recovery (Whoops, I didn't really want to rename = everyone in my directory)
Client-side caching (Give me all the changes to a = subtree)

If LDUP is going to subsume the role of maintaining = changes for replication
purposes, then I think it is important to make sure = that mechanisms are
in place to deal with these other uses as = well.  Otherwise, I think
changelogs should become part of the LDAP standard, = not just informational.

It doesn't really matter how the directory server = maintains this information, but clients need to have a consistent way = of accessing it.

James A Benedict
Advisor, IP Directory Systems Architecture
Preside Policy Services
NORTEL NETWORKS
Ph:  (613) 763-3909


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, March 01, 2000 1:30 PM
> To: ggood@netscape.com
> Cc: Natarajan SK; ietf-ldapext@netscape.com; = Savitha R;
> ietf-ldup@imc.org
> Subject: Re: Changelog entries draft. Do not = seem to find it.
>
>
> At 10:04 AM 3/1/00 -0800, Gordon Good = wrote:
> >While I'm happy to resurrect the changelog = draft and discuss
> publishing it as a standards-track document = (informational,
> >probably), it's not going to be a part = of  the LDUP specification.
>
> I would support publication of the Changelog = draft as an
> Informational RFC as it would document existing = practices.
> The document would have to be amended, of = course, to contain
> appropriate statements concerning IETF work in = this area.
>
> Kurt
>

------_=_NextPart_001_01BF844B.C324378C-- From list@netscape.com Thu Mar 2 09:14:10 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13304 for ; Thu, 2 Mar 2000 09:14:10 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA17738; Thu, 2 Mar 2000 06:08:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA05859; Thu, 2 Mar 2000 06:12:54 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 06:12:54 -0800 (PST) From: "Howard Chu" To: "James Benedict" , "Kurt D. Zeilenga" , Cc: "Natarajan SK" , , "Savitha R" , Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 06:14:31 -0800 Message-ID: <000201bf8451$a0e2d1a0$0c01a8c0@fiddle.symas.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01BF840E.92BF91A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <438D12915E64D2118AB10000F8C1C07802734093@zcard00e.ca.nortel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Resent-Message-ID: <"NvXc-D.A.RbB.mbnv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. ------=_NextPart_000_0003_01BF840E.92BF91A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Changelog entries draft. Do not seem to find it.The ChangeLog spec isn't sufficient for "Accountability" purposes. It isn't flexible enough to provide a full audit of all operations; since it only records successful changes it doesn't address binds, searches, compares, etc... It doesn't record who did an operation. The changeNumber mechanism is problematic. I started talking to Gordon about using it for these purposes, but after he pointed out its limitations I decided to let it drop. I came up with something similar for our own audit log purposes. If you're interested, here's a quick summary: requestId: ; requestUser: the bindDN that was in effect, or "(anonymous)" requestDn: the DN of interest to the operation, if any requestType: add/bind/compare/delete/etc... requestResult: numeric result code [, number of results returned by search] requestParameters: free format field. For a typical search, this could contain e.g. scope: 2 filter: (objectclass=*) attrs: objectclass attrs: cn The requestParameters attribute gets treated as a binary object... I have auditing configured both globally and on a per-subtree (slapd backend) basis, with "audit (none|mod|all)" - "audit mod" is essentially just a changelog, "audit all" adds bind, compare, search, and unbind. (Sorry, y'all probably aren't interested in implementation details here, but it seemed like a simple example was warranted.) -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc -----Original Message----- From: James Benedict [mailto:grunt@nortelnetworks.com] Sent: Thursday, March 02, 2000 5:32 AM To: Kurt D. Zeilenga; ggood@netscape.com Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > ------=_NextPart_000_0003_01BF840E.92BF91A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Changelog entries draft. Do not seem to find = it.
The=20 ChangeLog spec isn't sufficient for "Accountability" purposes. It isn't = flexible=20 enough to provide a full audit of all operations; since it only records=20 successful changes it doesn't address binds, searches, compares, etc... = It=20 doesn't record who did an operation. The changeNumber mechanism is = problematic.=20 I started talking to Gordon about using it for these purposes, but after = he=20 pointed out its limitations I decided to let it drop. I came up with = something=20 similar for our own audit log purposes.
 
If=20 you're interested, here's a quick summary:
 =20 requestId: <timestamp>;<sequence number>
 =20 requestUser: the bindDN that was in effect, or = "(anonymous)"
 =20 requestDn: the DN of interest to the operation, if = any
 =20 requestType: add/bind/compare/delete/etc...
 =20 requestResult: numeric result code [, number of results returned by=20 search]
 =20 requestParameters: free format field. For a typical search, this could = contain=20 e.g.
     scope: = 2
     filter:=20 (objectclass=3D*)
     attrs:=20 objectclass
     attrs: = cn
The=20 requestParameters attribute gets treated as a binary=20 object...
 
I have=20 auditing configured both globally and on a per-subtree (slapd backend) = basis,=20 with "audit (none|mod|all)" - "audit mod" is essentially just a = changelog,=20 "audit all" adds bind, compare, search, and unbind. (Sorry, y'all = probably=20 aren't interested in implementation details here, but it seemed like a = simple=20 example was warranted.)

  -- Howard Chu
  Chief Architect, Symas=20 Corp.       Director, Highland = Sun
  http://www.symas.com     &nb= sp;        =20 http://highlandsun.com/hyc

 
-----Original Message-----
From: James Benedict=20 [mailto:grunt@nortelnetworks.com]
Sent: Thursday, March 02, = 2000=20 5:32 AM
To: Kurt D. Zeilenga; = ggood@netscape.com
Cc:=20 Natarajan SK; ietf-ldapext@netscape.com; Savitha R;=20 ietf-ldup@imc.org
Subject: RE: Changelog entries draft. Do = not seem=20 to find it.

Changelogs seem to be falling between the cracks = (LDAP, LDUP,=20
LCUP?).  The concept of changelogs is = important=20 to replication, but it also has many other uses.

Accountability (Who did what? When?) =
Problem Tracking (Why is my email address X)
Recovery (Whoops, I didn't really want to rename everyone in = my=20 directory)
Client-side caching (Give me all = the=20 changes to a subtree)

If LDUP is going to subsume the role of maintaining = changes=20 for replication
purposes, then I think it is = important=20 to make sure that mechanisms are
in place to = deal with=20 these other uses as well.  Otherwise, I think
changelogs should become part of the LDAP standard, not just=20 informational.

It doesn't really matter how the directory server = maintains=20 this information, but clients need to have a consistent way of = accessing=20 it.

James A Benedict
Advisor, = IP Directory=20 Systems Architecture
Preside Policy = Services=20
NORTEL NETWORKS
Ph:  = (613)=20 763-3909


> -----Original Message-----
>=20 From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] =
> Sent: Wednesday, March 01, 2000 1:30 PM
> To: ggood@netscape.com
> = Cc: Natarajan=20 SK; ietf-ldapext@netscape.com; Savitha R;
>=20 ietf-ldup@imc.org
> Subject: Re: = Changelog entries=20 draft. Do not seem to find it.
> =
>
> At 10:04 AM 3/1/00 -0800, = Gordon Good=20 wrote:
> >While I'm happy to resurrect = the=20 changelog draft and discuss
> publishing = it as a=20 standards-track document (informational,
>=20 >probably), it's not going to be a part of  the LDUP=20 specification.
>
> I=20 would support publication of the Changelog draft as an =
> Informational RFC as it would document existing = practices.=20
> The document would have to be amended, of = course, to=20 contain
> appropriate statements = concerning IETF=20 work in this area.
>
>=20 Kurt
> =

------=_NextPart_000_0003_01BF840E.92BF91A0-- From list@netscape.com Thu Mar 2 10:32:39 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15163 for ; Thu, 2 Mar 2000 10:32:37 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA24632; Thu, 2 Mar 2000 07:27:18 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA24844; Thu, 2 Mar 2000 07:31:29 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 07:31:29 -0800 (PST) Date: Thu, 02 Mar 2000 07:55:37 -0700 From: Linda Grimaldi Subject: RE: Changelog entries draft. Do not seem to find it. To: "'James Benedict'" , "Kurt D. Zeilenga" , "ggood@netscape.com" Cc: Natarajan SK , "ietf-ldapext@netscape.com" , Savitha R , "ietf-ldup@imc.org" Message-id: <01BF841C.B3228D40@csp06121.mcit.com> MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Resent-Message-ID: <"AMLr0B.A.6DG.Qlov4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA15163 Just one note on changelog standardization. I recently wrote a program to monitor change logs for audit purposes. It worked great on Innosoft- I had to re-write chunks of it for Netscape. I was quite pissed off, and cursed both the IETF and the LDAP working group for about a week (fortunately, to no effect). Mr. Benedict makes a good point about using the logs for other purposes. From a developer's perspective, I would really appreciate some consistency here. Linda -----Original Message----- From: James Benedict [SMTP:grunt@nortelnetworks.com] Sent: Thursday, March 02, 2000 6:32 AM To: Kurt D. Zeilenga; ggood@netscape.com Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > << File: ATT00002.htm >> From list@netscape.com Thu Mar 2 12:28:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19756 for ; Thu, 2 Mar 2000 12:28:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA00490; Thu, 2 Mar 2000 09:24:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA08443; Thu, 2 Mar 2000 09:26:56 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 09:26:56 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 02 Mar 2000 10:26:43 -0700 From: "Jim Sermersheim" To: , , Cc: , , "Savitha R" , "Natarajan SK" Subject: RE: Changelog entries draft. Do not seem to find it. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"PGD40B.A.pDC.gRqv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19756 LDUP/LCUP should include include enough functionality to achieve a client-side cache. For the other three issues you mention, maybe someone should author an audit draft. Jim >>> "James Benedict" 3/2/00 6:38:35 AM >>> Changelogs seem to be falling between the cracks (LDAP, LDUP, LCUP?). The concept of changelogs is important to replication, but it also has many other uses. Accountability (Who did what? When?) Problem Tracking (Why is my email address X) Recovery (Whoops, I didn't really want to rename everyone in my directory) Client-side caching (Give me all the changes to a subtree) If LDUP is going to subsume the role of maintaining changes for replication purposes, then I think it is important to make sure that mechanisms are in place to deal with these other uses as well. Otherwise, I think changelogs should become part of the LDAP standard, not just informational. It doesn't really matter how the directory server maintains this information, but clients need to have a consistent way of accessing it. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Wednesday, March 01, 2000 1:30 PM > To: ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > >While I'm happy to resurrect the changelog draft and discuss > publishing it as a standards-track document (informational, > >probably), it's not going to be a part of the LDUP specification. > > I would support publication of the Changelog draft as an > Informational RFC as it would document existing practices. > The document would have to be amended, of course, to contain > appropriate statements concerning IETF work in this area. > > Kurt > From list@netscape.com Thu Mar 2 13:24:57 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21960 for ; Thu, 2 Mar 2000 13:24:55 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA09438; Thu, 2 Mar 2000 10:21:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA02272; Thu, 2 Mar 2000 10:23:40 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 10:23:40 -0800 (PST) Sender: vinnie@oasis.ireland.Sun.COM Message-ID: <38BEB099.4FD134C2@Ireland.Sun.COM> Date: Thu, 02 Mar 2000 18:19:05 +0000 From: Vincent Ryan Organization: Sun Microsystems X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: LDAP list , ietf-ldapext@netscape.com Subject: Digest SASL mechanism Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Jxr_vD.A.Oj.rGrv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Does anyone know of an LDAP server product that supports the Digest SASL mechanism defined in: http://www.ietf.org/internet-drafts/draft-leach-digest-sasl-05.txt Thanks in advance. From list@netscape.com Thu Mar 2 15:31:57 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25759 for ; Thu, 2 Mar 2000 15:31:57 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id MAA00807; Thu, 2 Mar 2000 12:28:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id MAA11840; Thu, 2 Mar 2000 12:30:32 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 12:30:32 -0800 (PST) Message-ID: <438D12915E64D2118AB10000F8C1C0780273419E@zcard00e.ca.nortel.com> From: "James Benedict" To: Linda Grimaldi , "Kurt D. Zeilenga" , ggood@netscape.com Cc: Natarajan SK , ietf-ldapext@netscape.com, Savitha R , ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 14:15:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF847B.B0E352F8" Resent-Message-ID: <"iUqeQD.A.u4C.n9sv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF847B.B0E352F8 Content-Type: text/plain; charset="ISO-8859-1" So lets try to get a list of all the current uses of changelogs (good or bad), and see if we can identify viable alternatives for them. If not, then I think we've got a good reason to look at changelog standardization. I'll start with my original list > Accountability (Who did what? When?) > Problem Tracking (Why is my email address X) > Recovery (Whoops, I didn't really want to rename everyone in > my directory) > Client-side caching (Give me all the changes to a subtree) and add, Change Monitoring (a new addition to the changelog means something changed somewhere... it's kind of a caching issue, but a little different) Anyone else? James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com] > Sent: Thursday, March 02, 2000 9:56 AM > To: Benedict, James [CAR:5N41-M:EXCH]; Kurt D. Zeilenga; > ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: RE: Changelog entries draft. Do not seem to find it. > > > Just one note on changelog standardization. I recently wrote > a program to monitor change logs for audit purposes. It > worked great on Innosoft- I had to re-write chunks of it for > Netscape. I was quite pissed off, and cursed both the IETF > and the LDAP working group for about a week (fortunately, to > no effect). Mr. Benedict makes a good point about using the > logs for other purposes. From a developer's perspective, I > would really appreciate some consistency here. > > Linda > > -----Original Message----- > From: James Benedict [SMTP:grunt@nortelnetworks.com] > Sent: Thursday, March 02, 2000 6:32 AM > To: Kurt D. Zeilenga; ggood@netscape.com > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > ietf-ldup@imc.org > Subject: RE: Changelog entries draft. Do not seem to find it. > > Changelogs seem to be falling between the cracks (LDAP, LDUP, > LCUP?). The concept of changelogs is important to > replication, but it also > has many other uses. > > Accountability (Who did what? When?) > Problem Tracking (Why is my email address X) > Recovery (Whoops, I didn't really want to rename everyone in > my directory) > Client-side caching (Give me all the changes to a subtree) > > If LDUP is going to subsume the role of maintaining changes > for replication > purposes, then I think it is important to make sure that > mechanisms are > in place to deal with these other uses as well. Otherwise, I think > changelogs should become part of the LDAP standard, not just > informational. > > It doesn't really matter how the directory server maintains this > information, but clients need to have a consistent way of > accessing it. > > James A Benedict > Advisor, IP Directory Systems Architecture > Preside Policy Services > NORTEL NETWORKS > Ph: (613) 763-3909 > > > > -----Original Message----- > > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > > Sent: Wednesday, March 01, 2000 1:30 PM > > To: ggood@netscape.com > > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R; > > ietf-ldup@imc.org > > Subject: Re: Changelog entries draft. Do not seem to find it. > > > > > > At 10:04 AM 3/1/00 -0800, Gordon Good wrote: > > >While I'm happy to resurrect the changelog draft and discuss > > publishing it as a standards-track document (informational, > > >probably), it's not going to be a part of the LDUP specification. > > > > I would support publication of the Changelog draft as an > > Informational RFC as it would document existing practices. > > The document would have to be amended, of course, to contain > > appropriate statements concerning IETF work in this area. > > > > Kurt > > > << File: ATT00002.htm >> > ------_=_NextPart_001_01BF847B.B0E352F8 Content-Type: text/html; charset="ISO-8859-1" RE: Changelog entries draft. Do not seem to find it.

So lets try to get a list of all the current uses of changelogs
(good or bad), and see if we can identify viable alternatives for them.
If not, then I think we've got a good reason to look at changelog standardization.

I'll start with my original list
> Accountability (Who did what? When?)
> Problem Tracking (Why is my email address X)
> Recovery (Whoops, I didn't really want to rename everyone in
> my directory)
> Client-side caching (Give me all the changes to a subtree)

and add,

Change Monitoring (a new addition to the changelog means something
changed somewhere... it's kind of a caching issue, but a little
different)

Anyone else?

James A Benedict
Advisor, IP Directory Systems Architecture
Preside Policy Services
NORTEL NETWORKS
Ph:  (613) 763-3909



> -----Original Message-----
> From: Linda Grimaldi [mailto:linda.grimaldi@wcom.com]
> Sent: Thursday, March 02, 2000 9:56 AM
> To: Benedict, James [CAR:5N41-M:EXCH]; Kurt D. Zeilenga;
> ggood@netscape.com
> Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R;
> ietf-ldup@imc.org
> Subject: RE: Changelog entries draft. Do not seem to find it.
>
>
> Just one note on changelog standardization.  I recently wrote
> a program to monitor change logs for audit purposes.  It
> worked great on Innosoft- I had to re-write chunks of it for
> Netscape.  I was quite pissed off, and cursed both the IETF
> and the LDAP working group for about a week (fortunately, to
> no effect). Mr. Benedict makes a good point about using the
> logs for other purposes.  From a developer's perspective, I
> would really appreciate some consistency here.
>
> Linda
>
> -----Original Message-----
> From: James Benedict [SMTP:grunt@nortelnetworks.com]
> Sent: Thursday, March 02, 2000 6:32 AM
> To:   Kurt D. Zeilenga; ggood@netscape.com
> Cc:   Natarajan SK; ietf-ldapext@netscape.com; Savitha R;
> ietf-ldup@imc.org
> Subject:      RE: Changelog entries draft. Do not seem to find it.
>
> Changelogs seem to be falling between the cracks (LDAP, LDUP,
> LCUP?).  The concept of changelogs is important to
> replication, but it also
> has many other uses.
>
> Accountability (Who did what? When?)
> Problem Tracking (Why is my email address X)
> Recovery (Whoops, I didn't really want to rename everyone in
> my directory)
> Client-side caching (Give me all the changes to a subtree)
>
> If LDUP is going to subsume the role of maintaining changes
> for replication
> purposes, then I think it is important to make sure that
> mechanisms are
> in place to deal with these other uses as well.  Otherwise, I think
> changelogs should become part of the LDAP standard, not just
> informational.
>
> It doesn't really matter how the directory server maintains this
> information, but clients need to have a consistent way of
> accessing it.
>
> James A Benedict
> Advisor, IP Directory Systems Architecture
> Preside Policy Services
> NORTEL NETWORKS
> Ph:  (613) 763-3909
>
>
> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> > Sent: Wednesday, March 01, 2000 1:30 PM
> > To: ggood@netscape.com
> > Cc: Natarajan SK; ietf-ldapext@netscape.com; Savitha R;
> > ietf-ldup@imc.org
> > Subject: Re: Changelog entries draft. Do not seem to find it.
> >
> >
> > At 10:04 AM 3/1/00 -0800, Gordon Good wrote:
> > >While I'm happy to resurrect the changelog draft and discuss
> > publishing it as a standards-track document (informational,
> > >probably), it's not going to be a part of  the LDUP specification.
> >
> > I would support publication of the Changelog draft as an
> > Informational RFC as it would document existing practices.
> > The document would have to be amended, of course, to contain
> > appropriate statements concerning IETF work in this area.
> >
> > Kurt
> >
>  << File: ATT00002.htm >>
>

------_=_NextPart_001_01BF847B.B0E352F8-- From list@netscape.com Thu Mar 2 16:35:32 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28382 for ; Thu, 2 Mar 2000 16:35:32 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA09840; Thu, 2 Mar 2000 13:28:26 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA08315; Thu, 2 Mar 2000 13:32:38 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 13:32:38 -0800 (PST) Message-ID: From: "Salter, Thomas A" To: ietf-ldapext@netscape.com, ietf-ldup@imc.org Subject: RE: Changelog entries draft. Do not seem to find it. Date: Thu, 2 Mar 2000 16:32:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"zzK4qD.A.pBC.13tv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I think the changelog draft should be standardized. It provides a simple, but useful feature. It's been implemented by more that one server and probably lots of clients. Perhaps it should include a disclaimer that it provides an interim solution until LDUP/LCUP mechanisms are defined and implemented. Accountability can be provided by adding createTimestamp and creatorsName to the changeLog entries. These are implied anyway, since change log records are defined as though they are entries in the directory, and all directory entries MAY contain these operational attributes. From list@netscape.com Thu Mar 2 16:55:55 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28996 for ; Thu, 2 Mar 2000 16:55:55 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA12870; Thu, 2 Mar 2000 13:50:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA20014; Thu, 2 Mar 2000 13:54:28 -0800 (PST) Resent-Date: Thu, 2 Mar 2000 13:54:28 -0800 (PST) Message-ID: <38BEE2B6.BE3DF1D2@netscape.com> Date: Thu, 02 Mar 2000 13:52:56 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com CC: ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"uD628C.A.c4E.SMuv4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit "Salter, Thomas A" wrote: > I think the changelog draft should be standardized. It provides a simple, > but useful feature. It's been implemented by more that one server and > probably lots of clients. > > Perhaps it should include a disclaimer that it provides an interim solution > until LDUP/LCUP mechanisms are defined and implemented. > > Accountability can be provided by adding createTimestamp and creatorsName to > the changeLog entries. These are implied anyway, since change log records > are defined as though they are entries in the directory, and all directory > entries MAY contain these operational attributes. I agree, with the caveat that supporting an LDAP-accessible changelog exactly as described in the internet draft may be very difficult in an environment featuring multi-master replication. As James Benedict mentioned, it would be very helpful to have an inventory of planned and existing applications that use changelogs. I've heard several mentioned on this mailing list - are there others? I have a strong suspicion that these applications will fall into one of a small number of classes, and that some of these classes may be better served by a newer client synchronization protocol that combines ideas from our Persistent Search draft, Innosoft's Triggered Search draft, and Microsoft's Dirsync draft. A first draft of that was posted to the ietf-lcup@netscape.com and ietf-ldup@imc.org mailing lists yesterday. -Gordon From list@netscape.com Fri Mar 3 21:16:39 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13393 for ; Fri, 3 Mar 2000 21:16:38 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA02878; Fri, 3 Mar 2000 18:13:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA02927; Fri, 3 Mar 2000 18:15:13 -0800 (PST) Resent-Date: Fri, 3 Mar 2000 18:15:13 -0800 (PST) From: dgkofdo@red.paston.co.uk Date: Fri, 3 Mar 2000 17:37:02 Message-Id: <156.894228.806909@mail.mindspring.com> Apparently-To: Apparently-To: Apparently-To: Resent-Message-ID: <"H92GPD.A.bt.vGHw4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com USE BULK EMAIL TO ADVERTISE YOUR PRODUCT OR SERVICE TODAY! 28,000 email broadcast (opt in) $495.00 500,000 email broadcast $750.00. 1 million Email Broadcast $1200.00. For details call 1 888 248 0765 today!. ______________________________________________________________ Stop paying $19.95 per month or more for web space! You can get it from us for only $12.95 per month! This price inlcudes hosting your own domain! All fees are prepaid in advance with a 90 day money back guarantee! A $40.00 set up fee applies to new customers. For details call 1 888 248 0765 today!.. _______________________________________________________________ Want to start bulk emailing on your own? Make your phone ring off the hook NOW! Get our popular program Direct Mail for only $395.00 to do the mailing you only dreamed about! Better yet for optimal responses you are going to want to email your ad in html format! Purchase our professional mailer program Emerge for only $1500.00 today! To get your own email addresses you will need an email address extractor! Use Nitro to get all the addresses you want for only $495.00! Get your free demo's at 888 248 0765 today! For further details call 888 248 0765 NOW! For our international customers please fax us at 240 352 7546 today! From list@netscape.com Mon Mar 6 18:12:49 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24454 for ; Mon, 6 Mar 2000 18:12:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA17710; Mon, 6 Mar 2000 15:07:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA05129; Mon, 6 Mar 2000 15:11:26 -0800 (PST) Resent-Date: Mon, 6 Mar 2000 15:11:26 -0800 (PST) Message-ID: <38C43B25.CB895F6F@netscape.com> Date: Mon, 06 Mar 2000 15:11:33 -0800 From: olga@netscape.com (Olga Natkovich) X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com Subject: lcup Content-Type: multipart/mixed; boundary="------------A4C7C527B9C5D24EA11236FF" Resent-Message-ID: <"15VzND.A.dOB.UsDx4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a multi-part message in MIME format. --------------A4C7C527B9C5D24EA11236FF Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

Attached is the specification for the LDAP Client Update Protocol (LCUP). The draft will be submitted to IETF later this week. LDUP will consider adding LCUP to its agenda at the coming IETF meeting.

Comments are welcome,

Olga Natkovich
Software Engineer, Sun-Netscape Alliance --------------A4C7C527B9C5D24EA11236FF Content-Type: text/plain; charset=us-ascii; name="draft-natkovich-ldap-lcup-00.txt" Content-Disposition: inline; filename="draft-natkovich-ldap-lcup-00.txt" Content-Transfer-Encoding: 7bit Internet Draft O. Natkovich Document: M. Smith Category: Proposed Standard Netscape Communications Corp. February 2000 LDAP Client Update Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document defines the LDAP Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. 2. Conventions used in this document In the protocol flow definition, the notation C->S and S->C specifies the direction of the data flow from the client to the server and from the server to the client respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. 3. Overview The LCUP protocol is intended to allow LDAP clients to synchronize with the content stored by LDAP servers. The problem areas addressed by the protocol include: - mobile clients that maintain a local read-only copy of the directory data. While off-line, the client uses the local copy of the data. When the client connects to the network, it synchronizes with the current directory content and can be optionally notified about the changes that occur while it is on- line. For example, a mail client can maintain a local copy of the corporate address book that it synchronizes with the master copy whenever the client gets connected to the corporate network. - applications intending to synchronize heterogeneous data stores. A meta directory application, for instance, would periodically retrieve a list of modified entries from the directory, construct the changes and apply them to a foreign data store. - clients that need to take certain actions when a directory entry is modified. For instance, an electronic mail repository may want to perform a "create mailbox" task when a new person entry is added to an LDAP directory and a "delete mailbox" task when a person entry is removed. The problem areas not being considered: - directory server to directory server synchronization. The LDUP replication protocol [LDUPPROT] should be used for this purpose. Several features of the protocol distinguish it from LDUP replication. First, the server does not maintain any state information on behalf of its clients. The clients are responsible for storing the information about how up to date they are with respect to the server's content. Second, no predefined agreements exist between the clients and the servers. The client decides when and from where to retrieve the changes. Finally, the server never pushes the data to the client; the client always initiates the update session during which it pulls the changes from the server. The set of clients that are allowed to synchronize with an LDAP server is determined by the server defined policy. There are, currently, several protocols available for LDAP client server synchronization. While each protocol addresses the needs of a particular group of clients (on-line clients in case of Persistent [PSEARCH] and Triggered [TSEARCH] Search, off-line clients in case of DirSync [DIRSYNC]), none satisfies the requirements of all clients in the target group. For instance, a mobile client that was off-line and wants to become up to date with the server and stay up to date while connected can't be easily supported by any of the above protocols. 4. Protocol Specification This section describes the protocol elements and the protocol flow. 4.1 Protocol Elements Natkovich Proposed Standard - Expires: August 2000 2 A client initiates a synchronization session with a server by attaching a clientUpdate control to a search operation. The search specification determines the part of the directory information tree (DIT) the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. The clientUpdate control contains the client's synchronization specification. The control has the following format: clientUpdateControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL keepConnection BOOLEAN DEFAULT FALSE changesOnly BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. keepConnection - if set to TRUE, indicates that the server should keep the connection open after the initial synchronization and should notify the client of modifications to the data. The connection should stay open until the client abandons the search operation, sends the stopClientUpdate extended operation, or closes the connection. changesOnly - if set to TRUE, the keepConnection and cookie fields of the control are ignored by the server. In response, the server skips the initial synchronization and only notifies the client about the changes that occur to the data while the client is connected. This feature is useful if the client is not interested in data synchronization but needs to trigger events in response to data modifications. In response to the client's synchronization request, the server returns a set of SearchResultEntries that fits the client's specification. To represent deleted entries, the server attaches an entryUpdate control to the SearchResultEntry. Furthermore, the server may elect to periodically return to the client the cookie that represents the state of the client's data. This information is useful in case the client crashes or gets disconnected. The cookie is also provided in the entryUpdate control. The control has the following format: entryUpdateControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL stateUpdate BOOLEAN DEFAULT FALSE entryDeleted BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. stateUpdate - if set to TRUE, indicates that the entry to which the control is attached contains no changes and it is sent only to Natkovich Proposed Standard - Expires: August 2000 3 communicate to the client the new cookie. In this case, the entryDeleted field MUST be ignored and the cookie field WILL contain the updated cookie. This feature allows updating the client's cookie when there is no changes that effect the client's data store. Note that the server MUST attach the control to a valid entry. The server COULD always send the entry at the root of the client's tree. entryDeleted - if set to TRUE, indicates that the entry to which the control is attached was deleted. When the server has finished processing the client's request, it attaches a clientUpdateDone control to the SearchResult message and sends it to the client. The control has the following format: clientUpdateDoneControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL reload BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. reload - if set to TRUE, indicates that the server does not contain sufficient information to synchronize the client or that the server's data was reloaded since the last synchronization session. This field indicates to the client that the client's data store needs to be reinitialized. If the client needs to terminate the synchronization process and it wishes to obtain the cookie that represents the current state of its data, it issues a stopClientUpdateRequest extended operation. The operation carries no data. The server responds with a stopClientUpdateResponse extended operation that has the following format: stopClientUpdateResponseValue ::= SEQUENCE { cookie OCTET STRING } cookie - an opaque cookie that represents the current state of the client's data. If the client is not interested in the state information, it can simply abandon the search operation or disconnect from the server. If server resources become tight, the server can terminate one or more search operations by sending a SearchResult message to the client(s). Unless the client sets the changesOnly field to TRUE, the server attaches a clientUpdateDone control that contains the cookie that corresponds to the current state of the client's data and the reload flag set to 0. A server set policy is used to decide which searches to terminate. This can also be used as a security Natkovich Proposed Standard - Expires: August 2000 4 mechanism to disconnect clients that are suspected of malicious actions. 4.2 Protocol Flow The client server interaction can proceed in three different ways depending on the client's requirements. If the client's intent is not to synchronize data but to trigger actions in response to directory modifications, the protocol proceeds as follows: C->S Sends a search operation with a clientUpdate control attached. The search specification determines the part of the DIT the client wishes to synchronize with and the set of attributes it is interested in. The changesOnly field of the control should be set to TRUE; other fields are ignored. S->C Sends change notification to the client for each change to the data within the client's search specification. S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server can terminate the search operation by sending a SearchResult message to the client. C->S Abandons the search operation or disconnects from the server. S->C Stops sending changes to the client and closes the connection. If the client's intent is to synchronize with the server and then disconnect, the protocol proceeds as follows: C->S Sends a search operation with the clientUpdate control attached. The search specification determines the part of the DIT the client wishes to synchronize with, the set of attributes it is interested in and the amount of data the client is willing to receive. If this is the initial synchronization session, the client does not provide a cookie; otherwise, the cookie field of the control is set to the cookie received from the server at the end of the last synchronization session. (Note that the client can synchronize with different servers during different synchronization sessions.) The keepConnection and changesOnly fields are set to FALSE. S->C If no cookie is specified in the clientUpdate control, the server sends all data that matches the client's search specification followed by the SearchResult message with a clientUpdateDone control attached to it. The control contains the cookie that corresponds to the current state of the client's data and the reload flag set to FALSE. If an invalid cookie is specified the server sends back an unwillingToPerform error. If a valid cookie is specified and the data that matches the search specification has been reloaded or the server does not contain enough state information to synchronize the client, the server sends a clientUpdateDone control with the reload field set to TRUE and no cookie. Natkovich Proposed Standard - Expires: August 2000 5 If the client is up to date, the server sends a success response to the client. If the cookie is valid and there is data to be sent, the server sends the modified entries to the client. Each SearchResultEntry contains the attributes requested by the client in the search specification regardless of whether they were modified. An entryUpdate control with the entryDeleted field set to TRUE is attached to every deleted entry. The server may also periodically attach an entryUpdate control to the entries sent to the client to indicate the current state of the client's data. In that case, the cookie field of the control represents the state of the client's data including the entry to which the control is attached. Once all the changes are sent, the server sends a SearchResult with the clientUpdateDone control attached. The control contains the cookie that represents the current state of the client's data. The reload field of the control is set to FALSE. C->S If the reload field of the control is set to TRUE, the client clears its data store and repeats the synchronization process by sending the search operation with clientUpdate control that contains no cookie. Otherwise, the client stores the cookie received from the server until the next synchronization session. If the client's intent is to be synchronized with the server and stay notified about data modifications, the protocol proceeds as follows: C->S The client behaves exactly as in the previous case except it sets the keepConnection control field to TRUE. S->C The server behaves exactly as in the previous case except the connection is kept open after the initial set of changes is sent to the client. A SearchResult message is not sent to the client; instead, the server keeps sending changes to the client. S->C If the server starts to run out of resources or the client is suspected of malicious actions, the server can terminate the search operation by sending a SearchResult message with the clientUpdateDone control back to the client. C->S Sends a stopClientUpdateRequest extended operation to the server to terminate the synchronization session. S->C Responds with a stopClientUpdateResponse extended operation with the cookie representing the current state of the client's data. 4.3 Size and Time Limits The search request size or the time limits can only be imposed for non-persistent operations, those that set keepConnection field of the clientUpdateControlValue to FALSE. All other operations SHOULD set both limits to 0. The server SHOULD ignore the limits set for persistent operations. 4.4 Changes vs. Operations Natkovich Proposed Standard - Expires: August 2000 6 Since the server sends to the client the modified entries rather than the operations, a MODDN operation performed on a subtree will be seen by the client as a sequence of added or modified entries depending on whether the operation moved the entries into the scope of the client's search specification. 5.0 Additional Features There are several features present in other protocols or considered useful by clients that are currently not included in the protocol primarily because they are difficult to implementing on the server. These features are briefly discussed in this section. This section is intended to open a discussion on the merits of including and approaches of implementing these features. 5.1. Change Type This feature is present in the Triggered Search [TSEARCH] specification. A flag is attached to each entry returned to the client indicating the reason why this entry is returned. The possible reasons from the draft are "- notChange: the entry existed in the directory and matched the search at the time the operation is being performed, - enteredSet: the entry entered the result set for one of the reasons defined in section 4 above, - leftSet: the entry left the result set for one of the reasons defined in section 4 above, - modified: the entry was part of the result set, was modified or renamed, and still is in the result set." The leftSet feature is particularly useful because it indicates to the client that an entry is no longer within the client's search specification and the client can remove the associated data from its data store. Ironically, this feature is the hardest to implement on the server because the server does not keep track of the client's state and has no easy way of telling which entries moved out of scope between synchronization sessions with the client. A compromise could be reached by only providing this feature for the operations that occur while the client is connected to the server. This is easier to accomplish because the decision about the change type can be made based only on the change without need for any historical information. This, however, would add complexity to the protocol. 5.2. Sending Changes The DirSync protocol [DIRSYNC] sends to the clients only the modified attributes of the entry rather than the entire entry. While this approach can significantly reduce the amount of data returned to the client, it has several disadvantages. First, unless a separate mechanism (like the change type described above) is used to notify the client about entries moving into the search scope, Natkovich Proposed Standard - Expires: August 2000 7 sending only the changes can result in the client having an incomplete version of the data. Let's consider an example. An attribute of an entry is modified. As a result of the change, the entry enters the scope of the client's search. If only the changes are sent, the client would never see the initial data of the entry. Second, this feature is hard to implement since the server might not contain sufficient information to construct the changes based solely on the server's state and the client's cookie. On the other hand, this feature can be easily implemented by the client assuming that the client has the previous version of the data and can perform value by value comparisons. 5.3. Data Size Limits The DirSync protocol [DIRSYNC] allows clients to control the amount of data sent to them in the search response. The client can specify the number of bytes it is willing to receive by setting the maxReturnLength field of the DirSync control. This feature is intended to allow clients with limited resources to process synchronization data in batches. However, an LDAP search operation already provides the means for the client to specify the size limit by setting the sizeLimit field in the SearchRequest to the maximum number of entries the client is willing to receive. While the granularity is not the same, the assumption is that LCUP protocol will be implemented by regular LDAP clients that can deal with the limitations of the LDAP protocol. 5.4. Data Ordering The DirSync protocol [DIRSYNC] allows a client to specify that parent entries should be sent before the children for add operations and children entries sent before their parents during delete operations. This ordering helps clients to maintain a hierarchical view of the data in their data store. While possibly useful, this feature is relatively hard to implement and is expensive to perform. 6. The Protocol and the LDUP Architecture The LDAP Client Update Protocol is defined within the framework of the LDUP Architecture [LDUPARCH]. The following aspects of the protocol are drawn from the architecture: - The scope of each search operation is restricted to a single replica as defined in the LDUP architecture document [LDUPARCH]. - Each entry returned to the client contains a unique identifier as defined in the LDUP architecture document [LDUPARCH]. The client can use the identifier to unambiguously cross reference objects stored on the server with those in the client's store. - One of the main criteria for selecting the protocol features is that an LDUP compliant server can implement these features efficiently. Natkovich Proposed Standard - Expires: August 2000 8 7. Client Side Considerations There are several issues that the implementors of a synchronization client need to consider: - The cookie received from the server after a synchronization session can only be used with the same or more restrictive search specification than the search that generated the cookie. The server will reject the search operation with a cookie that does not satisfy this condition. This is because the client can end up with an incomplete data store otherwise. A more restrictive search specification is the one that generates a subset of the data produced by the original search specification. - Because an LCUP client specifies the area of the tree with which it wishes to synchronize through the standard LDAP search specification, the client can be returned nsSuchObject error if the root of the synchronization area was renamed between the synchronization sessions. If this condition occurs, the client can attempt to locate the root by using the root's uniqueid saved in client's local data store. It then can repeat the synchronization request using the new search base. In general, a client can detect that an entry was renamed and apply the changes received to the right entry by using uniqueid rather than DN based addressing. 8. Server Implementation Considerations By design, the protocol does not specify the format of the cookie. This is to allow different implementations the flexibility of storing any information applicable to their environment. A reasonable implementation for an LDUP compliant server would be to use the Replica Update Vector (RUV). For each master, RUV contains the largest CSN seen from this master. In addition, the RUV implemented by the iPlanet Directory Server (not yet in LDUP) contains replica generation - an opaque string that identifies the replica's data store. The replica generation value changes whenever the replica's data is reloaded. Replica generation is intended to signal the replication/synchronization peers that the replica's data was reloaded and that all other replicas need to be reinitialized. RUV satisfies the three most important properties of the cookie: (1) it uniquely identifies the state of client's data, (2) it can be used to synchronize with multiple servers, and (3) it can be used to detect that the server's data was reloaded. In addition, the cookie must contain enough information to allow the server to determine whether the cookie can be safely used with the search specification it is attached to. As discussed earlier in the document, the cookie can only be used with the search specification that is equally or more restrictive than the one for which the cookie was generated. Natkovich Proposed Standard - Expires: August 2000 9 An implementation must make sure that it can correctly update the client's cookie when there is a size limit imposed on the search results by either the client's request or by the server's configuration. If RUV is used as the cookie, entries last modified by a particular master must be sent to the client in the order of their last modified CSN. This ordering guarantees that the RUV can be updated after each entry is sent. An implementation must be able to notify the client about all entries deleted since the last implementation session. An LDUP compliant implementation can achieve this through the use of entry tombstones. The implementation should avoid aggressive tombstone purging since lack of tombstones would cause client's data to be reloaded. We suggest that only the tombstone content be removed during the regular trimming cycle while tombstones themselves are discarded much less frequently. The specification makes no guarantees about how soon a server should send notification of a changed entry to the client when the connection between the client and the server is kept open. This is intentional as any specific maximum delay would be impossible to meet in a distributed directory service implementation. Server implementors are encouraged to minimize the delay before sending notifications to ensure that clients' needs for timeliness of change notification are met. 9. Synchronizing Heterogeneous Data Stores Clients synchronizing multiple writeable data stores, like iPlanet Meta Directory, will only work correctly if each piece of information is single mastered (for instance, only by an LDUP compliant directory or only by Oracle). This is because different systems have different notions of time and different update resolution procedures. As a result, a change applied on one system can be discarded by the other, thus preventing the data stores from converging. 10. Security Considerations In some situations, it may be important to prevent general exposure of information about changes that occur in an LDAP server. Therefore, servers that implement the mechanism described in this document SHOULD provide a means to enforce access control on the entries returned and MAY also provide specific access control mechanisms to control the use of the controls and extended operations defined in this document. As with normal LDAP search requests, a malicious client can initiate a large number of persistent search requests in an attempt to consume all available server resources and deny service to legitimate clients. The protocol provides the means to stop malicious clients by disconnecting them from the server. The servers that implement the mechanism SHOULD provide the means to detect the Natkovich Proposed Standard - Expires: August 2000 10 malicious clients. In addition, the servers SHOULD provide the means to limit the number of resources that can be consumed by a single client. Access control on the data can be modified in such a way that the data is no longer visible to the client. The specification does not specify how the server should handle this condition. Moreover, data consistency is not guaranteed if access control is changed from a more restrictive to a less restrictive one. This is because access control can be considered as an additional filter on the search specification and the protocol does not support going from a more to a less restrictive search specification. See Client Side Considerations Section for more detailed explanation of the problem. 11. References [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [PSEARCH] M. Smith "A Simple LDAP Change Notification Mechanism", INTERNET-DRAFT , August 1998. [TSEARCH] M.Whal "LDAPv3 Triggered Search Control", INTERNET-DRAFT , August 1998. [DIRSYNC] M. Armijo "Microsoft LDAP Control for Directory Synchronization", INTERNET-DRAFT , August 1999. [LDUPARCH] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architecture", INTERNET-DRAFT , October 1999. [LDUPPROT] E. Stokes, G. Good "The LDUP Replication Update Protocol", INTERNET-DRAFT , October 1999. 12. Author's Addresses Olga Natkovich Netscape Communications Corp. 501. E. Middlefield Rd., Mailstop MV068 Mountain View, CA 94043 Phone: +1 650 937-4788 Email: olga@netscape.com Mark Smith Netscape Communications Corp. 501. E. Middlefield Rd., Mailstop MV068 Mountain View, CA 94043 Phone: +1 650 937-3477 Natkovich Proposed Standard - Expires: August 2000 11 Email: mcs@netscape.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Natkovich Proposed Standard - Expires: August 2000 12 --------------A4C7C527B9C5D24EA11236FF-- From list@netscape.com Wed Mar 8 06:33:25 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29308 for ; Wed, 8 Mar 2000 06:33:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA01312; Wed, 8 Mar 2000 03:27:56 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA11304; Wed, 8 Mar 2000 03:32:17 -0800 (PST) Resent-Date: Wed, 8 Mar 2000 03:32:17 -0800 (PST) Message-Id: <200003081132.GAA28812@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-psearch-02.txt Date: Wed, 08 Mar 2000 06:32:07 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"mUNfhB.A.WwC.9ojx4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Persistent Search: A Simple LDAP Change Notification Mechanism Author(s) : M. Smith, G. Good, R. Weltman, T. Howes Filename : draft-ietf-ldapext-psearch-02.txt Pages : 8 Date : 07-Mar-00 This document defines two controls that extend the LDAPv3 [LDAP] search operation to provide a simple mechanism by which an LDAP client can receive notification of changes that occur in an LDAP server. The mechanism is designed to be very flexible yet easy for clients and servers to implement. Since the IETF is likely to pursue a different, more comprehensive solution in this area, this document will eventually be published with Informational status in order to document an existing practice. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-psearch-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-ldapext-psearch-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-ldapext-psearch-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: <20000307114353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-psearch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-psearch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000307114353.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Mar 8 18:47:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18242 for ; Wed, 8 Mar 2000 18:47:20 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA19564; Wed, 8 Mar 2000 15:41:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA00675; Wed, 8 Mar 2000 15:46:05 -0800 (PST) Resent-Date: Wed, 8 Mar 2000 15:46:05 -0800 (PST) From: rgfso@stuttgart.shuttle.de Date: Mon, 6 Mar 2000 16:15:26 Message-Id: <452.809952.853389@mail.mindspring.com> Resent-Message-ID: <"NmM9iC.A.uJ.7Yux4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com USE BULK EMAIL TO ADVERTISE YOUR PRODUCT OR SERVICE TODAY! 28,000 email broadcast (opt in) $495.00 500,000 email broadcast $750.00. 1 million Email Broadcast $1200.00. For details call 1 888 248 0765 today!. ______________________________________________________________ Stop paying $19.95 per month or more for web space! You can get it from us for only $12.95 per month! This price inlcudes hosting your own domain! All fees are prepaid in advance with a 90 day money back guarantee! A $40.00 set up fee applies to new customers. For details call 1 888 248 0765 today!.. _______________________________________________________________ Want to start bulk emailing on your own? Make your phone ring off the hook NOW! Get our popular program Direct Mail for only $395.00 to do the mailing you only dreamed about! Better yet for optimal responses you are going to want to email your ad in html format! Purchase our professional mailer program Emerge for only $1500.00 today! To get your own email addresses you will need an email address extractor! Use Nitro to get all the addresses you want for only $495.00! Get your free demo's at 888 248 0765 today! For further details call 888 248 0765 NOW! For our international customers please fax us at 240 352 7546 today! From list@netscape.com Thu Mar 9 06:30:59 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25704 for ; Thu, 9 Mar 2000 06:30:58 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA18802; Thu, 9 Mar 2000 03:27:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA00041; Thu, 9 Mar 2000 03:29:51 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 03:29:51 -0800 (PST) Message-Id: <200003091129.GAA25085@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt Date: Thu, 09 Mar 2000 06:29:45 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"-3FVMD.A.O.ts4x4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : The Java LDAP Application Program Interface Asynchronous Extension Author(s) : R. Weltman, C. Tomlinson, M. Kekic Filename : draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt Pages : 23 Date : 08-Mar-00 This document defines asynchronous extensions to the java language application program interface to the lightweight directory access protocol (LDAP) defined in [JAVALDAP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-asynch-ext-05.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-ldapext-ldap-java-api-asynch-ext-05.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-ldapext-ldap-java-api-asynch-ext-05.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: <20000308131918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldap-java-api-asynch-ext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131918.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Thu Mar 9 06:31:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25755 for ; Thu, 9 Mar 2000 06:31:03 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA18800; Thu, 9 Mar 2000 03:27:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA00007; Thu, 9 Mar 2000 03:29:49 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 03:29:49 -0800 (PST) Message-Id: <200003091129.GAA25039@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-ldap-java-api-10.txt Date: Thu, 09 Mar 2000 06:29:40 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"9Q5RYC.A.dUH.ss4x4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : The Java LDAP Application Program Interface Author(s) : R. Weltman, C. Tomlinson, J. Sermersheim, M. Smith, T. Howes Filename : draft-ietf-ldapext-ldap-java-api-10.txt Pages : 106 Date : 08-Mar-00 This document defines a java language application program interface to the lightweight directory access protocol (LDAP), in the form of a class library. It complements but does not replace RFC 1823 ([7]), which describes a C language application program interface. It updates and the previous draft in correcting a few minor errors which are listed in appendix B. The companion document draft-ietf-ldapext-ldap-java-api-asynch [10] defines the mandatory to implement asynchronous layer of the API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-10.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-ldapext-ldap-java-api-10.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-ldapext-ldap-java-api-10.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: <20000308131902.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldap-java-api-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldap-java-api-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131902.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Thu Mar 9 16:59:11 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06353 for ; Thu, 9 Mar 2000 16:59:08 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA26976; Thu, 9 Mar 2000 13:53:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA20096; Thu, 9 Mar 2000 13:57:43 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 13:57:43 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 09 Mar 2000 14:48:53 -0700 From: "Ed Reed" To: , , , , Cc: , Subject: LDAP subentry, discussion on CN {MUST or MAY} Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"-36oMC.A.P5E.U5By4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA06353 Back in November and at the IETF meeting in Washington, we discussed whether LDAPsubentry should be STRUCTURAL or ABSTRACT in definition. Mark has pointed out that MAY would address Kurt's objection to MUST {cn}, but that leaves the many folks out there who define naming rules with a problem, when there are (possibly) no attributes defined on the class at all (cn is the only attribute declared for the ldapsubentry class definition). Frankly, those folks who DO define naming attributes and naming rules will have to deal in some way with other systems who don't, but that's a different discussion I think. I think the discussion in Washington concluded that we should 1) leave the class STRUCTURAL 2) leave MUST {cn} in the definition 3) encourage Kurt to derive a new subclass of LDAPsubentry for his special-purpose class, which defines the other attribute he will use to actually name his entries - meaning that yes, he will need to provide a (possibly useless, but not necessarily unique) value for the cn value Erik's argument, that to make it Auxiliary would require a proliferation of new structural types, each with their own new naming rules, is what finally persuaded me to avoid that approach. The consequences of blithly ignoring the operational experience of the X.500 community was also important. It will be easier, by far, for most people to treat LDAPsubentry as STRUCTURAL, and then to decorate it with additional attributes for their particular needs, than to require each new use to define a new STRUCTURAL class with it's own naming rules. As I think about it, though, there is one way to make both camps happy: 1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. 2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). Such an approach would violate the "fewer classes is better" rule. But I think it would satisfy both Kurt and the X.500 folks. This is the only issue standing in the way of a last call. Any final words? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM From list@netscape.com Thu Mar 9 18:20:55 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01150 for ; Thu, 9 Mar 2000 18:20:53 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA08578; Thu, 9 Mar 2000 15:15:16 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA25745; Thu, 9 Mar 2000 15:19:41 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 15:19:41 -0800 (PST) Message-Id: <3.0.5.32.20000309151919.009539c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Mar 2000 15:19:19 -0800 To: "Ed Reed" From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Cc: , , , , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"koqRkC.A.qRG.MGDy4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 02:48 PM 3/9/00 -0700, Ed Reed wrote: >1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. >2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). That's exactly what I had in mind all a long. But Mark's suggestion of a single STRUCTURAL class with MAY cn is works as well. I really don't understand the 'naming rule' issue with MUST vs. MAY. One additional comment: We need a STRUCTURAL object class for the Root DSE. This object class would have no naming attributes... and, in fact, doesn't need to MAY/MUST any attributes. Ie: ( NAME 'LDAPentry' SUP 'top' STRUCTURAL ) My question is, does it make sense to define subentry oc's in terms of LDAPentry? I would guess "no" as a entry and subentries are quite different. Anyways, food for thought. From list@netscape.com Thu Mar 9 18:33:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04734 for ; Thu, 9 Mar 2000 18:33:53 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA10561; Thu, 9 Mar 2000 15:28:19 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA00876; Thu, 9 Mar 2000 15:32:45 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 15:32:45 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 09 Mar 2000 16:29:48 -0700 From: "Sukanta Ganguly" To: , Cc: , , , , , , Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2871D584.DFBEBC84" Resent-Message-ID: <"mbyRpB.A.GN.bSDy4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_2871D584.DFBEBC84 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Kurt, What is the reason behind the need to have a structural Object class for = RootDSE ? At the present the RootDSE is kinda defined. Newer attributes if = any are added to it on a a case by case basis and does go through the IEFT = WG check.=20 SG Novell Inc work 801-861-5190 >>> "Kurt D. Zeilenga" 03/09/00 04:20PM >>> At 02:48 PM 3/9/00 -0700, Ed Reed wrote: >1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with = no attributes defined at all. =20 >2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST = {cn} and normal naming rules for most foks to use they way I envision = they'll use it (by decorating them with AUXILIARY classes). That's exactly what I had in mind all a long. But Mark's suggestion of a single STRUCTURAL class with MAY cn is works as well. I really don't understand the 'naming rule' issue with MUST vs. MAY. One additional comment: We need a STRUCTURAL object class for the Root DSE. This object class would have no naming attributes... and, in fact, doesn't need to MAY/MUST any attributes. Ie: ( NAME 'LDAPentry' SUP 'top' STRUCTURAL ) My question is, does it make sense to define subentry oc's in terms of LDAPentry? I would guess "no" as a entry and subentries are quite different. Anyways, food for thought. --=_2871D584.DFBEBC84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Kurt,
  What is the reason behind the need to have a structural Object = class=20 for RootDSE ? At the present the RootDSE is kinda defined. Newer attributes= if=20 any are added to it on a a case by case basis and does go through the IEFT = WG=20 check.
 
SG
Novell Inc
work 801-861-5190


>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> = 03/09/00=20 04:20PM >>>
At 02:48 PM 3/9/00 -0700, Ed Reed wrote:
>1)= =20 create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no=20 attributes defined at all. 
>2) create a STRUCTURAL class, = derived=20 from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks = to=20 use they way I envision they'll use it (by decorating them with = AUXILIARY=20 classes).

That's exactly what I had in mind all a long.  But = Mark's=20 suggestion
of a single STRUCTURAL class with MAY cn is works as = well.  I=20 really
don't understand the 'naming rule' issue with MUST vs. MAY.
One=20 additional comment:

We need a STRUCTURAL object class for the = Root=20 DSE.  This object
class would have no naming attributes... and, in = fact,=20 doesn't
need to MAY/MUST any attributes.  Ie:
   = (=20 <oid> NAME 'LDAPentry' SUP 'top' STRUCTURAL )

My question is, = does=20 it make sense to define subentry oc's
in terms of LDAPentry?  = I=20 would guess "no" as a entry and
subentries are quite different. &nb= sp;=20 Anyways, food for thought.

--=_2871D584.DFBEBC84-- From list@netscape.com Thu Mar 9 18:39:18 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06525 for ; Thu, 9 Mar 2000 18:39:16 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA25173; Thu, 9 Mar 2000 15:36:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA02776; Thu, 9 Mar 2000 15:38:38 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 15:38:38 -0800 (PST) Message-Id: <3.0.5.32.20000309153827.0095c1c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 09 Mar 2000 15:38:27 -0800 To: "Sukanta Ganguly" From: "Kurt D. Zeilenga" Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Cc: "Ed Reed" , , , , , , , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"hmLDNC.A.Er.9XDy4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 04:29 PM 3/9/00 -0700, Sukanta Ganguly wrote: >What is the reason behind the need to have a structural >Object class for RootDSE ? The RootDSE, like any other entry, needs structure (per the X.500 model). Per previous discussions (see archives), a structural object class was going to be defined (by Mark Wahl) for LDAPv3 revised specifications. Kurt From list@netscape.com Fri Mar 10 00:23:22 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25185 for ; Fri, 10 Mar 2000 00:23:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA01509; Thu, 9 Mar 2000 21:19:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id VAA13874; Thu, 9 Mar 2000 21:22:05 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 21:22:05 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 09 Mar 2000 22:21:32 -0700 From: "Jim Sermersheim" To: , , , , , Cc: , , "Mark Hinckley" Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"D6MPhB.A.gYD.8ZIy4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA25185 To satisfy X.500, I believe that the LDAPSubentry object class can be STRUCTURAL and not include any attributes. From my reading, the attributes specified in the name form don't need to be made up of the attributes specified in the object class definition. The text I'm reading is in Section 12.6.2 of X.501: "The RDN attribute (or attributes) need not be chosen from the list of permitted attributes of the structural object class as specified in its structural or alias object class definition". I may be mis-reading that, but I don't think so. There also may be directory implementations that require naming attributes to be listed in the object class's MUST or MAY list (I know of at least one). Jim >>> "Ed Reed" 3/9/00 2:58:31 PM >>> Back in November and at the IETF meeting in Washington, we discussed whether LDAPsubentry should be STRUCTURAL or ABSTRACT in definition. Mark has pointed out that MAY would address Kurt's objection to MUST {cn}, but that leaves the many folks out there who define naming rules with a problem, when there are (possibly) no attributes defined on the class at all (cn is the only attribute declared for the ldapsubentry class definition). Frankly, those folks who DO define naming attributes and naming rules will have to deal in some way with other systems who don't, but that's a different discussion I think. I think the discussion in Washington concluded that we should 1) leave the class STRUCTURAL 2) leave MUST {cn} in the definition 3) encourage Kurt to derive a new subclass of LDAPsubentry for his special-purpose class, which defines the other attribute he will use to actually name his entries - meaning that yes, he will need to provide a (possibly useless, but not necessarily unique) value for the cn value Erik's argument, that to make it Auxiliary would require a proliferation of new structural types, each with their own new naming rules, is what finally persuaded me to avoid that approach. The consequences of blithly ignoring the operational experience of the X.500 community was also important. It will be easier, by far, for most people to treat LDAPsubentry as STRUCTURAL, and then to decorate it with additional attributes for their particular needs, than to require each new use to define a new STRUCTURAL class with it's own naming rules. As I think about it, though, there is one way to make both camps happy: 1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. 2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). Such an approach would violate the "fewer classes is better" rule. But I think it would satisfy both Kurt and the X.500 folks. This is the only issue standing in the way of a last call. Any final words? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM From list@netscape.com Fri Mar 10 02:44:33 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20292 for ; Fri, 10 Mar 2000 02:44:32 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id XAA10086; Thu, 9 Mar 2000 23:41:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id XAA09394; Thu, 9 Mar 2000 23:43:11 -0800 (PST) Resent-Date: Thu, 9 Mar 2000 23:43:11 -0800 (PST) From: in_the_market@winning.com Date: Fri, 10 Mar 2000 02:32:34 -0400 Subject: 6.Investors READ THIS! To: lftavares@msn.com Message-id: <2F099F658EA@UCENGLISH.MCM.UC.EDU> X-Mailer: Internet Mail Service [9.3.1966.48] (Win95; I) Content-type: text/html Sensitivity: Public X-See-Also: 02437462F X-Accept-Language: en MessageID: X-Other-References: 0C5D30BA1 Resent-Message-ID: <"NO8zT.A.gSC.OeKy4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com -The following is an excerpt from a Telecommunications Industry Report developed by OTC Investor and sent to you as a service of Diamonds in the Rough. After this industry introduction, you will have an opportunity to request the full industry report and more information about three small cap opportunities in this exciting sector.

Telecom Sector Report
One of the world's leading industries is undergoing a revolution. Telecommunications is changing at an astounding speed, driven by the convergence of technologies and demand for high-speed data and media anytime and anywhere. Television, the Internet, and wireless technology are all converging enabling people to access all of these mediums through one wireless handset. The dramatic reshaping of these industries, requires a tremendous amount of investment in new technologies. The dynamic changes in the huge and growing sector offers potential investors excellent opportunities in the years ahead.

When the telecommunications revolution began over a century ago, no one could have predicted where it would lead: telephones in nearly every household in the industrialized nations; the development of the radio, the broadcast television, cable television; the globe-spanning Internet; portable, personal satellite phones; the complete digitization of communications. U.S. Spending on Telecommunications topped $517 Billion in 1999 and according to MultiMedia Telecommunications Association forecasts, total U.S. spending for telecom equipment and services will grow to $794 billion in 2003. More broadly defined, the communications industry accounts for one seventh of the U.S. economy, a share worth $1 trillion annually and is growing at a rate twice as fast as the overall economy.

By far, the fastest growing segment of the telecom market is in the burgeoning mobile and wireless sector. From its invention only twenty years ago, to today the number of users continues to grow exponentially. According to the Cellular Telecommunications Industry Association, US wireless subscribers for the 12 month period ending June 1999 were up 26 percent over the previous year, totaling over 76 million. Wireless communications services - including analog cellular, digital cellular, personal communications services (PCS), pagers, specialized mobile radio (SMR) and low-orbiting satellites - are easier and cheaper to establish than wireline services and are becoming increasingly important on a global scale. Additionally, prices for wireless products and services dropped dramatically over the last decade and currently more than 40 percent of U.S. households own either a wireless phone or a pager. Adoption and usage rates are even higher in some European countries.

We have found several very promising opportunities in the telecom sector. The first is a publicly traded technology firm, specializing in wireless communications devices. The company manufactures high-tech electronic components such as AlphaTrak, a global positioning systems (GPS) unit that tracks and monitors shipping vehicles, helping to facilitate just-in-time manufacturing. The company will soon begin producing the DebitFone, a prepaid cellular phone system available fully configured, through vending machines. The company has signed a Letter of Agreement to acquire 100% of VENDAPIN, LLC, the patent holder of a newly developed pre-paid calling card machine that will help to eliminate billions of dollars of fraud in the pre-paid calling card industry.

For the full Telecom Industry Report and more information about the companies described in this mailing:[CLICK HERE]


Emerging Markets - Hot Spot For Wireless Growth

Demand for wireless communications will grow even faster in developing markets as entire economies bypass analog technology and jump straight to digital. More than 2 of the six billion people in the world have yet to place a single phone call. Global telecommunication companies see these numbers as tremendous opportunities, and they are all hoping to be major players in the developing economies of regions such as: Latin America, South East Asia and Africa. Because of favorable trade rules for telecommunications with and a surge of privatization initiatives, companies operating in Latin American offer perhaps some of the most promising investment opportunities. As the wireless industry continues to grow exponentially, there are a variety of ways to profit from this growth. Aside from companies digging up roads to lay down fiber optic cable, new technologies are enabling more flexible satellite and airborne networks as an alternative to underground fiber optics.

Our emerging market play in the wireless sector is the exclusive provider of the Airborne Relay Communications System (ARC System), an innovative, new wireless telecommunications technology. The ARC System is a high-altitude aircraft-relay telecommunications system designed to replace or augment traditional ground-based wireless infrastructures, as well as high and low earth orbiting satellites - at a fraction of the cost of such systems. It is an ideal solution for providing wireless access via AMPS, GSM, TDMA, or CDMA modulation schemes, as well as wireless fixed applications and Internet solutions to developing countries lacking terrestrial infrastructures, and to developed countries expanding coverage in existing wireless markets. The ARC System offers a substantial cost-savings vs. satellite or conventional terrestrial infrastructures, and can be installed in a fraction of the time it takes to build out a terrestrial infrastructure.

The company we have identified has received a letter of intent from a major Brazilian telecommunications service provider, stating their intention to purchase ARC Systems as an integral part of their operational network. After the successful completion of the ARC System ALPHA testing in September 1999, contract negotiations were entered in to for its first production system. The company has also received licenses from ANATEL (Brazilian FCC equivalent). More details regarding terms of a potential contract should emerge this quarter.

Investors who want more information about the telecom sector and the small cap opportunities we've identified should click on the link below:[CLICK HERE]

Demand For Bandwidth

Second only to the trend towards wireless is the demand for more bandwidth capacity via fiber optic cable. Optical fiber is becoming the new medium chosen by local and long-distance phone companies, as well as cable companies, to meet the demands for greater bandwidth and faster transmission speeds required by new technologies. The growth of the Internet and the emergence of multimedia applications such as videoconferencing are the driving forces behind the move to fiber optics. Overall spending in the fiber optics market, by carriers and others, has risen from $4.1 billion in 1990 to $12 billion in 1998. Fiber optic equipment, including transport equipment and digital cross-connects, is projected to compound at annual growth rates of 23 percent through 2002, increasing from $10 billion in 1998 to $22.9 billion in 2002. Companies that can offer telecom equipment companies new technologies to expand bandwidth over existing fiber optic cable will be well rewarded, as will early investors in these companies.

Our Bandwidth play is a public company that is developing new applications for its state-of-the-art, proprietary optical and light technologies. Its primary activity has been using a patented technique to acoustically manage light. The core Acoustical Optical Management Technology has a wide and potentially lucrative spectrum of applications, some of which are already producing earnings. Management and industry analysts believe that the greatest application potential may be realized in Digital Communications, through revolutionary technology that can transmit 65,536 separate channels of light over distance in a singular optic fiber. This quantum leap in optimizing capacity of existing fiber networks may be capable increase to the current internet backbone capacity 400-fold! We believe you will be as impressed as we are with the breadth and potential of the company's technology.

For the research report on the telecom sector and the three small cap opportunities described herein, click: [CLICK HERE]
======================================
if you wish you can be placed on our PERMANENT REMOVE LIST just,
CLICK HERE to be permanently REMOVED

====================================== WSI-0309B From list@netscape.com Fri Mar 10 03:59:56 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13394 for ; Fri, 10 Mar 2000 03:59:55 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA22853; Fri, 10 Mar 2000 00:54:11 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA23443; Fri, 10 Mar 2000 00:58:30 -0800 (PST) Resent-Date: Fri, 10 Mar 2000 00:58:30 -0800 (PST) From: 0M580I7R8@hotmail.com DATE: 10 Mar 00 1:25:51 AM Message-ID: <6vYraZXbn0pSS6o3l92> SUBJECT: Turn Key System For MLM Success Resent-Message-ID: <"-_qQPB.A.5tF.1kLy4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I'm really angry. As angry as I've ever been about anything. I get calls from prople every day that have been burned over and over by fast buck artists selling a lot of hype and saying how easy it is to make a lot of money in network marketing. As a matter of fact, if you told me a year ago I would be writing an email like this, I would have told you, you were nuts! But something changed for me recently.... Now, five months later, my life looks a lot different. I work my own hours from home home, and will make over $100,000 in 2000, then double and probably triple it in 2001. So even though I didn't believe it, I built a solid income in network marketing in just a few short months. And whether you believe it or not, so can you. To learn how, call 1-800-242-0363 ext. 2050 (Prerecorded message) Sincerely, Michael J. Trend ************************************************************* To be removed from our list mailto: Wasserman3562@hotmail.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTE: DON'T COMPLAIN TO HOTMAIL.COM, AS THE ACCOUNT WILL BE SHUT DOWN, AND WE WILL NOT BE ABLE TO REMOVE YOU FROM OUR LIST. WE DON'T WANT TO MAIL THOSE WHO DO NOT WANT US TO. ************************************************************* From list@netscape.com Fri Mar 10 10:09:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13562 for ; Fri, 10 Mar 2000 10:09:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA14991; Fri, 10 Mar 2000 07:03:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA00580; Fri, 10 Mar 2000 07:08:06 -0800 (PST) Resent-Date: Fri, 10 Mar 2000 07:08:06 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Fri, 10 Mar 2000 07:59:01 -0700 From: "Ed Reed" To: Cc: , , , , , "Ed Reed" , Subject: draft-ietf-ldup-subentry-02.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_4C15B0D8.5435596C" Resent-Message-ID: <"4cThCC.A.PI.U_Qy4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_4C15B0D8.5435596C Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Please publish the attached internet draft, a product of the LDUP and = LDAPEXT (joint effort) working groups. It replaces draft-ietf-ldup-subentr= y-01.txt. The abstract is the same: This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class. To the working groups: I think this is ready for last call, now (joint, = as I recall). The only changes since the previous draft are to make cn an = optional, rather than mandatory, (MAY rather than MUST) attribute, remove = a gratuitous reference to the LDUP Information Model document, add the = LDAPEXT mailing list and adjust the author address for my new contact = information. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM --=_4C15B0D8.5435596C Content-Type: text/plain Content-Disposition: attachment; filename="draft-ietf-ldup-subentry-02.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT=20 draft-ietf-ldup-subentry-02.txt=20 Ed Reed=20 Reed-Matthews, Inc.=20 March 9, 2000=20 =20 LDAP Subentry Schema=20 1. Status of this Memo=20 This document is an Internet-Draft and is in full=20 conformance with all provisions of Section 10 of RFC2026.=20 =20 Internet-Drafts are working documents of the Internet=20 Engineering Task Force (IETF), its areas, and its working=20 groups. Note that other groups may also distribute working=20 documents as Internet-Drafts. =20 =20 Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by=20 other documents at any time. It is inappropriate to use=20 Internet-Drafts as reference material or to cite them other=20 than as "work in progress." =20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt. =20 =20 The list of Internet-Draft Shadow Directories can be=20 accessed at http://www.ietf.org/shadow.html.=20 =20 This Internet-Draft expires on September 9, 2000.=20 2. Abstract=20 This document describes an object class called ldapSubEntry=20 which MAY be used to indicate operations and management=20 related entries in the directory, called LDAP Subentries. =20 This version of this document is updated with an assigned=20 OID for the ldapSubEntry object class.=20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=20 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",=20 and "OPTIONAL" in this document are to be interpreted as=20 described in RFC 2119 [RFC2119]. The sections below=20 reiterate these definitions and include some additional=20 ones.=20 Reed [Page 1]=20 Expires September 9, 2000 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 3. Definition=20 3.1 ldapSubEntry Class=20 ( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry' =20 DESC 'LDAP Subentry class, version 1' =20 SUP top STRUCTURAL =20 MAY ( cn ) ) =20 The class ldapSubEntry is intended to be used as a super=20 class when defining other structural classes to be used as=20 LDAP Subentries. The presence of ldapSubEntry in the list=20 of super-classes of an entry in the directory makes that=20 entry an LDAP Subentry. Object classes derived from=20 ldapSubEntry are themselves considered ldapSubEntry=20 classes, for the purpose of this discussion.=20 LDAP Subentries MAY be named by their commonName attribute=20 [LDAPv3]. Other naming attributes are also permitted.=20 LDAP Subentries MAY be containers, unlike their [X.501]=20 counterparts.=20 LDAP Subentries MAY be contained by, and will usually be=20 located in the directory information tree immediately=20 subordinate to, administrative points and/or naming=20 contexts. Further (unlike X.500 subentries), LDAP=20 Subentries MAY be contained by other LDAP Subentries (the=20 way organizational units may be contained by other=20 organizational units). Deep nestings of LDAP Subentries=20 are discouraged, but not prohibited.=20 LDAP Subentries SHOULD be treated as "operational objects"=20 in much the same way that "operational attributes" are not=20 regularly provided in search results and read operations=20 when only user attributes are requested). =20 LDAP servers SHOULD implement the following special=20 handling of ldapSubEntry entries:=20 a) search operations which include a matching criteria=20 "objectclass=3DldapSubEntry" MUST include entries derived=20 from the ldapSubEntry class in the scope of their=20 operations; =20 b) search operations which do not include a matching=20 criteria "objectclass=3DldapSubEntry" MUST IGNORE entries=20 Reed [Page 2]=20 Expires September 9, 2000=20 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 derived from the ldapSubEntry class, and exclude them from=20 the scope of their operations.=20 The combination of SHOULD and MUST in the special handling=20 instructions, above, are meant to convey this: Servers=20 SHOULD support this special handling, and if they do they=20 MUST do it as described, and not some other way.=20 4. Security Considerations=20 LDAP Subentries will frequently be used to hold data which=20 reflects either the actual or intended behavior of the=20 directory service. As such, permission to read such=20 entries MAY need to be restricted to authorized users. =20 More importantly, IF a directory service treats the=20 information in an LDAP Subentry as the authoritative source=20 of policy to be used to control the behavior of the=20 directory, then permission to create, modify, or delete=20 such entries MUST be carefully restricted to authorized=20 administrators.=20 5. References=20 [LDAPv3] S. Kille, M. Wahl, and T. Howes, "Lightweight=20 Directory Access Protocol (v3)", RFC 2251, December 1997=20 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993=20 6. Copyright Notice=20 Copyright (C) The Internet Society (1999). All Rights=20 Reserved. =20 =20 This document and translations of it may be copied and=20 furnished to others, and derivative works that comment on=20 or otherwise explain it or assist in its implementation may=20 be prepared, copied, published and distributed, in whole or=20 in part, without restriction of any kind, provided that the=20 above copyright notice and this paragraph are included on=20 all such copies and derivative works. However, this=20 document itself may not be modified in any way, such as by=20 removing the copyright notice or references to the Internet=20 Reed [Page 3]=20 Expires September 9, 2000=20 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 Society or other Internet organizations, except as needed=20 for the purpose of developing Internet standards in which=20 case the procedures for copyrights defined in the Internet=20 Standards process must be followed, or as required to=20 translate it into languages other than English.=20 =20 The limited permissions granted above are perpetual and=20 will not be revoked by the Internet Society or its=20 successors or assigns.=20 =20 This document and the information contained herein is=20 provided on an "AS IS" basis and THE INTERNET SOCIETY AND=20 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL=20 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED=20 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL=20 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=20 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."=20 7. Acknowledgements=20 The use of subEntry object class to store Replica and=20 Replication Agreement information is due primarily to the=20 lucid explanation by Mark Wahl, Innosoft, of how they could=20 be used and extended.=20 =20 The IETF takes no position regarding the validity or scope=20 of any intellectual property or other rights that might be=20 claimed to pertain to the implementation or use of the=20 technology described in this document or the extent to=20 which any license under such rights might or might not be=20 available; neither does it represent that it has made any=20 effort to identify any such rights. Information on the=20 IETF's procedures with respect to rights in standards-track=20 and standards-related documentation can be found in BCP-11.=20 Copies of claims of rights made available for publication=20 and any assurances of licenses to be made available, or the=20 result of an attempt made to obtain a general license or=20 permission for the use of such proprietary rights by=20 implementors or users of this specification can be obtained=20 from the IETF Secretariat.=20 =20 The IETF invites any interested party to bring to its=20 attention any copyrights, patents or patent applications,=20 or other proprietary rights which may cover technology that=20 may be required to practice this standard. Please address=20 the information to the IETF Executive Director.=20 Reed [Page 4]=20 Expires September 9, 2000=20 =0C INTERNET-DRAFT 9 March 2000=20 LDAP Subentry Schema=20 8. Author's Address=20 Edwards E. Reed=20 Reed-Matthews, Inc.=20 1064 E 140 North=20 Lindon, UT 84042=20 USA=20 E-mail: eer@oncalldba.com =20 =20 LDUP Mailing List: ietf-ldup@imc.org =20 LDAPEXT Mailing List: ietf-ldapext@netscape.com=20 Reed [Page 5]=20 Expires September 9, 2000=20 =0C --=_4C15B0D8.5435596C-- From list@netscape.com Fri Mar 10 14:45:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19171 for ; Fri, 10 Mar 2000 14:45:07 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA24493; Fri, 10 Mar 2000 11:38:22 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA23309; Fri, 10 Mar 2000 11:42:47 -0800 (PST) Resent-Date: Fri, 10 Mar 2000 11:42:47 -0800 (PST) Message-Id: <4.2.2.20000310133633.00a451c0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 10 Mar 2000 13:41:05 -0600 To: internet-drafts@ietf.org, ietf-ldapext@netscape.com From: Ellen Stokes Subject: please publish (draft-ietf-ldapext-acl-model-05.txt) Cc: djbyrne@us.ibm.com, blakley@dascom.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_15199668==_" Resent-Message-ID: <"xe64ZC.A.PrF.0AVy4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --=====================_15199668==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Please publish. ldapext folks: Attached is the access control model draft I sent to the drafts editor. Also attached is a summary of the changes in this draft - I think I've reflected all email since October in this draft. Comments welcome. I'd like to see this version go to last call... Thanks. Ellen --=====================_15199668==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="draft-ietf-ldapext-acl-model-05.txt" Content-Transfer-Encoding: quoted-printable Internet-Draft E. Stokes LDAP Extensions WG D. Byrne Intended Category: Standards Track IBM Expires: 10 September 2000 B. Blakley Dascom 10 March 2000 Access Control Model for LDAP STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments and suggestions on this document are encouraged. Comments on this document should be sent to the LDAPEXT working group discussion list: ietf-ldapext@netscape.com COPYRIGHT NOTICE Copyright (C) The Internet Society (1997). All Rights Reserved. ABSTRACT This document describes the access control model for the Lightweight Directory Application Protocol (LDAP) Stokes, Byrne, Blakley Expires 10 September 2000 [Page 1] =0C Internet-Draft Access Control Model 10 March 2000 directory service. It includes a description of the model, the LDAP controls, and the extended operations to the LDAP protocol. The current LDAP APIs are sufficient for most access control operations. An API (in a separate document) is needed for the extended operation getEffectiveAccess and specifyCredentials. The keywords "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [Bradner97]. 1. Introduction The ability to securely access (replicate and distribute) directory information throughout the network is necessary for successful deployment. LDAP's acceptance as an access protocol for directory information is driving the need to provide an access control model definition for LDAP directory content among servers within an enterprise and the Internet. Currently LDAP does not define an access control model, but one is needed to ensure consistent secure access across heterogeneous LDAP implementations. The major objective is to provide a simple, but secure, highly efficient access control model for LDAP while also providing the appropriate flexibility to meet the needs of both the Internet and enterprise environments and policies. This document defines the model and the protocol extensions (controls and extended operations). 2. Overview Access Control mechanisms evaluate requests for access to protected resources and make decisions about whether those requests should be granted or denied. In order to make a grant/deny decision about a request for access to a protected resource, an access control mechanism needs to evaluate policy data. This policy data describes security-relevant characteristics of the requesting subject and the rules which govern the use of the target object. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 2] =0C Internet-Draft Access Control Model 10 March 2000 The access control model defines - A wire protocol for interoperability: The existing LDAP protocol flows for add, delete, modify, and search are used to manipulate access control information. There is an additional LDAP control and extended protocol operation defined, getEffectiveRights, to further help management of access control information. - A set of access control information (ACI) attributes for application portability: These attributes are used as input to the LDAP APIs so access control information can be addressed uniformly independent of how that information is addressed and stored at the server. These same attributes appear in LDIF output for interchange of access control information. - A set of attributes to identity the access control mechanisms supported by a server and in a given part of the namespace. Encoding of access control information on the wire is per the LDAPv3 specifications. The instantiation of an access control model at the directory server is not defined in this document. No mechanisms are defined in this document to control access to access control information or for storage of access control information at the server; this is vendor dependent. A separate requirements document for access control exists. The access control model used the requirements documents as a guideline for the development of this specification and are reflected in this specification to the extent that the working group could agree on an access control model. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 3] =0C Internet-Draft Access Control Model 10 March 2000 3. Terminology An "access control list" contains the access control policy information controlling access to an object or collection of objects. An access control list consists of a set of access control list entries. An "access control list entry" defines a single subject security attribute's granted rights for the objects governed by the access control list to which it belongs. The "access control information" (aci) for an object or a collection of objects defines which subject security attributes entitle a subject to which granted rights. The access control information for an object may be stored in an access control list. An "access decision" is a boolean-valued function which answers the question: "can the subject with these subject security attributes perform this operation on this object?" An "access decision function" is an algorithm which makes an access decision based on subject security attributes, access control information, an object identifier, and an operation name (possibly augmented by additional contextual information). An "access decision function interface" is a programmatic interface through which applications can request an access decision. An "access identity" is an identity which is used by an access decision function to make an access decision. An "audit identity" is an identity which does not, in the absence of additional information, enable a party receiving and examining it to determine which subject it belongs to. A "credential" is a collection of subject security attributes. "effective rights" are the complete set of rights a subject is entitled to based on all access control lists Stokes, Byrne, Blakley Expires 10 September 2000 [Page 4] =0C Internet-Draft Access Control Model 10 March 2000 which apply to a specific object and based on all of the subject's security attributes. "granted rights" are the complete set of rights an access control list entitles a subject to based on a specific subject security attribute. A "group" is a privilege attribute asserting a subject's membership in the collection of subjects whose name is that of the group. An "identity" is a subject security attribute which is unique to a single subject. A "privilege attribute" is a subject security attribute which may be shared by several subjects. "required rights" are the complete set of rights needed to authorize a requester to perform a specific operation on an object of a specific type. A "right" is the basic unit of access control administration. For each object type in an information system, a security administrator defines a set of required rights for each operation. For each object in the system, a security administrator defines a set of granted rights for each subject security attribute. When an access decision is required, an access decision function checks to make sure that the requester's subject security attributes have been granted all required rights needed to perform the requested operation on the specified target object. A "role" is a privilege attribute asserting a subject's organizational position and entitlement to perform the operations appropriate to that organizational position. A "subject' is an entity which initiate actions in an information system. A "subject security attribute" is a defined property which is used by a security policy evaluation system to make policy decisions. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 5] =0C Internet-Draft Access Control Model 10 March 2000 4. The Model The access control mechanism described in this draft addresses these activities: - Definition of subject security attributes information - Definition of access control policy - Retrieval of subject security attributes - Retrieval of effective access rights - Externalization of access control policy information 4.1 Access Control Information Model This document does not define formats for storage of access control information; it does define the operational semantics of access control operations. Stokes, Byrne, Blakley Expires 10 September 2000 [Page 6] =0C Internet-Draft Access Control Model 10 March 2000 The diagram below illustrates the componentry of a LDAP system and the placement of the function specified in this draft. +-------------+ | Application |<--attrs to address ACI +-------------+ - ldapACI +--------+ - policyOwner | LDAP | | Client | +--------+ | | <-- LDAP control | - getEffectiveAccess | | <-- LDAP extended operation | - getEffectiveAccess v +-----------------------------+ | LDAP Server (e.g. SLAPD) | +-----------------------------+ . | . | . | . | v v +----------+ +-----------+ | Access | | |<-attrs to define | Control |<--| Datastore | access control mechanisms | Manager | | | - supportedACIMechanisms +----------+ +-----------+ - aCIMechanisms LDAP clients use the control and extended operation specified in this document to administer access control policy enforced by LDAP servers. Servers may store access control information in any way they choose. In particular, servers may use the access control mechanisms of their datastores to store and enforce LDAP access control, or they may implement access control managers external to their datastores. Datastores and external access control managers may implement any access control rule syntax and semantics they choose, as long as the semantics are compatible with that defined in the section titled "Operational Semantics of Access Control Operations". Stokes, Byrne, Blakley Expires 10 September 2000 [Page 7] =0C Internet-Draft Access Control Model 10 March 2000 The access control administration mechanisms specified in this document are neutral with respect to policy inheritance mechanisms, explicit vs. implicit denial, and group nesting. 5. Access Control Mechanism Attributes There are several attributes defined associated with access control. Two attributes are defined to identify which access control mechanisms are supported by a given server and by a given subtree: supportedACIMechanisms and aCIMechanisms. 5.1 Root DSE Attribute for Access Control Mechanism The server advertises which access control mechanisms it supports by inclusion of the 'supportedACIMechanisms' attribute in the root DSE. This attribute is a list of OIDs, each of which identify an access control mechanism supported by the server. ( NAME 'supportedACIMechanisms' DESC list of access control mechanisms supported by this directory server SYNTAX LDAPOID USAGE dSAOperation ) The access control mechanism defined is: LDAPv3 Other vendor access control mechanisms can be defined (by OID) and are the responsibility of those vendors to provide the definition and OID. 5.2 Subschema Attribute for Access Control Mechanism A given naming context must provide information about which access control mechanisms are in effect for that portion of the namespace. The following attribute must be in each subschema entry associated with a naming Stokes, Byrne, Blakley Expires 10 September 2000 [Page 8] =0C Internet-Draft Access Control Model 10 March 2000 context whose access control mechanism is different from adjacent naming contexts supported by that directory server. aCIMechanisms lists the values (list of OIDs) that defines the access control mechanism in effect for the scope of that subschema entry. More than one mechanism may be in effect for the scope of that subschema entry. ( NAME 'aCIMechanisms' DESC list of access control mechanisms supported in this subtree SYNTAX LDAPOID USAGE dSAOperation ) 6. Access Control Information Attributes The intent of the following attribute definitions is to design a common interchange format. Any given LDAP server should be able to translate the below defined attributes into a meaningful operation requests. Each server should be able to understand the attributes; there should not be any ambiguity into what any part of the syntax means. While the end goal is to have a common behavior model between different LDAP server implementations, the attribute definition alone will not ensure identical ACL processing behavior between servers. The semantics of how a server interprets the ACI syntax are defined in the "Operational Semantics of Access Control' section of this document. Additionally, while the server must recognize and act on the attribute when received over the wire, there are no requirements for the server to physically store this attribute. The attribute definition maintains an assumption that the receiving server supports inheritance within the security model. If the server does not support inheritance, the receiving server must expand any inherited information Stokes, Byrne, Blakley Expires 10 September 2000 [Page 9] =0C Internet-Draft Access Control Model 10 March 2000 based on the scope flag. If the server does not support partial inheritance and both the entry and subtree scope are used, then entry is the prevailing scope. Two attributes are defined so access control information (ACI) can be addressed in a server independent of server implementation. These attributes are used in typical LDAP APIs and in LDIF output of ACI. These two attributes may be queried or set on all directory objects: ldapACI and policyOwner. Their BNF=20and definitions are defined below. 6.1 The BNF < ldapACI > ::=3D < acl entry syntax > < acl entry syntax > ::=3D + '#' + + '#' + < rights > + '#' + < dnType > + '#' + < subjectDn > < policyOwner > ::=3D < familyOid > + '#' + + '#' +< dnType > + '#' + < subjectDn > < subjectDn > ::=3D < printable string > | "public" | "this" < familyOid > ::=3D < oid > ::=3D "entry" | "subtree" < dnType > ::=3D "access-id" | "role" | "group" | "subtree" | "ipAddress" | "kerberosID" | < kerberosID > ::=3D < userID > + '@' + < realm > < userID > ::=3D < printableString > < realm > ::=3D < printableString > < rights > ::=3D "grant" + ';' + + ';'+ | "deny" + ';' + + ';'+ | = "grant"+';'++';'+"deny"+';'++';'+ < permissions > ::=3D [ ] | [ Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 10] =0C Internet-Draft Access Control Model 10 March 2000 + [ ',' + ] ]* < attr > ::=3D ["collection" + ':' + [ "[all]" | "[entry]" | ] ] | ["attribute" + ':' ] < permission > ::=3D "a" | "d" | "r" | "s" | "w" | "c" | "e" | "b" These are the permissions defined for the IETF LDAP family OID. "a" corresponds to add "d" corresponds to delete "r" corresponds to read "s" corresponds to search "w" corresponds to write "c" corresponds to compare "e" corresponds to editDN "b" corresponds to browseDN 6.2 Other Defined Parameters This section defines additional parameters that are used in the two attributes that address access control information. 6.2.1 Families and Rights The familyOID tells what permission set etc. will follow in the string. This allows a different permission set, scope etc., but with the same syntax. The following family is defined: IETF-LDAPv3 Other families can be defined (by OID). It is the responsibility of those parties to provide the definition and OID. 6.2.1.1 IETF-LDAPv3 Family Access rights can apply to an entire object or to Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 11] =0C Internet-Draft Access Control Model 10 March 2000 attributes of the object. Each of the LDAP access rights are discrete. One permission does not imply another permission. The rights which apply to attributes and the entry parallel the type of ldap operations that can be performed. Rights which apply to attributes: r Read Read attribute values w Write Write attribute values s Search Search entries with specified attributes c Compare Compare attributes Rights that apply to an entire entry: a Add Add an entry below this entry d Delete Delete this entry e EditDN Edit an entry's DN b BrowseDN Browse an entry's DN When searching, the ldap search filter specifies the returned set of attributes. To do the search, browse (b) must be set for the entry (you can search only entries that you have permission to search so you can't discover things you don't have permission to) and search (s) must be set for all attributes used in the filter if you are testing for existence, otherwise search (s) and read (r) must be set for all attributes used in the filter because the filter specifies a test for other than existence. For a search to return attribute names only, search (s) must be set for the attribute. For a search to return attribute names and values, search (s) and read (r) must be set for the attribute. Search (s) implies knowledge of the attribute; read (r) implies knowledge of the value. 6.2.2 DN Types The following DN Types strings are defined and MUST be supported: - access-id Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 12] =0C Internet-Draft Access Control Model 10 March 2000 - group - role The following DN Types strings are defined and SHOULD be supported: - ipAddress - kerberosID An access-id is a non-collection (non-group and non-role objects) DN that can be authenticated. groupOfNames and groupOfUniqueNames (or subclasses from those object classes) must be recognized as a collection object. This aids in interoperability during replication. Other parties can (and will) define other DN Types. It is the responsibility of those parties to provide the definition. 6.3 Basic ACI Attribute (ldapACI) ( NAME 'ldapACI' DESC 'ldap access control information' EQUALITY caseIgnoreMatch SYNTAX directoryString USAGE directoryOperation ) Within the access control syntax, the family OID describes the permissions, dnType, subjectDn and scope that will be found in the following string. If the OID within the ldapACI attribute is listed as other than the IETF-LDAPv3 family OID, the syntax is the same, but one or more of the scope, dnType, subjectDn or permissions may vary from the defined syntax. Within the access control syntax, there is a string which describes the rights. This is a composite of the permissions and resources to which the subject is being Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 13] =0C Internet-Draft Access Control Model 10 March 2000 granted or denied access. The set of permissions is fixed. Either or both of the actions "grant" | "deny" may be used when creating or updating ldapACI. describes either an attribute name or an attribute collection. The keyword attribute indicates that the following printable string refers to an attribute name. If the string refers to an attribute not defined in the given server's schema, the server SHOULD report an error. The keyword "collection" indicates that the string that follows describes a group of attributes. The method for grouping attributes is server specific. Another option for the collection printable string is "[entry]". This is provided to describe permissions which apply to an entire object. This could mean actions such as delete the object, or add a child object. The third option for a collection is "[all]" which means the permission set should apply to all attributes. Even if the server does not support attribute grouping, it MUST recognize the "[all]" and "[entry]" keywords. If the server receives an unrecognized attribute collection name, the server SHOULD return an error. If the server supports grouping, the grouping is server and implementation specific. If the keyword "[all]" and another attribute are both specified within an aci, the more specific permission set for the attribute overrides the less specific permission set for "[all]". All permissions (for grant and deny) for an attribute and a given DN MUST be contained within one ldapACI value, i.e. (in abbreviated form) ldapACI: ...grant attr1 DN1 ldapACI: ...deny attr1 DN1 must be ldapACI: ...grant ... deny... attr1 DN1 Using the defined BNF it is possible for the permission string to be empty. The ACI ldapACI: 1.2.3.4#subtree#grant;; attribute:attr1#group#cn=3DDept XYZ,c=3DUS ldapACI: 1.2.3.4#subtree#grant;r,s; Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 14] =0C Internet-Draft Access Control Model 10 March 2000 collection:[all]#group#cn=3DDept XYZ,c=3DUS means that this group (Dept XYZ) is granted permission to read and search all attributes except attr1 because attr1 is more specific than "[all]". 6.3.1 LDAP Operations The attributes which are defined for access control interchange may be used in all LDAP operations. Within the ldapmodify-delete operation, the entire acl may be deleted by specifying dn: cn =3D some Entry changetype: modify delete: ldapACI In this case, the entry would then inherit its ACI from some other node in the tree depending on the server inheritance model. Similarly, if all values of ldapACI are deleted, then the access control information for that entry is defined by that implementation's inheritance model. 6.3.2 Grant/Deny Evaluation Rules More specific policies must override less specific ones (e.g. individual user entry in ACI takes precedence over group entry). Deny takes precedence over Grant. When there are conflicting ACI values, deny takes precedence over grant. Deny is the default when there is no access control information. Precendence of Scope Types (highest to lowest) - entry - subtree Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 15] =0C Internet-Draft Access Control Model 10 March 2000 Precedence of Privilege Attribute dnTypes within a scope (highest to lowest): - ipAddress - access-id, kerberosID (both same precedence) - group - role - subtree Although other types can be defined given the BNF, use of the well-known types aids in interoperability and operational consistency. 6.4 Policy Owner Attribute (policyOwner) ( NAME 'policyOwner' DESC 'Policy Owner Access Control Information' EQUALITY caseIgnoreMatch SYNTAX directoryString USAGE directoryOperation ) Policy ownership controls administrative subdomains. It can also control who has permission to set / change acls for implementations that do not have ACI controlling access to itself. If there are multiple policy owners it is implementation specific as to the behavior of whether policy owner #1 can override policy owner # 2. The syntax for policyOwner includes the 'scope' flag. Servers which do not support inheritance must expand the policyOwner inheritance similar to the expansion of the ACI. The scope and any inheritance hierarchy for policy ownership is distinct from any inheritance hierarchy defined for ACI values. If the policy owner is not specified for any object in the tree, behavior is implementation defined. For instance, if no object anywhere in the tree has a policy Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 16] =0C Internet-Draft Access Control Model 10 March 2000 owner, then the server could simply assert that the 'root DN' is considered the policy owner for all objects. An alternate approach might be that the implementation defines the entryDN to be the policy owner. 6.5 ACI Examples The examples use a family OID =3D 1.2.3.4 6.5.1 Attribute Definition The following two examples show an administrative subdomain being established. The first example shows a single user being assigned the policyOwner for the entire domain. The second example shows a group of IDs assigned to the policy Owner. policyOwner: 1.2.3.4#subtree#access-id#cn=3DHoyt policyOwner: 1.2.3.4#subtree#group#cn=3DSystem Owners,o=3DCompany The next example shows a ldapACI attribute where a group "cn=3DDept XYZ, c=3DUS" is being given permissions to read, search and compare attribute attr1. The permission applies to the entire subtree below the node containing this ACI. ldapACI:1.2.3.4#subtree#grant;r,s,c; attribute:attr1#group#cn=3DDept XYZ,c=3DUS The next example shows an ACI attribute where a role "cn=3DSysAdmins,o=3DCompany" is being given permissions to add objects below this node and read, search, and compare attributes attr2 and attr3. The permission applies to the entire subtree below the node containing this ACI. ldapACI: 1.2.3.4#subtree#grant;a; collection:[entry]#role#cn=3DSysAdmins,o=3DCompany ldapACI: 1.2.3.4#subtree#grant;r,s,c; attribute:attr2#role#cn=3DSysAdmins,o=3DCompany Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 17] =0C Internet-Draft Access Control Model 10 March 2000 ldapACI: 1.2.3.4#subtree#grant;r,s,c; attribute:attr3#role#cn=3DSysAdmins,o=3DCompany 6.5.2 Modifying the ldapACI Values Modify-Replace works as defined in the ldap oepration modify. If the attribute value does not exist, create the value. If the attribute does exist, replace the value. If the ldapACI value is replaced, all ldapACI values are replaced. A given ldapACI for an entry: ldapACI: 1.2.3.4#subtree#deny;r,w; collection:[all]#group#cn=3DDept ABC ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=3DDept XYZ perform the following change: dn: cn=3DsomeEntry changetype: modify replace: ldapACI ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all];#group#cn=3DDept LMN The resulting ACI is: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all];#group#cn=3DDept LMN ( ldapACI values for Dept XYZ and ABC are lost through the replace ) During an ldapmodify-add, if the ACI does not exist, the create the ACI with the specific ldapACI value(s). If the ACI does exist, then add the specified values to the given ldapACI. For example a given ACI: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=3DDept XYZ with a modification: Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 18] =0C Internet-Draft Access Control Model 10 March 2000 dn: cn=3DsomeEntry changetype: modify add: ldapACI ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=3DDept XYZ would yield an multi-valued aci of: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=3DDept XYZ ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=3DDept XYZ To delete a particular ACI value, use the regular ldapmodify - delete syntax Given an ACI of: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=3DDept XYZ ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=3DDept XYZ dn: cn =3D some Entry changetype: modify delete: ldapACI ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=3DDept XYZ would yield a remaining ACI on the server of ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=3DDept XYZ 6.5.3 Evaluation These examples assume that the ldapACI entries listed in each example are the only ACI which applies to the entry in question; if backing-store ACI also exists, the effective policy may be different from that listed in each example. See section 7 for a discussion of the semantics of ldapACI entries when backing-store ACI administration is also used. Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 19] =0C Internet-Draft Access Control Model 10 March 2000 Assume cn=3Djsmith is a member of group cn=3DG1. Assume cn=3Djsmith is a member of group cn=3DG2. Example #1 dn: o=3DXYZ, c=3DUS ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr1; #access-id#cn=3Djsmith,ou=3DABC,o=3DXYZ,c=3DUS ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr1; #group#cn=3DG1,ou=3DABC,o=3DXYZ,c=3DUS What rights does cn=3Djsmith have to attr1 of o=3DXYZ,c=3DUS? Read (r) access; access-id is higher precedence than group. Example #2 dn: o=3DXYZ, c=3DUS ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr2; #group#cn=3DG1,ou=3DABC,o=3DXYZ,c=3DUS ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr2; #group#cn=3DG2,ou=3DABC,o=3DXYZ,c=3DUS What rights does cn=3Djsmith have to attr2 of o=3DXYZ,c=3DUS? Read-write (r,w) access; ACI is combined because both dnTypes (group) have same precedence. Example #3 dn: o=3DXYZ, c=3DUS ldapACI: 1.2.3.4#subtree#grant;r,w;attribute:attr3; #group#cn=3DG1,ou=3DABC,o=3DXYZ,c=3DUS ldapACI: 1.2.3.4#subtree#deny;w;attribute:attr3; #group#cn=3DG2,ou=3DABC,o=3DXYZ,c=3DUS What rights does cn=3Djsmith have to attr3 of o=3DXYZ, c=3DUS? Read access; write is denied (deny has precedence over grant). Example #4 dn: o=3DXYZ, c=3DUS ldapACI: 1.2.3.4#subtree#grant;w;attribute:attr4; #access-id#cn=3Djsmith,ou=3DABC,o=3DXYZ,c=3DUS ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr4; #subtree#ou=3DABC,ou=3DXYZ,c=3DUS Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 20] =0C Internet-Draft Access Control Model 10 March 2000 What rights does cn=3Djsmith have to attr4 of o=3DXYZ, c=3DUS? Write (w); rights given to an access-id take precedence over those given to a subtree. 7. Operational Semantics of Access Control Operations The semantics of access control operations described in this document are defined operationally in terms of "histories". A history is a sequence of actions (x1, x2, ..., xN). 7.1 Types of actions We consider five types of actions: - LDAP Access Control Policy Update actions: invocations of ldap modify when used to add, delete, or replace the aci attribute; invocations of ldap add when used to add an entry with an aci attribute. A LDAP Access Control Policy Update action may replace the policy (by completely replacing the aci attribute with new policy information) or it may grant or deny specific rights while leaving others unaffected. - LDAP Access Control Policy Query operations: invocations of ldap search when used to retrieve the aci attribute; invocations of ldap search with the getEffectiveRightsRequest control; invocations of the ldapGetEffectiveRightsRequest extended operation. - Datastore Access Control Policy Update Actions: any operation implemented by the server which LDAP is using as its datastore which changes the access policy enforced with respect to attempts to access LDAP directory entries and their attributes. - LDAP Access Request operations: invocations of LDAP entry or attribute access operations (Read, Update, Search, Compare, etc...). Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 21] =0C Internet-Draft Access Control Model 10 March 2000 - Other operations: anything else, including Datastore operations which do not change the access policy enforced by the server. 7.2 Semantics of Histories The semantics of histories are defined as follows: - LDAP Update (Replace), LDAP Query The Query will show that the subject has all rights granted by the Update operation, and no rights not granted by the Update operation. - LDAP Update (Grant), LDAP Query The Query will show that the subject has all rights granted by the Update operation. The Query may show that the subject also has other rights not granted by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Deny), LDAP Query The Query will show that the subject does not have any right denied by the Update operation. The Query may show that the subject has rights not denied by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Replace), LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request will fail if it requires any right not granted by the Update operation. - LDAP Update (Grant), LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request may succeed if it requires rights not granted by the Update operation, depending on the policy in force before the Update Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 22] =0C Internet-Draft Access Control Model 10 March 2000 operation. - LDAP Update (Deny), LDAP Access Request The Request will fail if it requires any right denied to the requesting subject by the Update operation. If the Request requires only rights which were not denied by the Update operation, it may succeed, depending on the policy in force before the Update operation. - LDAP Update (Replace), Other, LDAP Query The Query will show that the subject has all rights granted by the Update operation, and no rights not granted by the Update operation. - LDAP Update (Grant), Other, LDAP Query The Query will show that the subject has all rights granted by the Update operation. The Query may show that the subject also has other rights not granted by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Deny), Other, LDAP Query The Query will show that the subject does not have any right denied by the Update operation. The Query may show that the subject has rights not denied by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Replace), Other, LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request will fail if it requires any right not granted by the Update operation. - LDAP Update (Grant), Other, LDAP Access Request The Request will succeed if it requires only rights granted to the requesting subject by the Update operation. The Request may succeed if it requires Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 23] =0C Internet-Draft Access Control Model 10 March 2000 rights not granted by the Update operation, depending on the policy in force before the Update operation. - LDAP Update (Deny), Other, LDAP Access Request The Request will fail if it requires any right denied to the requesting subject by the Update operation. If the Request requires only rights which were not denied by the Update operation, it may succeed, depending on the policy in force before the Update operation. - LDAP Update (Replace), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Grant), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Deny), Datastore Policy Update, LDAP Query The result of the Query is not defined. - LDAP Update (Replace), Datastore Policy Update, LDAP Access Request The result of the Access Request is not defined. - LDAP Update (Grant), Datastore Policy Update, LDAP Access Request The result of the Access Request is not defined. - LDAP Update (Deny), Datastore Policy Update, LDAP Access Request The result of the Access Request is not defined. Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 24] =0C Internet-Draft Access Control Model 10 March 2000 8. Access Control Parameters for LDAP Controls & Extended Operations This section defines the parameters used in the access control LDAP controls and extended operations in this document. targetDN specifies the initial directory entry in DN syntax on which the control or extended operation is performed. whichObject specifies whether the access control information (in the get effective rights control) which is retrieved is for the target directory entry (ENTRY) or the target directory entry and its subtree (SUBTREE). family specifies the family OID that will be retrieved for the get effective rights control or extended operation performed. A family has a defined set of rights, among other things. rights in the get effective rights control or extended operation response is of the form specified in the BNF for . dnType speficies the type of subject security attribute. Defined types are specified in the BNF. subjectDN is a LDAP string that defines the subject or value of the dnType. The subjectDN may be a DN or another string such as IPAddress (dotted-decimal string representation) on which access control is get/set. If the subject is an entry in the directory, then the syntax of the LDAP string is DN. The well-known subjectDNs strings are defined - public - meaning public access for all users - this - meaning the user whose name matches the entry being accessed - * - meaning everyone who has access to the entry Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 25] =0C Internet-Draft Access Control Model 10 March 2000 9. Access Control Information (ACI) Controls The access control information controls provide a way to manipulate access control information in conjunction with a LDAP operation. One LDAP control is defined. This control allows access control information to be get/set while manipulating other directory information for that entry. The control is: - getEffectiveRights to obtain the effective rights for a given directory entry(s) for a given subject during a ldap_search operation 9.1 getEffectiveRights Control 9.1.1 Request Control This control may only be included in the ldap_search message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. The controlType is set to . The criticality MAY be either TRUE or FALSE (where absent is also equivalent to FALSE) at the client's option. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: getEffectiveRightsRequest ::=3D SEQUENCE { effectiveRightsRequest SEQUENCE OF SEQUENCE { family LDAPOID | "*", whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType "access-id"|"group"|"role"| "ipAddress"|"kerberosID"| | "*", subjectDN LDAPString | "public" | "this" | "*" } } The effectiveRightsRequest is a set of sequences that state the whichObject (entry or entry plus subtree) and Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 26] =0C Internet-Draft Access Control Model 10 March 2000 specifics of the control request to be performed. One or more family can be be obtained for a given subjectDN ad dnType. A "*" in the family field indicates that the rights for all families defined for the subjectDN / dnType are to be returned. A "*" in the dnType field specifies that all DN types are to be used in returning the effective rights. This control is applied to the filter and scope set by the ldap_search operation, i.e. base, one-level, subtree. So the attributes/values returned are defined by the ldap_search operation. 9.1.2 Response Control This control is included in the ldap_search_response message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. The controlType is set to . There is no need to set the criticality on the response. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE: getEffectiveRightsResponse ::=3D { result ENUMERATED { success (0), operationsError (1), unavailableCriticalExtension (12), noSuchAttribute (16), undefinedAttributeType (17), invalidAttributeSyntax (21), insufficientRights (50), unavailable (52), unwillingToPerform (53), other (80) } } The effective rights returned are returned with each entry returned by the search result. The control response for ldap_search is: PartialEffectiveRightsList ::=3D SEQUENCE OF SEQUENCE { family LDAPOID, rights in BNF>, whichObject ENUMERATED { Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 27] =0C Internet-Draft Access Control Model 10 March 2000 LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType "access-id"|"group"| "role"|"ipAddress"| "kerberosID"| | "*", subjectDN LDAPString | "public" | "this" | "*" } Although this extends the search operation, there are no incompatibilities between versions. LDAPv2 cannot send a control, hence the above structure cannot be returned to a LDAPv2 client. A LDAPv3 client cannot send this request to a LDAPv2 server. A LDAPv3 server not supporting this control cannot return the additional data. 9.1.3 Client-Server Interaction The getEffectiveRightsRequest control requests the rights that MUST be in effect for requested directory entry/attribute based on the subject DN. The server that consumes the search operation looks up the rights for the returned directory information based on the subject DN and returns that rights information. There are six possible scenarios that may occur as a result of the getEffectiveRights control being included on the search request: 1. If the server does not support this control and the client specified TRUE for the control's criticality field, then the server MUST return unavailableCriticalExtension as a return code in the searchResponse message and not send back any other results. This behavior is specified in section 4.1.12 of [LDAPv3]. 2. If the server does not support this control and the client specified FALSE for the control's criticality field, then the server MUST ignore the Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 28] =0C Internet-Draft Access Control Model 10 March 2000 control and process the request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3]. 3. If the server supports this control but for some reason such as cannot process specified family and the client specified TRUE for the control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the searchResult message. 4. If the server supports this control but for some reason such as cannot process specified family and the client specified FALSE for the control's criticality field, then the server should process as 'no rights returned for that family' and include the result Unavailable in the getEffectiveRightsResponse control in the searchResult message. 5. If the server supports this control and can return the rights per the family information, then it should include the getEffectiveRightsResponse control in the searchResult message with a result of success. 6. If the search request failed for any other reason, then the server SHOULD omit the getEffectiveRightsResponse control from the searchResult message. The client application is assured that the correct rights are returned for scope of the search operation if and only if the getEffectiveRightsResponse control returns the rights. If the server omits the getEffectiveRightsResponse control from the searchResult message, the client SHOULD assume that the control was ignored by the server. The getEffectiveRightsResponse control, if included by the server in the searchResponse message, should have the getEffectiveRightsResult set to either success if the rights are returned or set to the appropriate error code as to why the rights could not be returned. Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 29] =0C Internet-Draft Access Control Model 10 March 2000 The server may not be able to return a right because it may not exist in that directory object's attribute; in this case, the rights request is ignored with success. 10. Access Control Extended Operation An extended operation, get effective rights, is defined to obtain the effective rights for a given directory entry for a given subject. This operation may help with the management of access control information independent of manipulating other directory information. 10.1 LDAP Get Effective Rights Operation ldapGetEffectiveRightsRequest ::=3D [APPLICATION 23] SEQUENCE { requestName [0] , requestValue [1] OCTET STRING OPTIONAL } where requestValue ::=3D SEQUENCE { targetDN LDAPDN, updates SEQUENCE OF SEQUENCE { family LDAPOID | "*", whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, attr SEQUENCE { attr in BNF > }, dnType "access-id"|"group"| "role"|"ipAddress"| "kerberosID"| | "*", subjectDN LDAPString | "public" | "this" | "*" } } Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 30] =0C Internet-Draft Access Control Model 10 March 2000 The requestName is a dotted-decimal representation of the OBJECT IDENTIFIER corresponding to the request. The requestValue is information in a form defined by that request, encapsulated inside an OCTET STRING. The server will respond to this with an LDAPMessage containing the ExtendedResponse which is a rights list. ldapGetEffectiveRightsResponse ::=3D [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] OPTIONAL, effectiveRights [11] OCTET STRING OPTIONAL } where effectiveRights ::=3D SEQUENCE OF SEQUENCE { family LDAPOID, rights in BNF>, whichObject ENUMERATED { LDAP_ENTRY (1), LDAP_SUBTREE (2) }, dnType "access-id"|"group"|"role"| "ipAddress"|"kerberosID"| , subjectDN LDAPString | "public" | "this" } If the server does not recognize the request name, it MUST return only the response fields from LDAPResult, containing the protocolError result code. 11. Security Considerations This document proposes protocol elements for transmission of security policy information. Security considerations are discussed throughout this draft. Because subject security attribute information is used to evaluate decision requests, it is security-sensitive information and must be protected against unauthorized modification whenever it is stored or transmitted. Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 31] =0C Internet-Draft Access Control Model 10 March 2000 12. References [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [ECMA] ECMA, "Security in Open Systems: A Security Framework" ECMA TR/46, July 1988 [REQTS] Stokes, Byrne, Blakley, "Access Control Requirements for LDAP", INTERNET-DRAFT , February 2000. [ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)": Attribute Syntax Definitions, RFC 2252, December 1997. [UTF] M. Wahl, S. Kille, "Lightweight Directory Access Protocol (v3)": A UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [Bradner97] Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement Levels", RFC 2119. AUTHOR(S) ADDRESS Ellen Stokes Bob Blakley IBM Dascom 11400 Burnet Rd 5515 Balcones Drive Austin, TX 78758 Austin, TX 78731 USA USA mail-to: stokes@austin.ibm.com mail-to: blakley@dascom.com phone: +1 512 838 3725 phone: +1 512 458 4037 ext= 5012 fax: +1 512 838 8597 fax: +1 512 458 237 Debbie Byrne IBM 11400 Burnet Rd Austin, TX 78758 USA mail-to: djbyrne@us.ibm.com phone: +1 512 838 1960 fax: +1 512 838 8597 Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 32] =0C Internet-Draft Access Control Model 10 March 2000 Stokes, Byrne, Blakley Expires 10 September 2000 [Page= 33] =0C CONTENTS 1. Introduction....................................... 2 2. Overview........................................... 2 3. Terminology........................................ 4 4. The Model.......................................... 6 4.1 Access Control Information Model............. 6 5. Access Control Mechanism Attributes................ 8 5.1 Root DSE Attribute for Access Control Mechanism.................................... 8 5.2 Subschema Attribute for Access Control Mechanism.................................... 8 6. Access Control Information Attributes.............. 9 6.1 The BNF...................................... 10 6.2 Other Defined Parameters..................... 11 6.2.1 Families and Rights 11 6.2.2 DN Types 12 6.3 Basic ACI Attribute (ldapACI)................ 13 6.3.1 LDAP Operations 15 6.3.2 Grant/Deny Evaluation Rules 15 6.4 Policy Owner Attribute (policyOwner)......... 16 6.5 ACI Examples................................. 17 6.5.1 Attribute Definition 17 6.5.2 Modifying the ldapACI Values 18 6.5.3 Evaluation 19 7. Operational Semantics of Access Control Operations......................................... 21 7.1 Types of actions............................. 21 7.2 =20Semantics of Histories....................... 22 8. Access Control Parameters for LDAP Controls & Extended Operations................................ 25 9. Access Control Information (ACI) Controls.......... 26 9.1 getEffectiveRights Control................... 26 9.1.1 Request Control 26 9.1.2 Response Control 27 9.1.3 Client-Server Interaction 28 - i - 10. Access Control Extended Operation.................. 30 10.1 LDAP Get Effective Rights Operation.......... 30 11. Security Considerations............................ 31 12. References......................................... 32 - ii - Full Copyright Statement Copyright (C) The Internet Society (1999).=A0 All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.=A0 However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - iii - --=====================_15199668==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="summary mar2000 model changes.txt" Folks, I think I've addressed all the email from the last several months on the acccess control model and the attached draft reflects those changes. The changes are summarized below. I think the changes have resulted in simplifying the model. - OIDs have not been generated yet and placeholders in the text still exist (a long time ago I was told not to list OIDs until last call, so I haven't) - changed the name of the ACI attribute to ldapACI so as not to conflict with existing ACI attributes - removed attribute vendorACI - removed get/set/use/manage in the rights set - added browse to the rights set - removed control specifyCredentials. The intent here is to merge this function with the ldap authorization proxy draft. - the attribute aCIMechanism is renamed to aCIMechanisms to better indicate that it is multi-valued - removed 'level' on the BNF for scope - syntax of ldapACI is not compound (removed " ['#' ]* from BNF) - added 3 dnTypes: subtree, ipAddress, kerberosID - modified the rights syntax to allow attributes and collections of atributes to be specified - there is now just a family (OID) and not families of rights within a family; we define one family for this model (IETF_LDAPv3) - specified the ACI atributes as USAGE directoryOperation - fixed the examples to reflect changes in the BNF - added section on grant, deny, and precedence - added section on evaluation examples - various sections modified so access control operations use exactly the ldap operations semantics - modified the semantic section (section 7) to allow ldap operations on access control that fail to return either access denied or just nothing (cases can be made for why each is important) - added '*' to subjectDN - various updates to the getEffectiveAccess control and extended operation for correctness (per BNF, email, etc) --=====================_15199668==_-- From list@netscape.com Mon Mar 13 00:54:26 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04300 for ; Mon, 13 Mar 2000 00:54:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA02938; Sun, 12 Mar 2000 21:50:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id VAA20745; Sun, 12 Mar 2000 21:53:06 -0800 (PST) Resent-Date: Sun, 12 Mar 2000 21:53:06 -0800 (PST) From: 35v9R47R1@hotmail.com DATE: 12 Mar 00 11:53:47 PM Message-ID: SUBJECT: Private Offshore Club Resent-Message-ID: <"unWwCB.A.QDF.-IIz4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com PRIVATE OFFSHORE WEALTH BUILDING CLUB *Privacy *Wealth Building *Medium to high yield investments (6% to 40% returns per month) *Offshore opportunities *Offshore Banking *Asset protection *Private calls *Much More If you are interested in finding out addtional information call us toll free 24hrs 877 213 7235 PRIVATE OFFSHORE WEALTH BUILDING CLUB *Privacy *Wealth Building *Medium to high yield investments (6% to 40% returns per month) *Offshore opportunities *Offshore Banking *Asset protection *Private calls *Much More If you are interested in finding out addtional information call us toll free 24hrs 877 213 7235 ********************************************************** From list@netscape.com Mon Mar 13 01:47:49 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28692 for ; Mon, 13 Mar 2000 01:47:35 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id WAA26332; Sun, 12 Mar 2000 22:41:53 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA00318; Sun, 12 Mar 2000 22:46:24 -0800 (PST) Resent-Date: Sun, 12 Mar 2000 22:46:24 -0800 (PST) From: Pxioku6Lk@mail.sintel.inet.it DATE: 12 Mar 00 10:33:11 PM Message-ID: <78uaEiUxUaZX0iT5> SUBJECT: >>> WANT TO BE A MILLIONAIRE <<< 78UY6TY Resent-Message-ID: <"R0Xz2C.A.qE._6Iz4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com !!!!! THOUSANDS ARE RETIRING AFTER 24 - 36 MONTHS !!!! Let me show you how you can retire in luxury within the next 36 months. I didn't believe it either, but I gave it a try and I can honestly tell you it is the best thing I ever did for myself and my family. Now I am on course to retire in less than 3 years and I am only 33 years old. I am going to enjoy the good life while I am young enough to enjoy it. " YOU CAN TO " This opportunity has truly changed my whole life and it can change yours too. This is absolutely, positively NOT MLM or NETWORK MARKETING, this is real. This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life. Do it for your family. Do it for yourself. I promise you this will be the best decision you will ever make to change your life for the best. I tried every get rich scheme out there, THIS IS DIFFERENT. Start working 3 to 4 hours a day and you will soon be making that decision to quit your regular job because you will be loosing money by working there. NO SPECIAL SKILLS OR EXPERIENCE REQUIRED, ONLY DESIRE. You will receive all the training and support necessary to get you on that road to success. If your idea of success is; LIVING IN A BIG HOUSE WITH NO MORTGAGE PAYMENT, DRIVING LUXURY AUTOMOBILES WITH NO CAR PAYMENT, TRAVELING TO EXOTIC PLACES AROUND THE WORLD, ENJOYING ALL THE FINE THINGS IN LIFE THAT MAKE YOU HAPPY, AND RETIRE IN STYLE. Then you must make this call. Only SERIOUS people need to apply. If you are SERIOUS you will succeed in this business! Call me NOW and get started changing your life into something you always dreamed it could be. 1 800 587 9046 ext. 1310 To be removed from this mailing list FAX your email address to: 1 800 546 3685 From list@netscape.com Mon Mar 13 12:09:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27561 for ; Mon, 13 Mar 2000 12:09:47 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA25194; Mon, 13 Mar 2000 09:05:07 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA18949; Mon, 13 Mar 2000 08:57:31 -0800 (PST) Resent-Date: Mon, 13 Mar 2000 08:57:31 -0800 (PST) Message-ID: <38CD1D97.94C1446@netscape.com> Date: Mon, 13 Mar 2000 08:55:51 -0800 From: ggood@netscape.com (Gordon Good) X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ldapext@netscape.com, ietf-ldup@imc.org Subject: Re: Changelog entries draft. Do not seem to find it. References: <38BEE2B6.BE3DF1D2@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"COdmVC.A.pjE.z3Rz4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I've refreshed the changelog draft. It's now available from the IETF Internet Drafts repository: http://www.ietf.org/internet-drafts/draft-good-ldap-changelog-01.txt -Gordon From list@netscape.com Mon Mar 13 18:10:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17670 for ; Mon, 13 Mar 2000 18:10:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA07970; Mon, 13 Mar 2000 15:04:27 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA07108; Mon, 13 Mar 2000 15:08:51 -0800 (PST) Resent-Date: Mon, 13 Mar 2000 15:08:51 -0800 (PST) Reply-To: From: "Steven Legg" To: "'Jim Sermersheim'" Cc: , Subject: RE: LDAP subentry, discussion on CN {MUST or MAY} Date: Tue, 14 Mar 2000 10:09:57 +1100 Message-ID: <000801bf8d41$42668970$895508cb@rubidium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Resent-Message-ID: <"tvqeED.A.8tB.AUXz4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Jim, I agree with your interpretation, with the added qualification that the naming attribute(s) must still be a permitted attribute of the entry, if not by the structural object class then by an auxiliary object class or DIT content rule. That is, being referenced in a relevant name form does not alone make an attribute a permitted attribute of an entry. For the record, I'm not much fussed whether we make the cn attribute mandatory or not, but if the definition of LDAPsubentry ends up being the same as X.500's subentry definition I would rather that we just copy the X.500 definition and OID. Steven -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jim Sermersheim Sent: Friday, 10 March 2000 16:22 To: jayhawk@att.com; kurt@boolean.net; eskovgaard@geotrain.com; era.als@get2net.dk; mcs@netscape.com; eer@OnCallDBA.COM Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com; Mark Hinckley Subject: Re: LDAP subentry, discussion on CN {MUST or MAY} To satisfy X.500, I believe that the LDAPSubentry object class can be STRUCTURAL and not include any attributes. From my reading, the attributes specified in the name form don't need to be made up of the attributes specified in the object class definition. The text I'm reading is in Section 12.6.2 of X.501: "The RDN attribute (or attributes) need not be chosen from the list of permitted attributes of the structural object class as specified in its structural or alias object class definition". I may be mis-reading that, but I don't think so. There also may be directory implementations that require naming attributes to be listed in the object class's MUST or MAY list (I know of at least one). Jim >>> "Ed Reed" 3/9/00 2:58:31 PM >>> Back in November and at the IETF meeting in Washington, we discussed whether LDAPsubentry should be STRUCTURAL or ABSTRACT in definition. Mark has pointed out that MAY would address Kurt's objection to MUST {cn}, but that leaves the many folks out there who define naming rules with a problem, when there are (possibly) no attributes defined on the class at all (cn is the only attribute declared for the ldapsubentry class definition). Frankly, those folks who DO define naming attributes and naming rules will have to deal in some way with other systems who don't, but that's a different discussion I think. I think the discussion in Washington concluded that we should 1) leave the class STRUCTURAL 2) leave MUST {cn} in the definition 3) encourage Kurt to derive a new subclass of LDAPsubentry for his special-purpose class, which defines the other attribute he will use to actually name his entries - meaning that yes, he will need to provide a (possibly useless, but not necessarily unique) value for the cn value Erik's argument, that to make it Auxiliary would require a proliferation of new structural types, each with their own new naming rules, is what finally persuaded me to avoid that approach. The consequences of blithly ignoring the operational experience of the X.500 community was also important. It will be easier, by far, for most people to treat LDAPsubentry as STRUCTURAL, and then to decorate it with additional attributes for their particular needs, than to require each new use to define a new STRUCTURAL class with it's own naming rules. As I think about it, though, there is one way to make both camps happy: 1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all. 2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes). Such an approach would violate the "fewer classes is better" rule. But I think it would satisfy both Kurt and the X.500 folks. This is the only issue standing in the way of a last call. Any final words? Ed ================= Ed Reed Reed-Matthews, Inc. +1 801 796 7065 http://www.OnCallDBA.COM From list@netscape.com Mon Mar 13 18:51:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03025 for ; Mon, 13 Mar 2000 18:51:14 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA13754; Mon, 13 Mar 2000 15:45:25 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA23450; Mon, 13 Mar 2000 15:49:51 -0800 (PST) Resent-Date: Mon, 13 Mar 2000 15:49:51 -0800 (PST) Message-Id: <3.0.5.32.20000313154921.009508d0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 13 Mar 2000 15:49:21 -0800 To: From: "Kurt D. Zeilenga" Subject: RE: LDAP subentry, discussion on CN {MUST or MAY} Cc: "'Jim Sermersheim'" , , In-Reply-To: <000801bf8d41$42668970$895508cb@rubidium.adacel.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"c4GeSB.A.IuF.e6Xz4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:09 AM 3/14/00 +1100, Steven Legg wrote: >For the record, I'm not much fussed whether we make the cn attribute >mandatory or not, but if the definition of LDAPsubentry ends up being the >same as X.500's subentry definition I would rather that we just copy >the X.500 definition and OID. LDAPsubentry is quite dissimiliar in definition to the X.500 subentry. It doesn't allow have a subtree specifier. Hence, the new OID. From list@netscape.com Mon Mar 13 19:26:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16166 for ; Mon, 13 Mar 2000 19:26:38 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA11394; Mon, 13 Mar 2000 16:22:55 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA12154; Mon, 13 Mar 2000 16:25:16 -0800 (PST) Resent-Date: Mon, 13 Mar 2000 16:25:16 -0800 (PST) Date: Mon, 13 Mar 2000 18:25:10 -0600 From: Mark Wahl Subject: LDAPEXT draft agenda Sender: Mark.Wahl@INNOSOFT.COM To: ietf-ldapext@netscape.com Cc: agenda@ietf.org Cc: paf@swip.net Cc: moore@cs.utk.edu Cc: Ned.Freed@INNOSOFT.COM Reply-to: M.Wahl@INNOSOFT.COM Message-id: <10330.952993510@threadgill.austin.innosoft.com> Resent-Message-ID: <"PzVdUB.A.o9C.qbYz4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Here is the draft agenda. If you have any additions, or are signed up but will not be there, please let me know. Be sure to read the drafts listed in sections 5-13! What: LDAPEXT Working Group When: Monday, March 27, 2000 1530-1730 1. Agenda review (Mark Wahl) 2. Summary of long-completed work items (Mark Wahl) 3. Last calls completed since November (Mark Wahl) draft-ietf-ldapext-ldapv3-vlv-03 draft-ietf-ldapext-ldap-java-api-10 draft-ietf-ldapext-ldap-java-api-asynch-ext-05 draft-ietf-ldapext-ldap-taxonomy-02 4. Charter progress review (Mark Wahl) 5. Server location with DNS (Paul Leach) draft-ietf-ldapext-locate-01 6. C API (Mark Smith) draft-ietf-ldapext-ldap-c-api-04 7. ACL Model (Ellen Stokes) draft-ietf-ldapext-acl-model-05 8. CLDAP (Roland Hedberg) 9. Subentries (Ed Reed) draft-ietf-ldup-subentry-01 10. LCUP (Olga Natkovich) draft-natkovich-ldap-lcup-00 11. Referrals and knowledge references draft-ietf-ldapext-namedref-00 draft-ietf-ldapext-knowledge-00 12. DIF SP-DNA BOF info (Farzi Khazai) 13. Password management (Jim Sermersheim, Kurt Zeilenga) draft-behera-ldap-password-policy-01 draft-zeilenga-ldap-authpassword-02 draft-zeilenga-ldap-passwd-exop-01 14. Any other business Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Mon Mar 13 19:40:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22549 for ; Mon, 13 Mar 2000 19:40:46 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA13980; Mon, 13 Mar 2000 16:35:41 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA16004; Mon, 13 Mar 2000 16:38:01 -0800 (PST) Resent-Date: Mon, 13 Mar 2000 16:38:01 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: Ellen Stokes , internet-drafts@ietf.org, ietf-ldapext@netscape.com Date: Tue, 14 Mar 2000 00:35:34 -0000 MIME-Version: 1.0 Content-type: Multipart/Mixed; boundary=Message-Boundary-10040 Subject: Re: please publish (draft-ietf-ldapext-acl-model-05.txt) Reply-to: d.w.chadwick@salford.ac.uk CC: djbyrne@us.ibm.com, blakley@dascom.com Priority: normal In-reply-to: <4.2.2.20000310133633.00a451c0@popmail2.austin.ibm.com> X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"Lf-TvD.A.y5D.onYz4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --Message-Boundary-10040 Content-type: text/plain; charset=US-ASCII Content-description: Mail message body Content-Transfer-Encoding: 7BIT Ellen Please find attached my comments on model-05 David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** --Message-Boundary-10040 Content-type: text/plain; charset=US-ASCII Content-description: Text from file 'Comments on ACL model 05.txt' Content-Transfer-Encoding: 7BIT Comments on ACL model 05 i) I think it is extra clutter to have familyOID as the first component of the ldapACI attribute type, and does not buy us anything. If you want to define another set of permissions, then simply give them a new attribute type (e.g. ldapACIv2) which is itself an OID. It serves no good purpose to have one OID for the ldapACI attribute then another OID for the family. You might as well have just one OID that means precisely one set of permissions and access control information. ii) I made a comment on 04 about ReadDN that I don't believe has been addressed yet. There is a difference between letting someone have access to an entry they know exists, and ones they don't know exist. I.e. there is a difference in permissions needed for the base object of a Search and the entries beneath the base object (the latter is a greater permission than the former). At the moment BrowseDN gives the latter permission, but there is not the lesser permission of accessing an entry whose name you already know. This would call for a ReadDN permission I believe. Comments please on this. iii) Precedence of privilege dnTypes. I would argue that role comes higher than group as it is more specific. By this I mean that group membership is usually conferred on more people than are roles (and as you said in October, roles can be regarded as groups with permissions). I would expect my role of abc administrator to have more weight than simply a member of the IETF LDAP group. iv) On the same vein, can you explain why IP address should be higher than access-id, when the former can be used by multiple people, the latter by only one. It is the issue of specificity again. The more specific a dnType the higher its precedence should be. v) In my comments to version 4, I mentioned that delete permission for attribute values could be needed, as with Modify Entry you both add values and delete values and replace values (I took your write values permission to mean add). With separate permissions you can allow some people to add, some to delete, and some to do both. You said you would look into it, but I don't remember your reply to this. I would suggest changing "write" to "add", and adding "delete". vi) Why can an acl entry only confer multiple rights on a single attribute name. I would have expected to allow multiple attribute names within it. (Version 4 allowed this.) Your later example shows the ldapACI being repeated in order to give SysAdmins access to attr2 and attr3. Why was the restriction introduced? vii) Section 9 introductory paragraph talks about manipulating access rights and getting and setting them. But as I read it, the section only provides a mechanism to read them, not to update, set or manipulate them. Can you alter the wording please. --Message-Boundary-10040-- From list@netscape.com Mon Mar 13 21:38:29 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03374 for ; Mon, 13 Mar 2000 21:38:27 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA29902; Mon, 13 Mar 2000 18:34:47 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA04058; Mon, 13 Mar 2000 18:37:07 -0800 (PST) Resent-Date: Mon, 13 Mar 2000 18:37:07 -0800 (PST) From: H6727HIcX@aa.nl DATE: 13 Mar 00 4:58:21 PM Message-ID: SUBJECT: >>> Guaranteed -- Best FREE Cell Phone Offer On The Planet!!! <<< jljblasl Resent-Message-ID: <"uXyRpD.A.G_.SXaz4"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com ______________________________________________ «¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ Guaranteed -- Best FREE Cell Phone Offer On The Planet!!! ______________________________________________ «¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤»§«¤»¥«¤ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ => How to get the 1st and ONLY FREE PCS Digital Cell Phone with: =>> NO Long Distance and NO Roaming Charges. =>>> Call anytime you want too. =>>>> Now Available on the Net for a Limited Time. That's right! You get a FREE PCS "Dual-Band " Digital Cell Phone. You SAVE over $125.00 !!! Don't miss out on using the best NATIONWIDE DIGITAL PCS NETWORK!!! Your "Free" Digital Phone includes the following: => Your choice of a NEW Samsung or Qualcomm Thin Phone => You pay No Activation Fee. => You Risk Nothing. Order Now and You Get: + FREE Long Distance and Roaming. + FREE Caller ID. + FREE Call Waiting. + FREE Call Forwarding. + FREE Three Way Calling + FREE VoiceMail. + FREE Paging. [Get rid of your pager bill.] + FREE Home Charger. + PLUS, You Get The First Incoming Minute FREE. Your NEW phone is... => Slim and Lightweight -- just 6 oz. => Easy to use. You will enjoy... * CALLING PLAN AS LOW AS 10 CENTS PER MINUTE * Crystal Clear Sound. * CDMA technology protects your calls against eavesdropping. * Voice Activated Dialing and Voice Memo with the Samsung model. * The best and largest digital carrier in the USA. You get FREE Delivery by UPS within just 10-15 working days of approval. * * * 30 Day Satisfaction Guarantee * * * Just fill out the form below and fax it to us. One of our professional Cell Phone experts will promptly call you to complete the setup process. Bad credit is NO PROBLEM. You'll be notified if a deposit is needed to activate your new service. TO ORDER your FREE CELL PHONE, just print the form below. Then fax it to the number below. You should have your new Cell Phone within 10-15 business days after your service is set up. Is there any question that this is an incredible opportunity? Apply now for the best wireless phone service for the new millennium and get your new "FREE" PCS digital Cell Phone. Sound too good to be true? We're going to make this an easy decision for you to FAX YOUR APPLICATION TODAY... FREE BONUS #1. Fax your application before March 21st, 2000 and you get a certificate for THREE EXCITING DAYS and TWO FUN FILLED NIGHTS in a mini-suite at a major LAS VEGAS casino hotel or you can choose one of 19 other resort destinations including Branson and Cancun. FREE BONUS #2. Fax your application in the next 72 hours and you get a certificate for over $500 in Casino Benefits to use with your vacation to Reno/Lake Tahoe or Las Vegas. Anaheim and Orlando Fun Books are also available that offer discount entertainment and meals. This vacation package alone will save you more than $700.00 !!! ** So what's the catch? Company's are scrambling for new customers. They're taking risks like never before to get new business. The hotel's know that once you have experienced their services, you'll want to come back. It's a great way for them to advertise. FREE BONUS #3 Fax your application before March 21st and you'll receive a brochure to get a Continental Advantage credit card with an immediate $4,000 line of credit "PLUS" a $100 Merchandise Certificate to use just like CASH. You can't lose!!! DON'T WAIT to get started ...DO IT NOW!!! To receive your Vacation Certificates, mail a self-addressed, stamped envelope to: ===> Network Special Offers [netcell-offer] 2133 East 9400 South, #110 Sandy, Utah 84093, U.S.A. PS. There are a limited number of vacation certificates that will be given out on a first-come, first-serve bases to those who fax their application before March 21st, 2000. Go Ahead And Fax Your Application Now! Thank you for reading this e-mail, Opt-In Marketing Concepts Copyright 2000, All Rights Reserved - - - - - - - CUT HERE - - - - - - - * * * WARNING, DO NOT MODIFY THIS APPLICATION * * * Fax Order Centers: => Main Office 801-457-0554 => 559-991-8166 Please TYPE or PRINT CLEARLY. Fax ONLY this application. APPLICATION MUST BE COMPLETED or IT WILL NOT BE PROCESSED. No blank fields. [Sorry, no coverage currently available to residents of MT, MS, NC, SC, AK] "VERY CLEARLY" Print or Type: (02LL) YOUR E-MAIL ADDRESS: ________________________ NAME First:__________________ M.I. ____ Last:________________ USA Address ______________________________________ Apt# _______ City _______________________________ ST ________ Zip ______ County _______________________ [NEEDED TO FIND YOUR COVERAGE AREA] SS# ________________________ Date Of Birth ______/_____/______ DL# __________________________ Exp. Date _____/_____/_______ Home Ph# (___)_______________ [NO PAGER NUMBERS] Work Ph# (____)_____________ Ext# ______ [NO PAGER NUMBERS] Best Time To Call ______________________ Time Zone: _______ YOUR Business or EMPLOYER Information: (02LL) Check one: ____ Self Employed ____ Employee If Self Employed, please enter your Business License # ______________ or Sales Tax ID #_____ Company or Employer NAME: _______________________ Address: _______________________ City:_______________________________ST:________ Zip:_______ Phone #:______________ Check the phone you want: ___ Sanyo 3000 ___ Qualcomm Thin Phone Available Calling Plans: => 120 Anytime minutes per month!!! => 1500 Anytime minutes per month!!! => 500 Anytime minutes per month!!! => 1000 Anytime minutes per month!!! => 700 Anytime minutes per month!!! => 2000 Anytime minutes per month!!! Best of all, every plan exclusive to this offer, allows YOU the freedom to upgrade or downgrade at ANY time!!! One of our professional Cell Phone experts will promptly call you to help you choose the plan that best fits your needs. Signature: ______________________________ Date: ____/____/_______ NO UP-FRONT MONEY -- your first bill comes within 30 days from receipt of phone. [2 year Air Time contract, O.A.C.] (02LL) Authorization for credit check and contract approved by my signature. * * * WARNING, DO NOT MODIFY THIS APPLICATION * * * - - - - - - - CUT HERE - - - - - - - Check your application status by calling: 1-888-248-1136 Fax Order Centers: => Main Office 801-457-0554 => 559-991-8166 IMPORTANT NOTE: An independent marketing company will be processing your free bonus’s and not the cell phone provider or the company sending this email. So don't forget to send your self-address, stamped envelope to: ===> Network Special Offers 2133 East 9400 South, #110 Sandy, UT 84093 From list@netscape.com Tue Mar 14 03:14:36 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17837 for ; Tue, 14 Mar 2000 03:14:35 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA17330; Tue, 14 Mar 2000 00:11:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA10204; Tue, 14 Mar 2000 00:13:25 -0800 (PST) Resent-Date: Tue, 14 Mar 2000 00:13:25 -0800 (PST) X-Envelope-Sender-Is: helmut.volpers@icn.siemens.de (at relayer goliath.siemens.de) Message-ID: From: "Volpers, Helmut" To: "'Kurt D. Zeilenga'" , steven.legg@adacel.com.au Cc: "'Jim Sermersheim'" , ietf-ldapext@netscape.com Subject: RE: LDAP subentry, discussion on CN {MUST or MAY} Date: Tue, 14 Mar 2000 09:13:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"O_JmEB.A.KfC.kSfz4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA17837 > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Dienstag, 14. März 2000 00:49 > To: steven.legg@adacel.com.au > Cc: 'Jim Sermersheim'; ietf-ldup@imc.org; ietf-ldapext@netscape.com > Subject: RE: LDAP subentry, discussion on CN {MUST or MAY} > > > At 10:09 AM 3/14/00 +1100, Steven Legg wrote: > >For the record, I'm not much fussed whether we make the cn attribute > >mandatory or not, but if the definition of LDAPsubentry ends > up being the > >same as X.500's subentry definition I would rather that we just copy > >the X.500 definition and OID. > > LDAPsubentry is quite dissimiliar in definition to the X.500 subentry. > It doesn't allow have a subtree specifier. Hence, the new OID. independant of the OID, what is the problem to define the LDAPsubentry with the same semantics as an X.500 subentry ? In our Implementation I can retrieve the X.500 subentries easily over LDAP, if a ldapclient search for OCL=LDAPSubentry it is handled by the server the same way as it is handled if the X.500 ServiceControl SUBENTRIES=TRUE. So I can search for the X.500 subentries over LDAP. > From list@netscape.com Wed Mar 15 03:34:58 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01248 for ; Wed, 15 Mar 2000 03:34:57 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA25501; Wed, 15 Mar 2000 00:31:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA17786; Wed, 15 Mar 2000 00:33:41 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 00:33:41 -0800 (PST) From: joerg_schaefer@westlb.de X-Lotus-FromDomain: WLB@WESTLB_INTERNET To: ietf-ldapext@netscape.com Message-ID: <412568A3.002EDD64.00@data.WestLB.de> Date: Wed, 15 Mar 2000 09:31:45 +0100 Subject: Antwort: Re: reply: [Bug 31141] Changed - LDAPSearchResults getCount() methodreturns incorrect value Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=81zA9pjPihmew75mPpPmvKpac8f8BMXNmiVd4mN6NMnCC6mszacONexm" Content-Disposition: inline Resent-Message-ID: <"1qBBRC.A.oVE.jr0z4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --0__=81zA9pjPihmew75mPpPmvKpac8f8BMXNmiVd4mN6NMnCC6mszacONexm Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I would like to comment on the definition of "getCount()" in the ldapjd= k API. I understand your rationale for providing asynchronous access, but I w= ould argue for a renaming the method as its confusing and exposes implementa= tion details to the client and for adding a convenience method as described = in the email below. Cheers Joerg miodrag@netscape.com (Miodrag Kekic) on 03/14/2000 11:38:59 PM An: J=F6rg Sch=E4fer/D/WLB@WLB Kopie: Thema: Re: reply: [Bug 31141] Changed - LDAPSearchResults getCount()= methodreturns incorrect value = --0__=81zA9pjPihmew75mPpPmvKpac8f8BMXNmiVd4mN6NMnCC6mszacONexm Content-type: text/plain; charset=us-ascii Content-Disposition: inline Joerg, I agree that the name is misleading, you are not the first one that ran into the problem. However, ldapjdk APIs are now controlled by the ietf-ldapext working group and we can not any more just go and change them. There is an internet draft http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-10.txt where LDAPSearchResults.getCount() is defined as " Returns a count of the entries in the search result. If the search is asynchronous (batch size not 0), this reports the number of results received so far." These APIs are subject to public discussion. You can add yourself to the mailing list ietf-ldapext@netscape.com where you can discuss ldap java API. Regards, Miodrag joerg_schaefer@westlb.de wrote: > Hi there, > > OK, understood, many thanks. But I still think this is not a feature but a bug, > or bad behaviour, to say the least. > We have a public method that exposes implementation details such as the status > of the internal result queue to the client. This should be avoided in general. > The naming is also misleading - I saw example code that mistakenly believed in > what I believed would be returned. Thus, I would suggest some renaming at least > and maybe adding a convenience-method returning the business relevant > information e.g. the total number of entries that match the search filter, too! > (if this requires blocking - ok, there is no alternative.) > By the way - is it appropriate to suggest this here? > Cheers > Joerg > > ------- Additional Comments From mcs@netscape.com 2000-03-09 10:19 ------- > Reassigned to Miodrag. > + > + ------- Additional Comments From miodrag@netscape.com 2000-03-13 18:08 > ------- > + This is a normal behavior. LDAPSearchResults.getCount() returns the number of > + currently available search results in the search result queue, rather than the > + total number of entries that match the search filter. > + > + When the directory sends a new search result, the result gets queued and the > + search result count is incremented. As you read search results from > + LDAPSearchResults, one at a time, the search result count gets decremeneted. > + > + Only if you set the batch size in LDAPSearchConstrains to 0 --means search() > + should wait for all results to be received before proceeding --, you'll see > the > + exact count of found entries. > + > + By default the batchSize is 1, which means results are to be processed as they > + come in. LDAPSearchResults.hasMoreElements() blocks until the batchSize number > + of results is received. > + --0__=81zA9pjPihmew75mPpPmvKpac8f8BMXNmiVd4mN6NMnCC6mszacONexm-- From list@netscape.com Wed Mar 15 03:57:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08247 for ; Wed, 15 Mar 2000 03:57:40 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA26998; Wed, 15 Mar 2000 00:54:13 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA21992; Wed, 15 Mar 2000 00:56:36 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 00:56:36 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: "Volpers, Helmut" Date: Wed, 15 Mar 2000 08:49:08 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: RE: LDAP subentry, discussion on CN {MUST or MAY} Reply-to: d.w.chadwick@salford.ac.uk CC: ietf-ldapext@netscape.com Priority: normal In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"LGI8Q.A.WXF.DB1z4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT > > > LDAPsubentry is quite dissimiliar in definition to the X.500 > > subentry. It doesn't allow have a subtree specifier. Hence, the new > > OID. > In fact LDAP implies the default value for subtreeSpecification (which is simply an empty sequence). THe meaning of this is the entire naming context. So LDAP subentries are the most degenerate case of X.500 subentries. Because of this you are able to go one step further in simplification - rather than having a subtreeSpecification attribute with a value which is always an empty sequence you have decided to simply omit the attribute altogether (which is sensible). But what happens if in the future if you decide that you would like to manage a section of a naming context, rather than the whole of it. Well then you can re-invent subtreeSpecifications!! David > independant of the OID, what is the problem to define the LDAPsubentry > with the same semantics as an X.500 subentry ? In our Implementation I > can retrieve the X.500 subentries easily over LDAP, if a ldapclient > search for OCL=LDAPSubentry it is handled by the server the same way > as it is handled if the X.500 ServiceControl SUBENTRIES=TRUE. So I can > search for the X.500 subentries over LDAP. > > > *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Mar 15 06:26:18 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00049 for ; Wed, 15 Mar 2000 06:26:18 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA27065; Wed, 15 Mar 2000 03:20:34 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA12154; Wed, 15 Mar 2000 03:25:09 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 03:25:09 -0800 (PST) Message-Id: <200003151125.GAA29554@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-acl-model-05.txt Date: Wed, 15 Mar 2000 06:25:04 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"YjmiW.A.o9C.UM3z4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : Access Control Model for LDAP Author(s) : E. Stokes, D. Byrne, B. Blakley Filename : draft-ietf-ldapext-acl-model-05.txt Pages : 33 Date : 14-Mar-00 This document describes the access control model for the Lightweight Directory Application Protocol (LDAP) directory service. It includes a description of the model, the LDAP controls, and the extended operations to the LDAP protocol. The current LDAP APIs are sufficient for most access control operations. An API (in a separate document) is needed for the extended operation getEffectiveAccess and specifyCredentials. RFC2219 [Bradner97] terminology is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-acl-model-05.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-ldapext-acl-model-05.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-ldapext-acl-model-05.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: <20000314133103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-acl-model-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-acl-model-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314133103.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Mar 15 06:26:21 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00075 for ; Wed, 15 Mar 2000 06:26:20 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA27136; Wed, 15 Mar 2000 03:20:39 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA12260; Wed, 15 Mar 2000 03:25:14 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 03:25:14 -0800 (PST) Message-Id: <200003151125.GAA29588@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ldapext@netscape.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ldapext-ldapv3-dupent-03.txt Date: Wed, 15 Mar 2000 06:25:09 -0500 Sender: nsyracus@cnri.reston.va.us Resent-Message-ID: <"yQt71D.A.7-C.YM3z4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : LDAP Control for a Duplicate Entry Representation of Search Results Author(s) : J. Sermersheim Filename : draft-ietf-ldapext-ldapv3-dupent-03.txt Pages : 7 Date : 14-Mar-00 This document describes a Duplicate Entry Representation control extension for the LDAP Search operation. By using the control with an LDAP search, a client requests that the server return separate entries for each value held in the specified attributes. For instance, if a specified attribute of an entry holds multiple values, the search operation will return multiple instances of that entry, each instance holding a separate single value in that attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-dupent-03.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-ldapext-ldapv3-dupent-03.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-ldapext-ldapv3-dupent-03.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: <20000314133113.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ldapext-ldapv3-dupent-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ldapext-ldapv3-dupent-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000314133113.I-D@ietf.org> --OtherAccess-- --NextPart-- From list@netscape.com Wed Mar 15 11:17:41 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28917 for ; Wed, 15 Mar 2000 11:17:40 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA00022; Wed, 15 Mar 2000 08:14:02 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA14198; Wed, 15 Mar 2000 08:16:20 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 08:16:20 -0800 (PST) Message-Id: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 15 Mar 2000 10:15:28 -0600 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: please publish (draft-ietf-ldapext-acl-model-05.txt) Cc: djbyrne@us.ibm.com, blakley@dascom.com In-Reply-To: References: <4.2.2.20000310133633.00a451c0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"766Br.A.kdD.Td7z4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Responses embedded below and prefaced by (EJS) Ellen At 12:35 AM 3/14/00 +0000, David Chadwick wrote: >Ellen >Please find attached my comments on model-05 >David >*************************************************** > >David Chadwick >IS Institute, University of Salford, Salford M5 4WT >Tel +44 161 295 5351 Fax +44 161 745 8169 >Mobile +44 790 167 0359 >Email D.W.Chadwick@salford.ac.uk >Home Page http://www.salford.ac.uk/its024/chadwick.htm >Understanding X.500 http://www.salford.ac.uk/its024/X500.htm >X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm >Entrust key validation string MLJ9-DU5T-HV8J > >*************************************************** > >Comments on ACL model 05 > >i) I think it is extra clutter to have familyOID as the first component of >the >ldapACI attribute type, and does not buy us anything. If you want to define >another set of permissions, then simply give them a new attribute type (e.g. >ldapACIv2) which is itself an OID. It serves no good purpose to have one OID >for the ldapACI attribute then another OID for the family. You might as well >have just one OID that means precisely one set of permissions and access >control information. (EJS) We could do as you suggest, but I'd rather not. I believe that it is better to have a single attribute known for ldap access control rather than proliferate more attributes for this purpose and let the family OID control the remaining information. This provides an application with one way of accessing access control information, although it may still have to parse out the information. If we start propagating different attributes for ldap access control, then it is difficult, if not impossible, for the application to know which ldap access control attribute it needs to invoke. >ii) I made a comment on 04 about ReadDN that I don't believe has been >addressed yet. There is a difference between letting someone have access >to an >entry they know exists, and ones they don't know exist. I.e. there is a >difference in permissions needed for the base object of a Search and the >entries >beneath the base object (the latter is a greater permission than the >former). At >the moment BrowseDN gives the latter permission, but there is not the lesser >permission of accessing an entry whose name you already know. This would >call for a ReadDN permission I believe. Comments please on this. (EJS) BrowseDN is ReadDN. BrowseDN allows that DN in a search. This allows someone access to only information that he has been authorized for. A person may know that an entry exists, but just because he does have that knowledge does not mean he can access it. Likewise, if a person doesn't know an entry exists doesn't mean that he should be able to discover it. >iii) Precedence of privilege dnTypes. I would argue that role comes higher >than >group as it is more specific. By this I mean that group membership is usually >conferred on more people than are roles (and as you said in October, roles >can >be regarded as groups with permissions). I would expect my role of abc >administrator to have more weight than simply a member of the IETF LDAP >group. The following is a cut and paste from Bob Blakley's reasoning in his prior email on the precedence stated in this current draft. The underlying implementation of the access decision function (which looks at ACL entries and compares them against the subject's credentials to render a yes/no decision about a particular access request) may treat "group" entries differently from "role" entries. For example, it might implement "union semantics" for groups but "intersection semantics" for roles. Thus if an ACL contained 4 entries: group1 : grant (read, search) group2 : grant (update) role1 : grant (read, search) role2 : grant (update) A subject belonging to group1 and group2 would be granted access (because union semantics grants access if any group grants access), but a subject belonging to role1 and role2 would be denied access (because intersection semantics grants access only if all roles grant access). This ability to distinguish groups and roles semantically is important. It permits security administrators to have two different subject collection constructs with different granularities and different dynamism. Roles (not role attributes -- actual roles) are typically defined at a fairly high organizational level and changed infrequently. The authorizations granted to role attributes mirror the organizational responsibilities associated with the roles. However in modern organizations roles don't describe the "entire job" of an individual -- the VP of marketing may be assigned (for a short time) to a task force evaluating the technical competitiveness of a product. To participate in this activity, she may need access to engineering data to which her job role (or roles) as marketing VP don't entitle her. The CFO and the East Region Helpdesk Director may also be on the taskforce, and may need access to the same data. To grant the desired access to all three of these individuals, it would be possible to individually authorize them to the data -- but this would be bad for several reasons. The first is scale -- for three people this would be feasible, but for 30 it would be unpleasant, and for 3000 it would be impractical (especially in organizations which run lots of task forces or have lots of matrix management). The second is that if you simply put individual entries on the ACL, you might forget who the individuals are and why they're on the ACL. In this case you'd very likely forget to take them off the ACL when the task force ended, thus creating a need-to-know violation. On the other hand, defining a new "role" for the task force is bad also: task force membership isn't really a role; it's really an assignment. Adding lots of roles to the role namespace pollutes the policy environment and makes it very difficult for the enterprise policy administrators, whose job is defining work roles and their proper authorizations, to do their work. What's really called for is defining a "group" -- an ad-hoc collection of users who can be authorized to the specific set of resources for the duration of the project as an *exception* to the role-based policy. The group should be given an evocative name (like the name of the project) and should be authorized to the resource. When the project ends, the group can be deleted, and its entries can be removed from the associated resource ACLs. As this example suggests, in order to support using groups as exceptions to roles, group attributes and role attributes need to have different precedence. As the example also suggests, I think groups should have *higher* precedence than roles, since roles are essentially a coarse-grained, static, subject collection, and groups are a fine-grained, dynamic subject collection. Note that many existing security models, including ISO, ECMA-138, CORBA, and others include both groups and roles (and type-distinguish the two). For ipAddress, we ought to consider how it will be used. Normally the requirements are for restricting access to a resource so that either (1) it can be accessed ONLY from a particular workstation or group of workstations, or (2) it can NEVER be accessed from a particular workstation or group of workstations. Hence, the precedence in this current draft (05), (highest to lowest): ipAddress access-id, kerberosID group role subtree Comments? >iv) On the same vein, can you explain why IP address should be higher than >access-id, when the former can be used by multiple people, the latter by only >one. It is the issue of specificity again. The more specific a dnType the >higher >its precedence should be. (EJS) See response to iii) above. >v) In my comments to version 4, I mentioned that delete permission for >attribute >values could be needed, as with Modify Entry you both add values and delete >values and replace values (I took your write values permission to mean add). >With separate permissions you can allow some people to add, some to delete, >and some to do both. You said you would look into it, but I don't remember >your reply to this. I would suggest changing "write" to "add", and adding >"delete". (EJS) The write (w) permission is for the ldap_modify operation where that single operation allows add, delete, and replace. We can certainly change this so that write permission is broken into two permissions (add and delete) where replace requires both add and delete. Proposed permissions for this change are 'w' for write/add and 'o' for write/delete (obliterate) where write/replace operation requires both w and o to be set. The question in doing this is do people/applications really make this fine of a distinction in write permissions, for example where someone may write/add but not write/delete (and vice-versa)? Comments? What's the consensus here? >vi) Why can an acl entry only confer multiple rights on a single attribute >name. I >would have expected to allow multiple attribute names within it. >(Version 4 allowed this.) Your later example shows the ldapACI being >repeated in order to give SysAdmins access to attr2 and attr3. Why was the >restriction introduced? (EJS) Several people complained that the syntax was too complicated and hence the restriction. We can certainly remove the restriction so attribute: can have one or more attributes. So you can then specify a grouping of attributes by collection: or by attribute: *. Comments? What's the consensus here? >vii) Section 9 introductory paragraph talks about manipulating access >rights and >getting and setting them. But as I read it, the section only provides a >mechanism to read them, not to update, set or manipulate them. Can you alter >the wording please. (EJS) You are correct. I will alter the wording to reflect read, not write (oversight on my part). From list@netscape.com Wed Mar 15 12:38:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02594 for ; Wed, 15 Mar 2000 12:38:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA12964; Wed, 15 Mar 2000 09:35:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA15235; Wed, 15 Mar 2000 09:37:29 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 09:37:29 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 15 Mar 2000 10:37:16 -0700 From: "Jim Sermersheim" To: Subject: Re: I-D ACTION:draft-ietf-ldapext-ldapv3-dupent-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"WHkDyC.A.xtD.Yp8z4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA02594 Here's a summary of what changed in this version (which wasn't much): - Stated that the number of attributes supported by the server is optional (1-n). This was because specifying a whole grundle of attributes could potentially cause a burden on the server. There is also some language in the implementation section describing the proper error to return in the event that the server doesn't allow the specified number of attributes in the control. - Added a paragraph in the Relationship to Other Controls section about the VLV control. Jim >>> 3/15/00 4:25:39 AM >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the LDAP Extension Working Group of the IETF. Title : LDAP Control for a Duplicate Entry Representation of Search Results Author(s) : J. Sermersheim Filename : draft-ietf-ldapext-ldapv3-dupent-03.txt Pages : 7 Date : 14-Mar-00 This document describes a Duplicate Entry Representation control extension for the LDAP Search operation. By using the control with an LDAP search, a client requests that the server return separate entries for each value held in the specified attributes. For instance, if a specified attribute of an entry holds multiple values, the search operation will return multiple instances of that entry, each instance holding a separate single value in that attribute. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-dupent-03.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-ldapext-ldapv3-dupent-03.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-ldapext-ldapv3-dupent-03.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. From list@netscape.com Wed Mar 15 12:43:22 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04323 for ; Wed, 15 Mar 2000 12:43:22 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA28326; Wed, 15 Mar 2000 09:37:34 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA17634; Wed, 15 Mar 2000 09:42:09 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 09:42:09 -0800 (PST) Message-Id: From: "Courtney, Scott D." To: ietf-ldapext@netscape.com Subject: RE: I-D ACTION:draft-ietf-ldapext-ldap-java-api-10.txt Date: Wed, 15 Mar 2000 12:46:13 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"ebvPeB.A.NTE.wt8z4"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the LDAP Extension Working Group > of the IETF. > > Title : The Java LDAP Application Program Interface > Author(s) : R. Weltman, C. Tomlinson, > J. Sermersheim, M. Smith, T. Howes > Filename : draft-ietf-ldapext-ldap-java-api-10.txt > Pages : 106 > Date : 08-Mar-00 I have reviewed this draft and overall am very pleased with what I see. This looks like a clean, easy-to-use API and the partitioning of functionality seems reasonable to me. A couple of comments, if I may: 1. I think LDAPAttributeSchema should expose all of the parameters with a get/set API. Right now only some of them are exposed. The reasons for this needed feature are twofold: * A programmer might wish to parse the raw string input into its separate fields by simply constructing an LDAPAttributeSchema object and then retrieving the separate parameters from the object. * The clone() method is made more useful if one can create a "nearly identical" object by modifying a clone of the original. This comment might apply to other classes which are mostly data containers as well. 2. Many of the classes should probably implement Serializable to facilitate use in RMI and other distributed environments, or for storage in databases as BLOBS. This wouldn't make much sense for the connection class, but would be useful for the metadata and data entities and for the exceptions. 3. I was very pleased to see such a clear discussion of the ramifications of a clone() operation in section 4.6.2. That's very useful information and serves to "tighten" the behavior of API implementations. 4. In 4.6.10, may I suggest renaming the method to getServerPort() so that it is clear that the port number from the client is NOT being retrieved? Or is this an issue with regard to matching a C/C++ API? Other than these small points, I think this document represents a very fine and readable piece of work, and I commend the authors. Scott Opinions herein are my own and do not necessarily represent those of The Timken Company or its management. ---------------------------------------------------------------------------- ---- Graphical interfaces are great -- you can run dozens of command lines in them! Scott D. Courtney, Senior Technical Analyst; The Timken Company, Canton OH (USA) Email: courtney@timken.com Intranet Web: http://www.cis.corp.inside.tkr/~courtney/ Public Web: http://www.timken.com/ Personal Web: http://www.4th.com/ From list@netscape.com Wed Mar 15 17:38:48 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05474 for ; Wed, 15 Mar 2000 17:38:45 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA13629; Wed, 15 Mar 2000 14:32:53 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA04609; Wed, 15 Mar 2000 14:37:28 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 14:37:28 -0800 (PST) Message-ID: <918C79AB552BD211A2BD00805F15CE8502C95355@x-crt-es-ms1.cp10.es.xerox.com> From: "Manros, Carl-Uno B" To: ietf-ldapext@netscape.com Cc: IETF-IPP , =?ISO-8859-1?Q?=22F=E4ltstr=F6m=2C_Patrik=22?= , "Freed, Ned" , "Moore, Keith" Subject: FW: IPP> I-D ACTION:draft-ietf-ipp-ldap-printer-schema-00.txt Date: Wed, 15 Mar 2000 14:36:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF8ECE.D89CA0A6" Resent-Message-ID: <"q4IKeB.A.vHB.mCB04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BF8ECE.D89CA0A6 Content-Type: text/plain; charset="ISO-8859-1" Hi, The IPP WG has been working with a couple of LDAP experts to produce a first I-D for a LDAP printer schema, see details below. I would like to have a wider review of this document from the experts in the LDAPEXT WG to make certain that we have got it right before making an IPP WG Last Call for subsequent submission to the IESG. The draft has been synchronized to align with the directory requirements in the IPP specs for IPP/1.1, which is currently under IESG review, but is also applicable for other commonly used printing protocols. This draft has also been synchronized with and is in effect derived from a corresponding SLP schema draft: I will put discussion of this IPP LDAP document on the agenda for the IPP WG in IETF47. We are meeting on the Tuesday afternoon. Please try to attend if you have comments that you want to discuss. Regards, Carl-Uno Manros Chair of IETF IPP WG -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, March 10, 2000 3:29 AM Cc: ipp@pwg.org Subject: IPP> I-D ACTION:draft-ietf-ipp-ldap-printer-schema-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Printing Protocol Working Group of the IETF. Title : Internet Printing Protocol (IPP): LDAP Schema for Printer Services Author(s) : P. Fleming, K. Jones, H. Lewis, I. McDonald Filename : draft-ietf-ipp-ldap-printer-schema-00.txt Pages : 26 Date : 09-Mar-00 This document defines a common printer schema for use with LDAP directories (a directory service supporting the Lightweight Directory Access Protocol (LDAP)). Using this common printer schema enables client applications to use LDAP to search for printers using application or user specified search criteria. Searches are defined based on the entry's type and attributes independent of the LDAP directory being used. This document describes the LDAP schema, object classes and attributes, for SLP printer templates. This document uses the printer attributes defined in Appendix E. of [IPPMOD], the 'printer:' service template defined in [SLPPRT], and the mapping between SLP service advertisements and LDAP descriptions of services defined in [SLPLDAP] to define an LDAP printer schema. The goal of this document is to define a consistent schema to be used by printers and print servers. The LDAP printer schema described in this document MAY be used in part or whole. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipp-ldap-printer-schema-00.tx t 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-ipp-ldap-printer-schema-00.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-ipp-ldap-printer-schema-00.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_000_01BF8ECE.D89CA0A6 Content-Type: message/rfc822 To: Subject: Date: Fri, 10 Mar 2000 03:33:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF8ECE.D89CA0A6" ------_=_NextPart_002_01BF8ECE.D89CA0A6 Content-Type: text/plain ------_=_NextPart_002_01BF8ECE.D89CA0A6 Content-Type: application/octet-stream; name="ATT17988.txt" Content-Disposition: attachment; filename="ATT17988.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipp-ldap-printer-schema-00.txt ------_=_NextPart_002_01BF8ECE.D89CA0A6 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-ipp-ldap-printer-schema-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BF8ECE.D89CA0A6-- ------_=_NextPart_000_01BF8ECE.D89CA0A6-- From list@netscape.com Wed Mar 15 19:53:19 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24465 for ; Wed, 15 Mar 2000 19:53:19 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA18316; Wed, 15 Mar 2000 16:49:51 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA24895; Wed, 15 Mar 2000 16:52:14 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 16:52:14 -0800 (PST) From: "David Chadwick" Organization: University of Salford To: ietf-ldapext@netscape.com, Ellen Stokes Date: Thu, 16 Mar 2000 00:51:12 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: please publish (draft-ietf-ldapext-acl-model-05.txt) Reply-to: d.w.chadwick@salford.ac.uk CC: djbyrne@us.ibm.com, blakley@dascom.com Priority: normal In-reply-to: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> References: X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: Resent-Message-ID: <"59ZjiB.A.lEG.8AD04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7BIT Date forwarded: Wed, 15 Mar 2000 08:16:23 -0800 (PST) Date sent: Wed, 15 Mar 2000 10:15:28 -0600 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Ellen Stokes Subject: Re: please publish (draft-ietf-ldapext-acl-model-05.txt) Copies to: djbyrne@us.ibm.com, blakley@dascom.com Forwarded by: ietf-ldapext@netscape.com > Responses embedded below and prefaced by (EJS) > Ellen > > >Comments on ACL model 05 > > > >i) I think it is extra clutter to have familyOID as the first > >component of the ldapACI attribute type, and does not buy us > >anything. If you want to define another set of permissions, then > >simply give them a new attribute type (e.g. ldapACIv2) which is > >itself an OID. It serves no good purpose to have one OID for the > >ldapACI attribute then another OID for the family. You might as well > >have just one OID that means precisely one set of permissions and > >access control information. > > (EJS) We could do as you suggest, but I'd rather not. I believe that > it is better to have a single attribute known for ldap access control > rather than proliferate more attributes for this purpose and let the > family OID control the remaining information. This provides an > application with one way of accessing access control information, > although it may still have to parse out the information. If we start > propagating different attributes for ldap access control, then it is > difficult, if not impossible, for the application to know which ldap > access control attribute it needs to invoke. Sorry, I dont buy this, since the application will have to know all the family OIDs if it is to be able to understand the meaning and content of the aci. There is thus no difference between having to know the OIDs of families or the OIDs of the attribute types. You have not saved anything by nesting families in a single attribute type (other than forcing them to all have the same syntax). Different code will be needed for each family OID, just as different code will be needed if it were different attribute types. Therefore I still believe the family OID is just extra clutter that actually buys you nothing. > > > >ii) I made a comment on 04 about ReadDN that I don't believe has been > >addressed yet. There is a difference between letting someone have > >access to an entry they know exists, and ones they don't know exist. > >I.e. there is a difference in permissions needed for the base object > >of a Search and the entries beneath the base object (the latter is a > >greater permission than the former). At the moment BrowseDN gives the > >latter permission, but there is not the lesser permission of > >accessing an entry whose name you already know. This would call for a > >ReadDN permission I believe. Comments please on this. > > (EJS) BrowseDN is ReadDN. I know that. What I was saying is that there is not a lesser permission than BrowseDN that only allows a read if you know the name beforehand. (Consider web access for example. There are many web pages that you can only access if you know the URL beforehand, but cannot browse to look for them) >BrowseDN allows that DN in a search. This > allows someone access to only information that he has been authorized > for. A person may know that an entry exists, but just because he does > have that knowledge does not mean he can access it. Likewise, if a > person doesn't know an entry exists doesn't mean that he should be > able to discover it. Agreed, but you do not currently have a way of allowing someone to access something they know exists and not have access to something they dont know exists. This is what I am suggesting should be added. > > > >iii) Precedence of privilege dnTypes. I would argue that role comes > >higher than group as it is more specific. By this I mean that group > >membership is usually conferred on more people than are roles (and as > >you said in October, roles can be regarded as groups with > >permissions). I would expect my role of abc administrator to have > >more weight than simply a member of the IETF LDAP group. > > The following is a cut and paste from Bob Blakley's reasoning in his > prior email on the precedence stated in this current draft. > > The underlying implementation of the access decision function (which > looks at ACL entries and compares them against the subject's > credentials to render a yes/no decision about a particular access > request) may treat "group" entries differently from "role" entries. > For example, it might implement "union semantics" for groups but > "intersection semantics" for roles. Thus if an ACL contained 4 > entries: > > group1 : grant (read, search) > group2 : grant (update) > role1 : grant (read, search) > role2 : grant (update) > > A subject belonging to group1 and group2 would be granted access > (because union semantics grants access if any group grants access), > but a subject belonging to role1 and role2 would be denied access > (because intersection semantics grants access only if all roles grant > access). > > This ability to distinguish groups and roles semantically is > important. It permits security administrators to have two different > subject collection constructs with different granularities and > different dynamism. Roles (not role attributes -- actual roles) are > typically defined at a fairly high organizational level and changed > infrequently. The authorizations granted to role attributes mirror the > organizational responsibilities associated with the roles. > > However in modern organizations roles don't describe the "entire job" > of an individual -- the VP of marketing may be assigned (for a short > time) to a task force evaluating the technical competitiveness of a > product. To participate in this activity, she may need access to > engineering data to which her job role (or roles) as marketing VP > don't entitle her. The CFO and the East Region Helpdesk Director may > also be on the taskforce, and may need access to the same data. To > grant the desired access to all three of these individuals, it would > be possible to individually authorize them to the data -- but this > would be bad for several reasons. The first is scale -- for three > people this would be feasible, but for 30 it would be unpleasant, and > for 3000 it would be impractical (especially in organizations which > run lots of task forces or have lots of matrix management). The second > is that if you simply put individual entries on the ACL, you might > forget who the individuals are and why they're on the ACL. In this > case you'd very likely forget to take them off the ACL when the task > force ended, thus creating a need-to-know violation. > > On the other hand, defining a new "role" for the task force is bad > also: task force membership isn't really a role; it's really an > assignment. Adding lots of roles to the role namespace pollutes the > policy environment and makes it very difficult for the enterprise > policy administrators, whose job is defining work roles and their > proper authorizations, to do their work. > > What's really called for is defining a "group" -- an ad-hoc collection > of users who can be authorized to the specific set of resources for > the duration of the project as an *exception* to the role-based > policy. The group should be given an evocative name (like the name of > the project) and should be authorized to the resource. When the > project ends, the group can be deleted, and its entries can be removed > from the associated resource ACLs. > > As this example suggests, in order to support using groups as > exceptions to roles, group attributes and role attributes need to have > different precedence. As the example also suggests, I think groups > should have *higher* precedence than roles, since roles are > essentially a coarse-grained, static, subject collection, and groups > are a fine-grained, dynamic subject collection. > > Note that many existing security models, including ISO, ECMA-138, > CORBA, and others include both groups and roles (and type-distinguish > the two). I follow this and agree with the example as far as it goes, but fail to see how the example supports the case for multiple role permissions to be intersection and not union, which appeared to be the rationale for the example, did it not? Also Bob has not said how role and group should combine together - would it be union or intersection? If it were union, then the precedence of group could be below role and his example would still work, would it not? Therefore can Bob explain why the example is arguing for group above role. > > For ipAddress, we ought to consider how it will be used. Normally the > requirements are for restricting access to a resource so that either > (1) it can be accessed ONLY from a particular workstation or group of > workstations, or (2) it can NEVER be accessed from a particular > workstation or group of workstations. I can buy into this one as the highest precedence for the reason stated. > > Hence, the precedence in this current draft (05), (highest to lowest): > ipAddress access-id, kerberosID group role subtree > > > > >v) In my comments to version 4, I mentioned that delete permission > >for attribute values could be needed, as with Modify Entry you both > >add values and delete values and replace values (I took your write > >values permission to mean add). With separate permissions you can > >allow some people to add, some to delete, and some to do both. You > >said you would look into it, but I don't remember your reply to this. > >I would suggest changing "write" to "add", and adding "delete". > > (EJS) The write (w) permission is for the ldap_modify operation where > that single operation allows add, delete, and replace. We can > certainly change this so that write permission is broken into two > permissions (add and delete) where replace requires both add and > delete. Proposed permissions for this change are 'w' for write/add > and 'o' for write/delete (obliterate) where write/replace operation > requires both w and o to be set. The question in doing this is do > people/applications really make this fine of a distinction in write > permissions, for example where someone may write/add but not > write/delete (and vice-versa)? Comments? What's the consensus here? Ellen I think this is the best way forward, to see what people actually want. I was raising the topic for precisely that reason. > > > >vi) Why can an acl entry only confer multiple rights on a single > >attribute name. I would have expected to allow multiple > >attribute names within it. (Version 4 allowed this.) Your later > >example shows the ldapACI being repeated in order to give SysAdmins > >access to attr2 and attr3. Why was the restriction introduced? > > (EJS) Several people complained that the syntax was too complicated > and hence the restriction. We can certainly remove the restriction so > attribute: can have one or more attributes. So you can then specify a > grouping of attributes by collection: or by > attribute: *. Comments? What's the consensus here? Again this seems to be the best way forward, lets get some opinions. I would argue for allowing multiple attribute types, rather than inventing a new collectionname that is only locally known and has to be broadcase to applications for them to understand it. David *************************************************** David Chadwick IS Institute, University of Salford, Salford M5 4WT Tel +44 161 295 5351 Fax +44 161 745 8169 Mobile +44 790 167 0359 Email D.W.Chadwick@salford.ac.uk Home Page http://www.salford.ac.uk/its024/chadwick.htm Understanding X.500 http://www.salford.ac.uk/its024/X500.htm X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string MLJ9-DU5T-HV8J *************************************************** From list@netscape.com Wed Mar 15 20:32:12 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08943 for ; Wed, 15 Mar 2000 20:32:11 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA23288; Wed, 15 Mar 2000 17:28:44 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA17959; Wed, 15 Mar 2000 17:31:07 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 17:31:07 -0800 (PST) Message-Id: <3.0.5.32.20000315173053.00922100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 15 Mar 2000 17:30:53 -0800 To: d.w.chadwick@salford.ac.uk From: "Kurt D. Zeilenga" Subject: Re: please publish (draft-ietf-ldapext-acl-model-05.txt) Cc: ietf-ldapext@netscape.com, Ellen Stokes , djbyrne@us.ibm.com, blakley@dascom.com In-Reply-To: References: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"yCSJ3B.A.VYE.alD04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:51 AM 3/16/00 -0000, David Chadwick wrote: >Date forwarded: Wed, 15 Mar 2000 08:16:23 -0800 (PST) >Date sent: Wed, 15 Mar 2000 10:15:28 -0600 >To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com >From: Ellen Stokes >Subject: Re: please publish (draft-ietf-ldapext-acl-model-05.txt) >Copies to: djbyrne@us.ibm.com, blakley@dascom.com >Forwarded by: ietf-ldapext@netscape.com > >> Responses embedded below and prefaced by (EJS) >> Ellen >> >> >Comments on ACL model 05 >> > >> >i) I think it is extra clutter to have familyOID as the first >> >component of the ldapACI attribute type, and does not buy us >> >anything. If you want to define another set of permissions, then >> >simply give them a new attribute type (e.g. ldapACIv2) which is >> >itself an OID. It serves no good purpose to have one OID for the >> >ldapACI attribute then another OID for the family. You might as well >> >have just one OID that means precisely one set of permissions and >> >access control information. >> >> (EJS) We could do as you suggest, but I'd rather not. I believe that >> it is better to have a single attribute known for ldap access control >> rather than proliferate more attributes for this purpose and let the >> family OID control the remaining information. This provides an >> application with one way of accessing access control information, >> although it may still have to parse out the information. If we start >> propagating different attributes for ldap access control, then it is >> difficult, if not impossible, for the application to know which ldap >> access control attribute it needs to invoke. > >Sorry, I dont buy this, since the application will have to know all the >family OIDs if it is to be able to understand the meaning and content >of the aci. There is thus no difference between having to know the >OIDs of families or the OIDs of the attribute types. You have not >saved anything by nesting families in a single attribute type (other >than forcing them to all have the same syntax). Different code will be >needed for each family OID, just as different code will be needed if >it were different attribute types. Therefore I still believe the family >OID is just extra clutter that actually buys you nothing. I concur with David. In particular, I do not think the ACI families we conjure up tomorrow should be limited to today's attribute type definition. Tomorrow's ACI families may require unthought of syntaxes and matching rules. >> >v) In my comments to version 4, I mentioned that delete permission >> >for attribute values could be needed, as with Modify Entry you both >> >add values and delete values and replace values (I took your write >> >values permission to mean add). With separate permissions you can >> >allow some people to add, some to delete, and some to do both. You >> >said you would look into it, but I don't remember your reply to this. >> >I would suggest changing "write" to "add", and adding "delete". >> >> (EJS) The write (w) permission is for the ldap_modify operation where >> that single operation allows add, delete, and replace. We can >> certainly change this so that write permission is broken into two >> permissions (add and delete) where replace requires both add and >> delete. Proposed permissions for this change are 'w' for write/add >> and 'o' for write/delete (obliterate) where write/replace operation >> requires both w and o to be set. The question in doing this is do >> people/applications really make this fine of a distinction in write >> permissions, for example where someone may write/add but not >> write/delete (and vice-versa)? Comments? What's the consensus here? > >Ellen I think this is the best way forward, to see what people actually >want. I was raising the topic for precisely that reason. Personally, I'd prefer attribute modify operation be control by a single permission. However, if the consensus is to have finer grained control, I suggest breaking into three permissions which relate directly to modify/add, modify/replace, and modify/delete operations. >> >vi) Why can an acl entry only confer multiple rights on a single >> >attribute name. I would have expected to allow multiple >> >attribute names within it. (Version 4 allowed this.) Your later >> >example shows the ldapACI being repeated in order to give SysAdmins >> >access to attr2 and attr3. Why was the restriction introduced? >> >> (EJS) Several people complained that the syntax was too complicated >> and hence the restriction. We can certainly remove the restriction so >> attribute: can have one or more attributes. So you can then specify a >> grouping of attributes by collection: or by >> attribute: *. Comments? What's the consensus here? > >Again this seems to be the best way forward, lets get some opinions. >I would argue for allowing multiple attribute types, rather than >inventing a new collectionname that is only locally known and has to >be broadcase to applications for them to understand it. I think a list of attributes should be allowed and that collections concept dropped. From list@netscape.com Wed Mar 15 21:45:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02923 for ; Wed, 15 Mar 2000 21:45:51 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA14430; Wed, 15 Mar 2000 18:40:06 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA12395; Wed, 15 Mar 2000 18:44:42 -0800 (PST) Resent-Date: Wed, 15 Mar 2000 18:44:42 -0800 (PST) Message-Id: <3.0.5.32.20000315184429.0091e100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 15 Mar 2000 18:44:29 -0800 To: Ellen Stokes From: "Kurt D. Zeilenga" Subject: ldapACI syntax and matching rules and more Cc: ietf-ldapext@netscape.com In-Reply-To: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> References: <4.2.2.20000310133633.00a451c0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"EGNg_C.A.ZBD.ZqE04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Just did very quick read of the latest draft. A few comments and questions. Please note that I (still) believe ldapACI should have a syntax which requires values to conform to the BNF described by Section 6.1 of the draft and that the equality matching rule be "syntax aware". In particular, the equality matching rule should treat any two ACI which have same meaning but different form to be equal. That is: ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#group#cn="Dept, XYZ",c=US ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#CN="dept, xyz",c=us ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#cn=Dept\, XYZ,c=US ldapACI:1.2.3.4#subtree#grant;c,s,r;attribute:xx#group#cn="Dept, XYZ",c=US ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:1.1.1#group#cn="Dept, XYZ",c=US where x is defined as ( 1.1.1 NAME ( 'x' $ 'xx' ) SUP 'name' ) should all be considerred equal. CaseIgnoreString does cut it... besides not handling the above, it would consider these as being the same: ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#KerberosID#user@REALM ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#KerberosID#USER@realm user != USER and REALM != realm. Also, I think KerberosId should be generalized. I suggest referring to it as a UserId which allows any UTF-8 printable string. This maps better onto authmeth's authzid "u:". If left as a KerberosId, it should not be a SHOULD. The BNFs appear underspecified. < printable string > allows too many characters which hinder (or disallow) parsing. A < subject DN > should be an RFC 2253 DN string. < oid > should be a RFC 2252 numericoid. A few questions: How does a ACL granting access to an attribute types superior affect access the attribute type? Ie: does granting access to 'name' allow access to 'cn'? I see that ACLs on attribute subtypes (cn;lang-US) are disallowed. Is this intentional? If so, why? If not, any syntax issues due to the attribute description's ';'(s) (could have more than one). Why is ipAddress restricted to the "dotted-decimal string representation"? This restricts ipAddress to IPv4 addresses. A reference to exact ipAddress form should be provided. [I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8 or 10.0.0.0:255.0.0.0] Kurt From list@netscape.com Thu Mar 16 07:03:02 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01406 for ; Thu, 16 Mar 2000 07:02:58 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA18981; Thu, 16 Mar 2000 03:57:08 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id EAA08156; Thu, 16 Mar 2000 04:01:43 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 04:01:43 -0800 (PST) Message-Id: <200003161201.EAA23059@ywing.netscape.com> From: "Alexander" To: "A good opportunity for u" Date: Thu, 16 Mar 2000 12:51:29 +0100 Subject: Surfingprize brand new Get-paid-programm (very good) Reply-To: Eugen@okay.net MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 1 Resent-Message-ID: <"FyKJYD.A.D_B.m0M04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit SurfingPrizes: A viewBar type that: The referral structure is 5 levels deep: For your surfing time, you'll receive $0.20 per hour; for your direct referrals, you'll earn $0.04/hour; and for your indirect referrals you'll earn $0.02/hour. For 5 levels deep! ViewBar Ver 1.0 Avalible for Win 95,98,NT Site is well laid out and snappy. I'm only number 786 in this one. Sign-up Here: http://www.surfingprizes.com/r/?100786 Thanks for sign-up under me Alexander Eugen@okay.net From list@netscape.com Thu Mar 16 11:10:18 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28624 for ; Thu, 16 Mar 2000 11:10:17 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA06439; Thu, 16 Mar 2000 08:04:37 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA01640; Thu, 16 Mar 2000 08:09:03 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 08:09:03 -0800 (PST) From: George_Robert_Blakley_III@tivoli.com X-Lotus-FromDomain: TIVOLI SYSTEMS To: "Kurt D. Zeilenga" cc: Ellen Stokes , ietf-ldapext@netscape.com Message-ID: <862568A4.004B26C5.00@tivmta4.tivoli.com> Date: Thu, 16 Mar 2000 10:10:02 -0600 Subject: Re: ldapACI syntax and matching rules and more Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"IYxlzC.A.WZ.ecQ04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Kurt et. al.: Here are a few of my reactions: >Also, I think KerberosId should be generalized. I suggest >referring to it as a UserId which allows any UTF-8 printable >string. This maps better onto authmeth's authzid "u:". >If left as a KerberosId, it should not be a SHOULD. This is "OK", but it needs to be possible to avoid name capture in cases where different authentication mechanisms are supported to the same directory. I don't want someone to be able to use a "foo-name" which is lexically the same as someone else's kerberosid to get access to resources illicitly. >The BNFs appear underspecified. < printable string > allows >too many characters which hinder (or disallow) parsing. A >< subject DN > should be an RFC 2253 DN string. < oid > >should be a RFC 2252 numericoid. I'll defer to those more knowledgeable on these. >How does a ACL granting access to an attribute types superior affect >access the attribute type? Ie: does granting access to 'name' >allow access to 'cn'? In the current draft the answer is no, and I'd prefer to keep it this way in order to keep the ACL resolution algorithm simple. If we implement semantics like these, then we need to do bunch of type resolution at access check time -- could be a performance problem. >Why is ipAddress restricted to the "dotted-decimal string >representation"? This restricts ipAddress to IPv4 addresses. >A reference to exact ipAddress form should be provided. >[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8 >or 10.0.0.0:255.0.0.0] Again, I don't want to do wildcarding because it requires a complicated evaluation code-path at access check time. However I agree it would be good to have some proposal which supports IPv6. --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit From list@netscape.com Thu Mar 16 11:42:29 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11830 for ; Thu, 16 Mar 2000 11:42:28 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA28733; Thu, 16 Mar 2000 08:38:59 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA16981; Thu, 16 Mar 2000 08:41:22 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 08:41:22 -0800 (PST) Message-Id: <3.0.5.32.20000316084109.00955c30@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Mar 2000 08:41:09 -0800 To: George_Robert_Blakley_III@tivoli.com From: "Kurt D. Zeilenga" Subject: Re: ldapACI syntax and matching rules and more Cc: Ellen Stokes , ietf-ldapext@netscape.com In-Reply-To: <862568A4.004B26C5.00@tivmta4.tivoli.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"TK_nZC.A.DJE.x6Q04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 10:10 AM 3/16/00 -0600, George_Robert_Blakley_III@tivoli.com wrote: >>Also, I think KerberosId should be generalized. I suggest >>referring to it as a UserId which allows any UTF-8 printable >>string. This maps better onto authmeth's authzid "u:". >>If left as a KerberosId, it should not be a SHOULD. > >This is "OK", but it needs to be possible to avoid name capture >in cases where different authentication mechanisms are supported to the >same directory. I don't want someone to be able to use a >"foo-name" which is lexically the same as someone else's kerberosid >to get access to resources illicitly. To resolve this issue, I suggest relating the ACI "userid" to the Authmeth AuthzId "u:". As new forms were added to AuthzId, a new form can be added to ACIs (and vice versa). >>How does a ACL granting access to an attribute types superior affect >>access the attribute type? Ie: does granting access to 'name' >>allow access to 'cn'? > >In the current draft the answer is no, and I'd prefer to keep it >this way in order to keep the ACL resolution algorithm simple. If we >implement semantics like these, then we need to do bunch of type >resolution at access check time -- could be a performance problem. I would note that ACL management already requires a bunch of type resolution checks to handle attribute subtypes (ie: lang- tags) and alternative name forms (OID vs. multiple names). Given this (and my experience implementing such) the performance hit of checking superiors (via sup) is actually quite minimal and, depending on the implementation quite natural (ie: it may actually be harder NOT to provide such support). >>[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8 >>or 10.0.0.0:255.0.0.0] >Again, I don't want to do wildcarding because it requires a complicated >evaluation >code-path at access check time. Even where that complication makes rules easier to manage and likely to be much "quicker"? The example I gave would require 2^24 times more ACI values to implement without wildcarding. Kurt From list@netscape.com Thu Mar 16 13:37:40 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23090 for ; Thu, 16 Mar 2000 13:37:39 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA28258; Thu, 16 Mar 2000 10:31:22 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA17645; Thu, 16 Mar 2000 10:35:57 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 10:35:57 -0800 (PST) Message-Id: <4.2.2.20000316122955.00a28ea0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Mar 2000 12:38:01 -0600 To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com From: Ellen Stokes Subject: ldapACI: familyOID Cc: djbyrne@us.ibm.com, blakley@dascom.com In-Reply-To: References: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"y4OUEC.A.bTE.MmS04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:51 AM 3/16/00 +0000, David Chadwick wrote: >Date forwarded: Wed, 15 Mar 2000 08:16:23 -0800 (PST) >Date sent: Wed, 15 Mar 2000 10:15:28 -0600 >To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com >From: Ellen Stokes >Subject: Re: please publish >(draft-ietf-ldapext-acl-model-05.txt) >Copies to: djbyrne@us.ibm.com, blakley@dascom.com >Forwarded by: ietf-ldapext@netscape.com > > > Responses embedded below and prefaced by (EJS) > > Ellen > > > > >Comments on ACL model 05 > > > > > >i) I think it is extra clutter to have familyOID as the first > > >component of the ldapACI attribute type, and does not buy us > > >anything. If you want to define another set of permissions, then > > >simply give them a new attribute type (e.g. ldapACIv2) which is > > >itself an OID. It serves no good purpose to have one OID for the > > >ldapACI attribute then another OID for the family. You might as well > > >have just one OID that means precisely one set of permissions and > > >access control information. > > > > (EJS) We could do as you suggest, but I'd rather not. I believe that > > it is better to have a single attribute known for ldap access control > > rather than proliferate more attributes for this purpose and let the > > family OID control the remaining information. This provides an > > application with one way of accessing access control information, > > although it may still have to parse out the information. If we start > > propagating different attributes for ldap access control, then it is > > difficult, if not impossible, for the application to know which ldap > > access control attribute it needs to invoke. > >Sorry, I dont buy this, since the application will have to know all the >family OIDs if it is to be able to understand the meaning and content >of the aci. There is thus no difference between having to know the >OIDs of families or the OIDs of the attribute types. You have not >saved anything by nesting families in a single attribute type (other >than forcing them to all have the same syntax). Different code will be >needed for each family OID, just as different code will be needed if >it were different attribute types. Therefore I still believe the family >OID is just extra clutter that actually buys you nothing. (EJS) A case where family OID could be useful is where the current ldapACI attribute permission set is just extended, such as for adding get/set/manage/use (which we removed from this draft). However, I see both points of view. So, comments on this topic, please, What's the consensus? > From list@netscape.com Thu Mar 16 13:43:33 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25127 for ; Thu, 16 Mar 2000 13:43:30 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA29743; Thu, 16 Mar 2000 10:38:05 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA21958; Thu, 16 Mar 2000 10:42:42 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 10:42:42 -0800 (PST) Message-ID: <38D12ABE.7BA8D670@netscape.com> Date: Thu, 16 Mar 2000 13:41:02 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ellen Stokes CC: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, djbyrne@us.ibm.com, blakley@dascom.com Subject: Re: ldapACI: familyOID References: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> <4.2.2.20000316122955.00a28ea0@popmail2.austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"QwGXVB.A.gWF.gsS04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Ellen Stokes wrote: > > (EJS) A case where family OID could be useful is where the current > ldapACI attribute permission set is just extended, such as for adding > get/set/manage/use (which we removed from this draft). However, I > see both points of view. So, comments on this topic, please, What's > the consensus? I believe that we need extensibility, even within the ldapACI scheme. That could be accomplished with the family OID or with a simple version (LDAP ACI v1, LDAP ACI v2, ...). -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Thu Mar 16 13:44:25 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25499 for ; Thu, 16 Mar 2000 13:44:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA25702; Thu, 16 Mar 2000 10:40:25 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA21894; Thu, 16 Mar 2000 10:42:39 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 10:42:39 -0800 (PST) Message-Id: <4.2.2.20000316123923.00a11410@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Mar 2000 12:44:54 -0600 To: "Kurt D. Zeilenga" , d.w.chadwick@salford.ac.uk From: Ellen Stokes Subject: ldapACI: collection and attribute list Cc: ietf-ldapext@netscape.com, djbyrne@us.ibm.com, blakley@dascom.com In-Reply-To: <3.0.5.32.20000315173053.00922100@infidel.boolean.net> References: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"SZJC2.A.xVF.esS04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 05:30 PM 3/15/00 -0800, Kurt D. Zeilenga wrote: >At 12:51 AM 3/16/00 -0000, David Chadwick wrote: > >Date forwarded: Wed, 15 Mar 2000 08:16:23 -0800 (PST) > >Date sent: Wed, 15 Mar 2000 10:15:28 -0600 > >To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com > >From: Ellen Stokes > >Subject: Re: please publish > (draft-ietf-ldapext-acl-model-05.txt) > >Copies to: djbyrne@us.ibm.com, blakley@dascom.com > >Forwarded by: ietf-ldapext@netscape.com > > > >> >vi) Why can an acl entry only confer multiple rights on a single > >> >attribute name. I would have expected to allow multiple > >> >attribute names within it. (Version 4 allowed this.) Your later > >> >example shows the ldapACI being repeated in order to give SysAdmins > >> >access to attr2 and attr3. Why was the restriction introduced? > >> > >> (EJS) Several people complained that the syntax was too complicated > >> and hence the restriction. We can certainly remove the restriction so > >> attribute: can have one or more attributes. So you can then specify a > >> grouping of attributes by collection: or by > >> attribute: *. Comments? What's the consensus here? > > > >Again this seems to be the best way forward, lets get some opinions. > >I would argue for allowing multiple attribute types, rather than > >inventing a new collectionname that is only locally known and has to > >be broadcase to applications for them to understand it. > >I think a list of attributes should be allowed and that collections >concept dropped. (EJS) I'll add back the list of attributes (e.g. attribute: *). However, collection is still a valuable ease of administration concept. I understand that a new collection name that might only be known locally could be a concern, but implementation could code around it to say that if it's not understood, then it's not supported. I'd like to retain this construct. Any other opinions? From list@netscape.com Thu Mar 16 13:53:29 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29050 for ; Thu, 16 Mar 2000 13:53:28 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA01666; Thu, 16 Mar 2000 10:47:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA27844; Thu, 16 Mar 2000 10:52:25 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 10:52:25 -0800 (PST) Date: Thu, 16 Mar 2000 13:51:48 -0500 Message-Id: <200003161851.NAA21671@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: blakley@dascom.com, djbyrne@us.ibm.com, stokes@austin.ibm.com Subject: Comments on the ACL Model draft Cc: ietf-ldapext@netscape.com Resent-Message-ID: <"hU6RsB.A.yyG.o1S04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This is a joint set of comments from Ryan Moats and Rick Huber. We've been discussing them internally for a while, so they may repeat some of the last day's discussion on the list, but there is a fair amount of new material here. Rick Huber --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Page 3 TECHNICAL: No mechanisms are defined in this document to control access to access control information or for storage of access control information at the server; this is vendor dependent. But the ACIs are attributes. Don't the normal access controls described in the rest of the draft apply here? EDITORIAL: Add reference to ACL Requirements document in last paragraph. Page 5: EDITORIAL: A "subject' is an entity which initiate actions in an ^ ^^^^^^^^ information system. The quotes on subject don't match. Also, "initiate" should be either "may initiate" or "initiates". TECHNICAL: How is a "role" really different from a "group" which contains all of the subjects in the organizational position that the role represents? In Ellen's response to Dave Chadwick's questions, she quotes Bob Blakley's previous posting on this. Bob's posting talks about having different semantics for combinations (union semantics vs. intersection semantics), but the model in the draft does not seem to allow for different merging semantics, so some of the reason to separate roles and groups is not present. Page 7: EDITORIAL: Add Section number at end of last paragraph. Page 9: EDITORIAL: aCIMechanisms lists the values (list of OIDs) that defines the access control mechanism in effect for the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ scope of that subschema entry. More than one mechanism may be in effect for the scope of that subschema entry. Should be "define the access control mechanisms" since it explicitly notes that there can be more than one. EDITORIAL: The intent of the following attribute definitions is to design a common interchange format. Any given LDAP server should be able to translate the below defined attributes into a meaningful operation requests. Each ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ server should be able to understand the attributes; there should not be any ambiguity into what any part of the syntax means. Should be "into meaningful operation requests" (drop the "a"). EDITORIAL: quote mismatch and add section number in second to last paragraph. ABNF: TECHNICAL: RFC 2234 gives standards for IETF ABNF, and the BNF in the draft does not match the standards. That drove many of the changes in our suggested replacement, the reasons for other changes are commented. We suggest replacing the BNF with the following ABNF and including references to RFCs 2234, 2252, and 2253: Open issues: 1. Is the internal structure of a kerberosID really important in this context? Can't we just leave as a terminal token for this ABNF? 2. Are the quoted strings in the ABNF (e.g. "deny", "public") meant to be case sensitive or case insensitive? RFC2234 assumes that quoted strings are case insensitive. If they are meant to be case sensitive, RFC2234 requires that some really awful stuff be done to the grammar. = ; left angle bracket replaces pound sign since pound sign is legal in ; distinguished name per RFC 2253 DN specification and RFC 2252 attribute ; definitions (inherited from ). This was chosen because it cannot ; appear in unescaped form in DNs (see 2253) or in attribute names at all ; (see 2252). Also, was changed to since it is ; not always a DN (it might be an or ). = "<" "<" "<" "<" = "<" "<" "<" ; is defined in RFC 2253 = / "public" / "this" / / = = "entry" / "subtree" ; the printableString definitions in , , and ; need to be more specific in terms of how to handle escaping of ; characters used literally in this ABNF spec = "access-id" / "role" / "group" / "subtree" / "ipAddress" / "kerberosID" / ; = "@" = = ; Pound symbols used below in place of semi-colon since semi-colon can ; appear in attribute name specification per RFC2252. This is really a ; nit - we admit that language and other tags are unlikely to show up ; here to cause syntax ambiguity. = ( "grant#" "#" ) / ( "deny#" "#" ) / ( "grant#" "#deny#" "#" ) = [ *( "," ) ] ; printableString seems too general a syntax for collection name. The ; syntax should be restricted to make sure that delimiter characters (";" ; or "#") can't occur in the collection name. We suggest using ; (defined in RFC 2252) for the attribute name since it better describes ; the allowable syntax for an attribute name. Might as well use it for ; collection name as well. = ( "collection:" ( "[all]" / "[entry]" / ) ) / ( "attribute:" ) = "a" / "d" / "r" / "s" / "w" / "c" / "e" / "b" Page 10: EDITORIAL: Two attributes are defined so access control information (ACI) can be addressed in a server independent of server implementation. These attributes are used in typical LDAP APIs and in LDIF output of ACI. These two attributes may be queried or set on all directory objects: ldapACI and policyOwner. Their BNF and definitions are defined ^^^^^^^ below. Should be "given" or "presented". Page 12: TECHNICAL: e EditDN Edit an entry's DN b BrowseDN Browse an entry's DN How is EditDN permission different from Write permission on the naming attribute? How is BrowseDN permission different from Search permission on the naming attribute? Can I have EditDN permission on the entry without explicit Write permission on the naming attribute of the entry? What would it mean? And do we really need both Search and Compare permissions? Page 14: TECHNICAL: describes either an attribute name or an attribute collection. The keyword attribute indicates that the following printable string refers to an attribute name. If the string refers to an attribute not defined in the given server's schema, the server SHOULD report an error. The keyword "collection" indicates that the string that follows describes a group of attributes. The method for ^^^^^^^^^^^^^^ grouping attributes is server specific. Another option ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ for the collection printable string is "[entry]". This is ... This seems to say that no ACI containing an attribute collection can be portable between vendors' LDAP products. Since attribute grouping may well be common (if you have a number of attributes that are always treated the same way for access control) this seems to be a major interoperability problem. Wouldn't it be better to require that the wire protocol list all the attributes and leave collections as a shortcut that some vendors' products may use in their administrative interface? Note we do not object to "[all]" and "[entry]" since they are well defined, we just have a problem with the server specific collections. TECHNICAL: What's the interaction between "[entry]" and attributes: if somebody has add permission for objects but is denied permissions for certain attributes, what happens? Page 15: TECHNICAL: means that this group (Dept XYZ) is granted permission to read and search all attributes except attr1 because attr1 is more specific than "[all]". ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ What if it were two collections rather than specific attribute vs. [all]? How do you determine which is "more specific"? TECHNICAL: More specific policies must override less specific ones (e.g. individual user entry in ACI takes precedence over ^^^^ group entry). The "e.g." makes us very nervous. There needs to be a solid definition of what "more specific" means to avoid problems of interpretation by different developers. Also, what would happen if a DN was a member of two groups, where one had rights while the other did not? An example on page 20 says to take the union of rights, but this behavior should be specifically defined in the text, not just in an example. Are union semantics always used for dnTypes at the same precedence? TECHNICAL: Deny takes precedence over Grant. When there are conflicting ACI values, deny takes precedence over grant. Deny is the default when there is no access control ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ information. ^^^^^^^^^^^ Does this mean that in the absence of any ACI at all, there is no access to anything? Does it imply that there MUST be an ldapACI at the root, since root can't inherit and without an explicit ldapACI there will be no access at all? Page 16: TECHNICAL: Precedence of Privilege Attribute dnTypes within a scope (highest to lowest): - ipAddress ^^^^^^^^^ - access-id, kerberosID (both same precedence) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - group - role - subtree Requirement S6 of the requirements draft states: S6. Access policy SHOULD NOT be expressed in terms of attributes which are easily forged (e.g. IP addresses). There may be valid reasons for enabling access based on attributes that are easily forged and the behavior/implications of doing that should be documented. Isn't use of ipAddress flaunting this? According to our reading of the definition of "access identity" in Section 3, a Kerberos ID would BE an access identity. Why make a distinction here? TECHNICAL: "deny" takes precedence over "grant", but groups have precedence over roles. What happens if a permission is granted to a subject by virtue of group membership but denied by virtue of role membership? What is the precedence among precedence groupings? Page 18: EDITORIAL: 6.5.2 Modifying the ldapACI Values Modify-Replace works as defined in the ldap oepration ^^^^^^^^^ modify. If the attribute value does not exist, create the value. If the attribute does exist, replace the value. If the ldapACI value is replaced, all ldapACI values are replaced. Spelling. Page 20: TECHNICAL: Examples are useful and should be encouraged, but they should not be the sole source of parts of the specification. Example #2 is the only place we have found that says that ACI is combined when two dnTypes have the same precendence. And the fact that the combination is by union is not stated anywhere, though it can be inferred from the example. Page 21: TECHNICAL: We are not sure we understand the purpose of Section 7. Is it just a set of high level examples of sequence of operations? TECHNICAL: - Datastore Access Control Policy Update Actions: any operation implemented by the server which LDAP is using as its datastore which changes the access policy enforced with respect to attempts to access LDAP directory entries and their attributes. Is this meant to say that the underlying DBMS/filesystem/etc may impose policy which overrides the policies expressed by LDAP ACIs? Or is it meant to say that non-LDAP means (SQL for an underlying RDBMS datastore) may change the data stored in ldapACI attributes? While either may be true in general, is it not part of the job of the server developer to make sure it doesn't happen? Shouldn't LDAP access control be the way that access control policy is expressed for an LDAP directory? Page 25: EDITORIAL: dnType speficies the type of subject security attribute. ^^^^^^^^^ Defined types are specified in the BNF. Spelling. Page 26 TECHNICAL: subjectDN LDAPString | "public" | "this" | "*" What does it mean to getEffectiveRights for "everyone who has access to the entry" (definition of "*" on Page 25)? Return all the ACIs? All possible subject DNs can't be known. And if all the ACIs are desired it would be simpler to just read the ldapACI attribute. Page 28: TECHNICAL: dnType "access-id"|"group"| "role"|"ipAddress"| "kerberosID"| | "*", ^^^ subjectDN LDAPString | "public" | "this" | "*" ^^^ What would it mean to return "*" as part of the RESPONSE to getEffectiveRights? Isn't a separate PartialEffectiveRightsList element needed for each dnType in the response? If "*" is part of the query, shouldn't the various elements of the response indicate which specific dnType they refer to rather than repeating the "*"? When would "*" be returned? And it is even less clear what "*" means for in the response for subjectDN. We note that the "*" is not allowed in the ldapGetEffectiveRightsResponse on Page 31. Was it left in PartialEffectiveRightsList by accident? Page 31: TECHNICAL: Should the security considerations section include some mention of the special problems that might arise in a replicated environment? What happens when new entries or attributes arrive at a replicated server out of sequence with the arrival of associated ldapACI data? From list@netscape.com Thu Mar 16 14:11:42 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05301 for ; Thu, 16 Mar 2000 14:11:40 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA04897; Thu, 16 Mar 2000 11:05:14 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA08347; Thu, 16 Mar 2000 11:09:41 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 11:09:41 -0800 (PST) Message-Id: <4.2.2.20000316124823.00a256a0@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Mar 2000 13:11:56 -0600 To: "Kurt D. Zeilenga" From: Ellen Stokes Subject: Re: ldapACI syntax and matching rules and more Cc: ietf-ldapext@netscape.com In-Reply-To: <3.0.5.32.20000315184429.0091e100@infidel.boolean.net> References: <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> <4.2.2.20000310133633.00a451c0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"Zr9QyB.A.2BC.0FT04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Responses embedded and prefaced by (EJS) Ellen At 06:44 PM 3/15/00 -0800, Kurt D. Zeilenga wrote: >Just did very quick read of the latest draft. A few comments >and questions. > >Please note that I (still) believe ldapACI should have a syntax >which requires values to conform to the BNF described by Section 6.1 >of the draft and that the equality matching rule be "syntax >aware". In particular, the equality matching rule should >treat any two ACI which have same meaning but different form >to be equal. That is: > >ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#group#cn="Dept, XYZ",c=US >ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#CN="dept, xyz",c=us >ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#cn=Dept\, XYZ,c=US >ldapACI:1.2.3.4#subtree#grant;c,s,r;attribute:xx#group#cn="Dept, XYZ",c=US >ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:1.1.1#group#cn="Dept, XYZ",c=US > >where x is defined as > ( 1.1.1 NAME ( 'x' $ 'xx' ) SUP 'name' ) >should all be considerred equal. CaseIgnoreString does cut it... (EJS) I agree the above examples should be case insensitive. I'll add the matching rule caseIgnoreString. >The BNFs appear underspecified. < printable string > allows >too many characters which hinder (or disallow) parsing. A >< subject DN > should be an RFC 2253 DN string. < oid > >should be a RFC 2252 numericoid. (EJS) If consensus is to retain familyOID, then, yes, it should be specified in the BNF as ; otherise it just goes away. I agree that in the BNF is underspecified. It needs to look something like: ::= | "public" | "this" | | where we reach agreement on how 'handle' kerberosID per your note and Bob's response, and also define the syntax for ipAddress (another one of your comments). I'll handle those two in a separate note. >A few questions: > >How does a ACL granting access to an attribute types superior affect >access the attribute type? Ie: does granting access to 'name' >allow access to 'cn'? (EJS) No, schema hierarchy will be independent of access control inheritance for now; we should look at this again in the future after we get this draft to RFC. >I see that ACLs on attribute subtypes (cn;lang-US) are disallowed. >Is this intentional? If so, why? If not, any syntax issues due >to the attribute description's ';'(s) (could have more than one). (EJS) It was not our intention to disallow (I didn't even think we stated explicitly we disallowed it). So, I'll add wording to make sure it's understand that it is allowed. I'll also change some of the separators in the BNF so there is not misunderstanding of parsing when ';' is used. Good catch. >Why is ipAddress restricted to the "dotted-decimal string >representation"? This restricts ipAddress to IPv4 addresses. >A reference to exact ipAddress form should be provided. >[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8 >or 10.0.0.0:255.0.0.0] (EJS) Another good catch. We need to support IPv6. I'll put out a BNF for ipAddress to cover this. I think we also need wildcarding, etc. I think perhaps a good starting point here might be the BNF by Netscape for support of ipAddress in access control. I''m open to other suggestions as well. >Kurt From list@netscape.com Thu Mar 16 17:24:56 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18153 for ; Thu, 16 Mar 2000 17:24:55 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA01868; Thu, 16 Mar 2000 14:21:13 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA00484; Thu, 16 Mar 2000 14:23:36 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 14:23:36 -0800 (PST) Message-Id: <3.0.5.32.20000316142325.009602c0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Mar 2000 14:23:25 -0800 To: Ellen Stokes From: "Kurt D. Zeilenga" Subject: ldapACI and attribute subtypes Cc: ietf-ldapext@netscape.com In-Reply-To: <4.2.2.20000316124823.00a256a0@popmail2.austin.ibm.com> References: <3.0.5.32.20000315184429.0091e100@infidel.boolean.net> <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> <4.2.2.20000310133633.00a451c0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"t2b9bB.A.4G.n7V04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 01:11 PM 3/16/00 -0600, Ellen Stokes wrote: >>How does a ACL granting access to an attribute types superior affect >>access the attribute type? Ie: does granting access to 'name' >>allow access to 'cn'? > >(EJS) No, schema hierarchy will be independent of access control >inheritance for now; we should look at this again in the future after >we get this draft to RFC. > >>I see that ACLs on attribute subtypes (cn;lang-US) are disallowed. >>Is this intentional? If so, why? If not, any syntax issues due >>to the attribute description's ';'(s) (could have more than one). > >(EJS) It was not our intention to disallow (I didn't even think we stated >explicitly we disallowed it). So, I'll add wording to make sure it's >understand that it is allowed. I'll also change some of the separators >in the BNF so there is not misunderstanding of parsing when ';' is used. >Good catch. Given these two statements I would assume that an ACL for a bare attribute type does NOT apply to subtypes of that attribute including those distinguished only by a combination of attribute description options. I believe that if you allow subtyping at all, you should allow both subtyping by 'sup' and by attribute description options. I personally think that ACI with subtype support are extermely powerful, easy to manage, and (depending on implementation) not expensive in terms of evaluation processing, and fairly easy to implement (depending upon server design). To not support subtyping would place a significant burden on directory manager to establish ACIs for all possible subtypes. Given the nature of some subtypes (like language tags subtypes and combined attribute description option subtypes), this can increase the number of ACIs needed. From list@netscape.com Thu Mar 16 18:30:22 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12104 for ; Thu, 16 Mar 2000 18:30:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA13278; Thu, 16 Mar 2000 15:26:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA02843; Thu, 16 Mar 2000 15:29:13 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 15:29:13 -0800 (PST) Message-Id: <4.2.2.20000316161309.00a21220@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 16 Mar 2000 17:30:52 -0600 To: rvh@qsun.mt.att.com (Richard V Huber), blakley@dascom.com, djbyrne@us.ibm.com From: Ellen Stokes Subject: Re: Comments on the ACL Model draft Cc: ietf-ldapext@netscape.com In-Reply-To: <200003161851.NAA21671@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"cnQpRD.A.Hs.I5W04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Ryan and Rick, My responses are embedded and prefaced by (EJS). Some of your comments have been delete in this email and will be addressed in a separate email. Ellen At 01:51 PM 3/16/00 -0500, Richard V Huber wrote: >This is a joint set of comments from Ryan Moats and Rick Huber. We've >been discussing them internally for a while, so they may repeat some of >the last day's discussion on the list, but there is a fair amount of new >material here. > >Rick Huber >--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- >Page 3 > >TECHNICAL: > > No mechanisms are defined in this document to control > access to access control information or for storage of > access control information at the server; this is vendor > dependent. > >But the ACIs are attributes. Don't the normal access controls >described in the rest of the draft apply here? (EJS) No. This was an agreement several ldapext meetings ago that this was out of scope. Please also see section 6.4 first paragraph that states: "Policy ownership controls administrative subdomains. It can also control who has permission to set / change acls for implementations that do not have ACI controlling access to itself. ... " >EDITORIAL: Add reference to ACL Requirements document in last paragraph. (EJS) Will do, may need to add at or during last call because although the ACL requirements doc has been approved for RFC publication, it hasn't been published yet so I don't have the RFC number. >Page 5: > >EDITORIAL: > > A "subject' is an entity which initiate actions in an > ^ ^^^^^^^^ > information system. > >The quotes on subject don't match. Also, "initiate" should be either >"may initiate" or "initiates". (EJS) Will do - I'll use the word 'initiates'. >Page 7: > >EDITORIAL: Add Section number at end of last paragraph. (EJS) Will do. >Page 9: > >EDITORIAL: > > aCIMechanisms lists the values (list of OIDs) that > defines the access control mechanism in effect for the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > scope of that subschema entry. More than one mechanism > may be in effect for the scope of that subschema entry. > >Should be "define the access control mechanisms" since it explicitly notes >that there can be more than one. (EJS) Will do. >EDITORIAL: > > The intent of the following attribute definitions is to > design a common interchange format. Any given LDAP > server should be able to translate the below defined > attributes into a meaningful operation requests. Each > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > server should be able to understand the attributes; there > should not be any ambiguity into what any part of the > syntax means. > >Should be "into meaningful operation requests" (drop the "a"). (EJS) Will do. >EDITORIAL: quote mismatch and add section number in second to last >paragraph. (EJS) Will do. >Page 10: > >EDITORIAL: > > Two attributes are defined so access control information > (ACI) can be addressed in a server independent of server > implementation. These attributes are used in typical > LDAP APIs and in LDIF output of ACI. These two attributes > may be queried or set on all directory objects: ldapACI > and policyOwner. Their BNF and definitions are defined > ^^^^^^^ > below. > >Should be "given" or "presented". (EJS) Will do. >Page 14: > >TECHNICAL: > > describes either an attribute name or an attribute > collection. The keyword attribute indicates that the > following printable string refers to an attribute name. > If the string refers to an attribute not defined in the > given server's schema, the server SHOULD report an error. > The keyword "collection" indicates that the string that > follows describes a group of attributes. The method for > ^^^^^^^^^^^^^^ > grouping attributes is server specific. Another option > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > for the collection printable string is "[entry]". This is ... > >This seems to say that no ACI containing an attribute collection can be >portable between vendors' LDAP products. Since attribute grouping may >well be common (if you have a number of attributes that are always >treated the same way for access control) this seems to be a major >interoperability problem. > >Wouldn't it be better to require that the wire protocol list all the >attributes and leave collections as a shortcut that some vendors' >products may use in their administrative interface? Note we do not >object to "[all]" and "[entry]" since they are well defined, we just >have a problem with the server specific collections. (EJS) See my previous email on this topic... >Page 15: > >TECHNICAL: > > means that this group (Dept XYZ) is granted permission to > read and search all attributes except attr1 because attr1 > is more specific than "[all]". > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >What if it were two collections rather than specific attribute vs. [all]? >How do you determine which is "more specific"? (EJS) Collection is more specific than All. Collections are server defined, so it is possible, but not probable, for an attribute to be a member of both collections. The specificity would be server defined. Also, keep in mind that I'm soliciting input on whether to keep or remove 'collection' - we'll do whatever is the consensus. >TECHNICAL: > > More specific policies must override less specific ones > (e.g. individual user entry in ACI takes precedence over > ^^^^ > group entry). > >The "e.g." makes us very nervous. There needs to be a solid definition >of what "more specific" means to avoid problems of interpretation by >different developers. (EJS) I'll tighten up the text for specificity and so explanation is not just implied by example. >Also, what would happen if a DN was a member of >two groups, where one had rights while the other did not? An example >on page 20 says to take the union of rights, but this behavior should >be specifically defined in the text, not just in an example. Are union >semantics always used for dnTypes at the same precedence? >(EJS) yes. > >TECHNICAL: > > Deny takes precedence over Grant. When there are > conflicting ACI values, deny takes precedence over grant. > Deny is the default when there is no access control > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > information. > ^^^^^^^^^^^ > >Does this mean that in the absence of any ACI at all, there is no >access to anything? (EJS) Yes, this was discussed on the list several weeks ago and was the consensus of the group. >Does it imply that there MUST be an ldapACI at the >root, since root can't inherit and without an explicit ldapACI there >will be no access at all? (EJS) There does not have to be a ldapACI at the root or even a default ldapACI. Root could inherit from a default, but that is implementation defined. And without an explicit ldapACI at the root, there is not access (which was consensus). >Page 16: > >TECHNICAL: > > Precedence of Privilege Attribute dnTypes within a scope > (highest to lowest): > > - ipAddress > ^^^^^^^^^ > > - access-id, kerberosID (both same precedence) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > - group > > - role > > - subtree > >Requirement S6 of the requirements draft states: > > S6. Access policy SHOULD NOT be expressed in terms of > attributes which are easily forged (e.g. IP addresses). > There may be valid reasons for enabling access based on > attributes that are easily forged and the > behavior/implications of doing that should be documented. > >Isn't use of ipAddress flaunting this? (EJS) Not really. The requirements document was put in place to serve as a guideline for writing the model draft, not as an explicit 'must follow' for writing the draft. So some things in the requirements are not in the draft and vice-versa. This was explained at previous ldapext meeting. Just because ipAddress is in the draft and an implementation provides it, doesn't mean that the deployment of the server needs to use it. >According to our reading of the definition of "access identity" in >Section 3, a Kerberos ID would BE an access identity. Why make a >distinction here? (EJS) Syntax. access-ID is a DN, kerberosID is typically something like userID@realm. Also, recall here, that there is pending email on generalizing kerberosID. >TECHNICAL: > >"deny" takes precedence over "grant", but groups have precedence over >roles. What happens if a permission is granted to a subject by virtue >of group membership but denied by virtue of role membership? (EJS) Let's answer when we settle on precedence of groups and roles. >What is the precedence among precedence groupings? (EJS) If I understand the question correctly, none; union semantics would apply and deny takes precedence over grant when both are listed. >Page 18: > >EDITORIAL: > > 6.5.2 Modifying the ldapACI Values > > Modify-Replace works as defined in the ldap oepration > ^^^^^^^^^ > modify. If the attribute value does not exist, create the > value. If the attribute does exist, replace the value. If > the ldapACI value is replaced, all ldapACI values are > replaced. > >Spelling. (EJS) Will do. >Page 20: > >TECHNICAL: > >Examples are useful and should be encouraged, but they should not be >the sole source of parts of the specification. Example #2 is the only >place we have found that says that ACI is combined when two dnTypes >have the same precendence. And the fact that the combination is by >union is not stated anywhere, though it can be inferred from the >example. (EJS) We'll explicitly state union and intersection semantics so as not to infer from examples. >Page 25: > >EDITORIAL: > > dnType speficies the type of subject security attribute. > ^^^^^^^^^ > Defined types are specified in the BNF. > >Spelling. (EJS) Will do. >Page 31: > >TECHNICAL: > >Should the security considerations section include some mention of the >special problems that might arise in a replicated environment? What >happens when new entries or attributes arrive at a replicated server >out of sequence with the arrival of associated ldapACI data? (EJS) I suggest that at a future time there be a draft that discusses the interaction of access control with other directory functions/features. In the case of replication, perhaps we should look at adding this to one of the (many) ldup drafts. I'll put this on my list to discuss since I author an ldup draft. From list@netscape.com Thu Mar 16 19:06:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26098 for ; Thu, 16 Mar 2000 19:06:36 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA18881; Thu, 16 Mar 2000 16:03:08 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA18121; Thu, 16 Mar 2000 16:05:33 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 16:05:33 -0800 (PST) Date: Thu, 16 Mar 2000 19:04:53 -0500 Message-Id: <200003170004.TAA29559@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: blakley@dascom.com, djbyrne@us.ibm.com, stokes@austin.ibm.com Subject: Re: Comments on the ACL Model draft Cc: ietf-ldapext@netscape.com Resent-Message-ID: <"SGaHTB.A.2aE.MbX04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I'll try to clarify a couple of places where our comments weren't clear enough. Rick Huber : >Page 15: : > : >TECHNICAL: : > : > means that this group (Dept XYZ) is granted permission to : > read and search all attributes except attr1 because attr1 : > is more specific than "[all]". : > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : > : >What if it were two collections rather than specific attribute vs. [all]? : >How do you determine which is "more specific"? : : (EJS) Collection is more specific than All. Collections are server defined, : so it is possible, but not probable, for an attribute to be a member of both : collections. The specificity would be server defined. Also, keep in mind : that I'm soliciting input on whether to keep or remove 'collection' - we'll do : whatever is the consensus. The question was meant to address the case where an attribute is a member of more than one collection and the different collections have different permissions. As for whether to keep or remove collections, my vote is to remove them and put in the "list of attributes" from one of the earlier email exchanges on this topic. But you will still have the issue of what to do when one attribute appears in two different lists and the different lists have different permissions. : >TECHNICAL: : > : >"deny" takes precedence over "grant", but groups have precedence over : >roles. What happens if a permission is granted to a subject by virtue : >of group membership but denied by virtue of role membership? : : (EJS) Let's answer when we settle on precedence of groups and roles. : : >What is the precedence among precedence groupings? : : (EJS) If I understand the question correctly, none; union semantics would : apply and deny takes precedence over grant when both are listed. I think we didn't make the question clear. There is a precedence of dnTypes, and there is a precedence of grant/deny. It is not clear how these precedences interact. We used group vs role only as an example. The question could be restated as: What happens if a permission is granted to a subject by virtue of the subject's access-ID but denied by virtue of subtree membership? Since access-ID has precedence over subtree membership, the permission should be granted, but since deny has precedence over grant it should be denied. Which precedence rule applies? I don't think union semantics apply to this question. : >Page 31: : > : >TECHNICAL: : > : >Should the security considerations section include some mention of the : >special problems that might arise in a replicated environment? What : >happens when new entries or attributes arrive at a replicated server : >out of sequence with the arrival of associated ldapACI data? : : (EJS) I suggest that at a future time there be a draft that discusses the : interaction of access control with other directory functions/features. In the : case of replication, perhaps we should look at adding this to one of the : (many) ldup drafts. I'll put this on my list to discuss since I author an : ldup draft. I don't think that we were suggesting that this issue must be resolved in the draft, just that it should be raised as a security concern that has to be considered. I agree that a full treatment of the issue is worth detailed examination in an LDUP document, but it is a security consideration related to the subject of this draft and should be noted as such in this draft. From list@netscape.com Thu Mar 16 21:16:23 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15002 for ; Thu, 16 Mar 2000 21:16:23 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA10775; Thu, 16 Mar 2000 18:10:37 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA26807; Thu, 16 Mar 2000 18:15:15 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 18:15:15 -0800 (PST) From: abstrainer@msn.com Date: Thu, 16 Mar 2000 21:11:13 -0500 (EST) Message-Id: <200003170211.e2H2BCn22258@virtual.stsi.net> To: makemoney@aol.com Subject: Life Is Too Valuable To Waste Resent-Message-ID: <"v8cFm.A.liG.yUZ04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Life Is Too Valuable To Waste... So, I¹ll get right to the point. Do you have a burning desire to succeed in every area of life? Would you like to live the life that most people will only day dream about? I am looking for sincere, honest and motivated people who posses a strong sense of integrity and vision and who want and need to make a minimum of 10k per month. If you think this is to good to be true or are skeptical then this may not be for you... Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from our efforts. The fact is we have many people in our enterprise that earn well over 50k per month from the privacy of their own home and who, having achieved both personal and financial freedom, are retiring in 2-3 years as extremely wealthy individuals. Ask yourself... Would you like to: … Drastically Reduce Personal, Business and Capital Gains Taxes ? … Create, Multiply and Protect Incredible Personal Wealth ? … Create a Six Figure Income Every 4 Months ? … Realize 3 to 6 Times Greater Returns on Your Money ? … Restore and Preserve Complete Personal and Financial Privacy ? … Legally Structure Yourself and Your Assets to be Completely Judgment-Proof, Seizure-Proof, Lien-Proof, Divorce-Proof, Attorney-Proof and Even IRS-Proof ? Yes, I realize that these are bold statements and No, these are not idle claims and promises. This Is For Real.. Only Your Sincere Time and Effort Is Required. Are you a BIG thinker, BIG dreamer and a person that believes that everyone deserves to have the best in life ? Do you want to be in a position to actually create powerful and positive change in your community ? Do you want to be free from the struggle of just barely making ends meet in order to pursue your creative potential ? Most importantly, are you capable of recognizing a truly once in a lifetime opportunity when it's sitting in your lap ? Countless others will have missed their shot at this opportunity and will look back years later and wish that they would have... because they could have ! If you are truly serious about taking complete control of your life... Call Toll Free (888) 692-9165 (24 hr recorded 2 minute message) This is NOT MLM ! - This is HIGH INTEGRITY ! Best Regards, Jeffrey From list@netscape.com Thu Mar 16 21:19:10 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16233 for ; Thu, 16 Mar 2000 21:19:09 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA05549; Thu, 16 Mar 2000 18:15:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA27904; Thu, 16 Mar 2000 18:18:01 -0800 (PST) Resent-Date: Thu, 16 Mar 2000 18:18:01 -0800 (PST) Message-Id: <3.0.5.32.20000316181746.00914c30@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 16 Mar 2000 18:17:46 -0800 To: Ellen Stokes From: "Kurt D. Zeilenga" Subject: Re: ldapACI: collection and attribute list Cc: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, djbyrne@us.ibm.com, blakley@dascom.com In-Reply-To: <4.2.2.20000316123923.00a11410@popmail2.austin.ibm.com> References: <3.0.5.32.20000315173053.00922100@infidel.boolean.net> <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"FVDPZC.A.uzG.ZXZ04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 12:44 PM 3/16/00 -0600, Ellen Stokes wrote: >(EJS) I'll add back the list of attributes (e.g. attribute: >*). However, >collection is still a valuable ease of administration concept. I understand >that a new collection name that might only be known locally could be a >concern, but implementation could code around it to say that if it's not >understood, then it's not supported. I'd like to retain this construct. Any >other opinions? The keyword "collection" indicates that the string that follows describes a group of attributes. The method for grouping attributes is server specific. So what if two servers hosting a cover naming context have two very differnet means for grouping attributes? Would not an ACI replicated between two such servers which used a collection understood by each, in its own way, cause the ACI to be evaluated differently on each server? This seems counter to "... one [an access control model] is needed to ensure consistent secure access across heterogeneous LDAP implementations." (p3) How about you define a collection to be the set of attributes allowed by an object class? An object class, after all, is defined (in part) as a collection of allowed attributes. [I've been thinking of experimenting with exactly this in OpenLDAP-devel... I'll try to find the time to implement it.] From list@netscape.com Fri Mar 17 09:19:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14550 for ; Fri, 17 Mar 2000 09:19:37 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA14972; Fri, 17 Mar 2000 06:14:10 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA27083; Fri, 17 Mar 2000 06:16:34 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 06:16:34 -0800 (PST) From: "Ryan Moats" To: "Ellen Stokes" , "Richard V Huber" , , Cc: Subject: RE: Comments on the ACL Model draft Date: Fri, 17 Mar 2000 08:15:20 -0600 Message-ID: <008901bf901b$3a6cf880$e3c8090a@schooner.local.windrose.omaha.ne.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 In-Reply-To: <4.2.2.20000316161309.00a21220@popmail2.austin.ibm.com> Importance: Normal Resent-Message-ID: <"vDhVzB.A.ZmG.A5j04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Ok, my $0.02, delineated with ... I've also cut whole swaths to save space... | >Page 16: | > | >TECHNICAL: | > | > Precedence of Privilege Attribute dnTypes within a scope | > (highest to lowest): | > | > - ipAddress | > ^^^^^^^^^ | > | > - access-id, kerberosID (both same precedence) | > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | > | > - group | > | > - role | > | > - subtree | > | >Requirement S6 of the requirements draft states: | > | > S6. Access policy SHOULD NOT be expressed in terms of | > attributes which are easily forged (e.g. IP addresses). | > There may be valid reasons for enabling access based on | > attributes that are easily forged and the | > behavior/implications of doing that should be documented. | > | >Isn't use of ipAddress flaunting this? | | (EJS) Not really. The requirements document was put in place to serve | as a guideline for writing the model draft, not as an explicit | 'must follow' for writing the draft. So some things in the requirements | are not in the draft and vice-versa. This was explained at previous | ldapext meeting. Just because ipAddress is in the draft and an | implementation provides it, doesn't mean that the deployment of the | server needs to use it. Hang on. I don't buy this (and I don't remember that particular LDAPEXT meeting, but I might have been someplace else). As I read SHOULD NOT, we need a good reason for using ipAddress. I don't see any documentation of why ipAddress is supported in this draft. At a bare minimum, we should document (a) why ipAddress is being proposed and (b) make a specific "Security Consideration" note about ipAddress being easily forgable. I'd really like for support of ipAddress to be a MAY (with everything else in the list a MUST), since this document is standards track. Ryan From list@netscape.com Fri Mar 17 09:59:30 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29455 for ; Fri, 17 Mar 2000 09:59:29 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA18323; Fri, 17 Mar 2000 06:56:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA05328; Fri, 17 Mar 2000 06:58:25 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 06:58:25 -0800 (PST) Message-Id: <4.2.2.20000317084652.00a2e240@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 17 Mar 2000 09:00:38 -0600 To: "Ryan Moats" , "Richard V Huber" , , From: Ellen Stokes Subject: RE: Comments on the ACL Model draft Cc: In-Reply-To: <008901bf901b$3a6cf880$e3c8090a@schooner.local.windrose.oma ha.ne.us> References: <4.2.2.20000316161309.00a21220@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"QivTp.A.-SB.Qgk04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > >| >Page 16: >| > >| >TECHNICAL: >| > >| > Precedence of Privilege Attribute dnTypes within a scope >| > (highest to lowest): >| > >| > - ipAddress >| > ^^^^^^^^^ >| > >| > - access-id, kerberosID (both same precedence) >| > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >| > >| > - group >| > >| > - role >| > >| > - subtree >| > >| >Requirement S6 of the requirements draft states: >| > >| > S6. Access policy SHOULD NOT be expressed in terms of >| > attributes which are easily forged (e.g. IP addresses). >| > There may be valid reasons for enabling access based on >| > attributes that are easily forged and the >| > behavior/implications of doing that should be documented. >| > >| >Isn't use of ipAddress flaunting this? >| >| (EJS) Not really. The requirements document was put in place to serve >| as a guideline for writing the model draft, not as an explicit >| 'must follow' for writing the draft. So some things in the requirements >| are not in the draft and vice-versa. This was explained at previous >| ldapext meeting. Just because ipAddress is in the draft and an >| implementation provides it, doesn't mean that the deployment of the >| server needs to use it. > >Hang on. I don't buy this (and I don't remember that particular LDAPEXT >meeting, but I might have been someplace else). As I read SHOULD NOT, we >need a good reason for using ipAddress. I don't see any documentation >of why ipAddress is supported in this draft. At a bare minimum, we should >document (a) why ipAddress is being proposed and (b) make a specific >"Security Consideration" note about ipAddress being easily forgable. >I'd really like for support of ipAddress to be a MAY (with everything else >in the list a MUST), since this document is standards track. > >Ryan (EJS) OK, let's step back for moment and start this discussion again. So far, I think we've all agreed that the supported dnTypes are access-id, group, and role. As for the addition of kerberosID, I haven't heard any violent objections - only that we should look at generalizing it and bringing it in line with the authmeth doc - and I'm looking into that. Now for other dnTypes such as ipAddress. I agree that we should include a note in the Security Considerations section about it being easily forged. ipAddress is useful when all directory updates are forced from a given machine or network domain. Given that this is an easily forged type, it's reasonable to ask the mailing list whether this type should be a MUST, SHOULD, or MAY, or perhaps remove it. So I'd like to hear opinions ipAddress so we can reach consensus. From list@netscape.com Fri Mar 17 10:21:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08077 for ; Fri, 17 Mar 2000 10:20:59 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA20959; Fri, 17 Mar 2000 07:17:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA11039; Fri, 17 Mar 2000 07:19:50 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 07:19:50 -0800 (PST) Message-ID: <438D12915E64D2118AB10000F8C1C078028FF6FB@zcard00e.ca.nortel.com> From: "James Benedict" To: ggood@netscape.com, ietf-ldapext@netscape.com Subject: RE: Changelog entries draft. Do not seem to find it. Date: Fri, 17 Mar 2000 10:17:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9023.F8835A5A" Resent-Message-ID: <"b7s2SC.A.NsC.W0k04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF9023.F8835A5A Content-Type: text/plain; charset="ISO-8859-1" Thanks Gordon. The next question is: Should it be a proposed standard? I haven't heard any more additions to my list of uses. Given the responses, I still think that there is value in a standard representation for change information. James A Benedict Advisor, IP Directory Systems Architecture Preside Policy Services NORTEL NETWORKS Ph: (613) 763-3909 > -----Original Message----- > From: ggood@netscape.com [mailto:ggood@netscape.com] > Sent: Monday, March 13, 2000 11:56 AM > To: ietf-ldapext@netscape.com; ietf-ldup@imc.org > Subject: Re: Changelog entries draft. Do not seem to find it. > > > I've refreshed the changelog draft. It's now available from > the IETF Internet Drafts > repository: > > http://www.ietf.org/internet-drafts/draft-good-ldap-changelog-01.txt > > -Gordon > > ------_=_NextPart_001_01BF9023.F8835A5A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Changelog entries draft. Do not seem to find it.

Thanks Gordon.

The next question is:  Should it be a proposed = standard?

I haven't heard any more additions to my list of = uses.  Given the
responses, I still think that there is value in a = standard representation
for change information.

James A Benedict
Advisor, IP Directory Systems Architecture
Preside Policy Services
NORTEL NETWORKS
Ph:  (613) 763-3909


> -----Original Message-----
> From: ggood@netscape.com [mailto:ggood@netscape.com]=
> Sent: Monday, March 13, 2000 11:56 AM
> To: ietf-ldapext@netscape.com; = ietf-ldup@imc.org
> Subject: Re: Changelog entries draft. Do not = seem to find it.
>
>
> I've refreshed the changelog draft. It's now = available from
> the IETF Internet Drafts
> repository:
>
> http://www.ietf.org/internet-drafts/draft-good-ldap-ch= angelog-01.txt
>
> -Gordon
>
>

------_=_NextPart_001_01BF9023.F8835A5A-- From list@netscape.com Fri Mar 17 10:30:44 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11688 for ; Fri, 17 Mar 2000 10:30:42 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA23159; Fri, 17 Mar 2000 07:24:58 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA13501; Fri, 17 Mar 2000 07:29:37 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 07:29:37 -0800 (PST) From: Search-Magic@mx.connectfree.co.uk Message-Id: <200003171513.WAA0000015608@oric.rajabhat.ac.th> To: Magic@yahoo.com Date: Fri, 17 Mar 00 07:59:03 EST Subject: Search Engine Secrets Discovered Resent-Message-ID: <"1PIZL.A.fSD.f9k04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com "Amazing Search Engine Secrets Discovered By A Computer Illiterate Man in Massachusetts Can Practically Hand You the Top Search Engine Positions...And Add 1,550 Hits a Day to Web Site Overnight!" Dear Friend, Remember the first time you built a web site. You stayed up until the early morning working it out so that it would be just perfect. Then, you were finally done and you sat back and thought, "The World is Good." After that, you've dreamed of all the visitors your site would have, how they would all see your ad and buy your product. Then it hit you, like a ton of bricks....How was anyone going to find your web site? You thought about it for a while and eventually thought you had the answer....submit your site to the search engines. But after you submitted your site you checked it out and couldn't find it. So you waited a few days.....and still nothing You couldn't even find your site if you looked up your own name!!! Then, you got discouraged....after all that hard work NOTHING?!?!? And this is where most people give up..... BUT You Don't Have To... You can achieve top 20 positioning for your web site...and the tens of thousands of hits which come with it...if you have the "Right" information available to you. For Example, did you know: * Infoseek, Alta Vista, and HotBot ban web sites which break their rules (many of the 'insider' techniques most experts recommend will get you banned faster than you could imagine). * Many search engines limit the number of pages you can submit from your domain (some only allow you to submit one page for best results), although we can show you a technique we use to get hundreds of our pages listed. * Yahoo only lists about 1% of the web in their actual directory. To even get your page listed, you may have to use the "backdoor". * Using a so-called search engine submission software that submits your site to 1,000 or more search engines could actually get your page deleted from the major search engines. * 95% of Internet traffic originates at one of the 10 major search engines...If you're not listed, you might as well not even have a web site! * Choosing the most effective 'keywords' is one of the major keys to a successful web site submission...Pick the right ones and your web site will look like Grand Central Station during rush hour! It has taken us over 2 years to learn how to consistently and without fail place any type of web site in the top 20 of the major search engines. Normally, we charge $500 per keyword that you want a top ranking on (plus a monthly fee of $150 for keeping that rank), but we have found we just don't have enough time for all of the clients that desperately need our services... So, we have produced a "Search Engine Magic" interactive CD-ROM that will show you step by step how to create pages which storm the search engines and lay hold to the precious Top 20 positions that millions of people are trying to reach. The Search Engine Magic CD-ROM consists of 21 interactive video and audio lessons that will run on any IBM compatible computer showing you the exact step-by-step process we use to traffic thousands of visitors to our web sites every single day. You will learn: * Three Different Methods We Use to Pick the Best Traffic Producing Keywords for any web site...and how you can have a list of hundreds of popular keywords in only a few minutes. * How Quick and Easy it is to Create 'Doorway' and 'Hallway' pages for the search engines so that you could possibly have thousands of different pages on your domain all pulling in visitors for your site 24 hours a day 7 days a week. * The Secret Weapon that gives you an "Unfair Advantage" over your competition...and virtually assures you will reach the top positions (don't let your competitors hear about this one first or you will be in trouble). * How to Submit Your Pages to the Search Engines and assure that every single one of them gets listed. (if you listen to one of those amateurs tell you how to list your site, you may just get banned for life). * How to Use Pay-Per-Click search engines to receive over 10,000 visitors for only $100 * The Infamous Yahoo backdoor...You can get listed and we will show you the quickest and easiest method for doing so! * And much, much more... Even Better, You'll Get the Same Results For A Fraction of What Everyone Else Had to Pay! Listen: A lot of people all over the world are gonna be furious with me for sharing these "Insider Secrets" with you...especially since you won't be paying even part of what they had to shell out for one top positioning page! That's just too bad. It's been a secret for too long. So, let me tell you what the deal is.... Contact us today using the below Risk-Free Response Form and you can have all of our secrets for only $139.00. This price wouldn't even buy you 10 minutes of our time at our regular submission fees, but you can own the top search engine positions for less than the cost of a few classified ads! You will be learning everything we know about top positioning! That, my friend, is the bargain of a lifetime for a serious Internet marketer like yourself. What’s more, the money is actually irrelevant, because... You Also Get a 90 Day No-Risk 100% Money-Back Guarantee! Here's how it works. Order your personal copy of this CD-ROM, and use it like you own it. If...For any reason or no reason at all, you aren't completely satisfied after 90 days (by which I had over 47 Top 20 positions for my own web site), just send the CD-ROM back in any condition, and I personally guarantee you to get a complete refund of your purchase price. No questions asked. No problems or forms to fill out. No problems at all. PLUS, You Will Also Receive What is Considered to be by most experts as the "Ultimate Bonus!" For the first 50 people who fill out the below response form and send it in, you will also receive UNLIMITED REPRINT AND REPRODUCTION RIGHTS to this CD-ROM for LIFE! I am not going to allow this CD-ROM to become like many of those over-advertised products you see out there, so only the first 50 will receive these rights. This means that you will be able to use this exact same sales letter, copy the CD-ROM yourself, and sell it For $139.00 a copy, one sell will have breaking even. Sell two copies and you will be in profit.This isn't even counting what the CD-ROM package will do for you! Since only 50 people are going to have these rights... you must take action today! Yours in Success, Michael Burgess To rush order this "Search Engine Magic CD-ROM" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM -------------------------------------------------------- Please send to: Your Name: _____________________________________________ Your Address: __________________________________________ Your City: _____________________________________________ State / Zip: ___________________________________________ Your Country: __________________________________________ Phone #: _______________________________________________ (For problems with your order only. No salesmen will call.) Email Address: ___________________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard, American Express and Discover. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $144 ($139 + 5.00 Shipping) Credit Card Number:________________________________ Expiration Date:___________________________ Signature:_________________________ Date:____________________ * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing or mailing my credit card number. (Note your card will be charged for $144.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $144.00! Note - If ordering outside continental US, please add $5 to S&H P.S. If you send in your order and you are not one of the first 50 to receive the Reprint and Reproduction Rights, I will notify you immediately and give you the opportunity to cancel your order. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. x _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From list@netscape.com Fri Mar 17 11:25:08 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05014 for ; Fri, 17 Mar 2000 11:25:06 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA28829; Fri, 17 Mar 2000 08:19:22 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA29794; Fri, 17 Mar 2000 08:24:01 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 08:24:01 -0800 (PST) From: djbyrne@us.ibm.com X-Lotus-FromDomain: IBMUS cc: blakley@dascom.com, ietf-ldapext@netscape.com, Ellen Stokes Message-ID: <852568A5.005A1179.00@d54mta08.raleigh.ibm.com> Date: Fri, 17 Mar 2000 10:15:47 -0600 Subject: RE: Comments on the ACL Model draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"4azFnD.A.UQH.fwl04"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My responses prefaced with < djb > Page 26 TECHNICAL: subjectDN LDAPString | "public" | "this" | "*" What does it mean to getEffectiveRights for "everyone who has access to the entry" (definition of "*" on Page 25)? Return all the ACIs? All possible subject DNs can't be known. And if all the ACIs are desired it would be simpler to just read the ldapACI attribute. < djb > * is intended to return the effective access for all DNs which are defined within the ACI. This is different from simply reading the ACI b/c it does the expansions and evaluations of grant / deny / group memberships etc and returns the granted rights after evaluation. Page 28: TECHNICAL: dnType "access-id"|"group"| "role"|"ipAddress"| "kerberosID"| | "*", ^^^ subjectDN LDAPString | "public" | "this" | "*" ^^^ What would it mean to return "*" as part of the RESPONSE to getEffectiveRights? Isn't a separate PartialEffectiveRightsList element needed for each dnType in the response? If "*" is part of the query, shouldn't the various elements of the response indicate which specific dnType they refer to rather than repeating the "*"? When would "*" be returned? And it is even less clear what "*" means for in the response for subjectDN. We note that the "*" is not allowed in the ldapGetEffectiveRightsResponse on Page 31. Was it left in PartialEffectiveRightsList by accident? < djb > Yes, it should be removed from the response Thanks, Debora Byrne Manager Secure Way Directory Config / User Interface INet: djbyrne@us.ibm.com Phone: (512)838-1930 ( T/L 678 ) Ellen Stokes on 03/17/2000 09:00:38 AM To: "Ryan Moats" , "Richard V Huber" , blakley@dascom.com, Debora Byrne/Austin/IBM@IBMUS cc: ietf-ldapext@netscape.com Subject: RE: Comments on the ACL Model draft > >| >Page 16: >| > >| >TECHNICAL: >| > >| > Precedence of Privilege Attribute dnTypes within a scope >| > (highest to lowest): >| > >| > - ipAddress >| > ^^^^^^^^^ >| > >| > - access-id, kerberosID (both same precedence) >| > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >| > >| > - group >| > >| > - role >| > >| > - subtree >| > >| >Requirement S6 of the requirements draft states: >| > >| > S6. Access policy SHOULD NOT be expressed in terms of >| > attributes which are easily forged (e.g. IP addresses). >| > There may be valid reasons for enabling access based on >| > attributes that are easily forged and the >| > behavior/implications of doing that should be documented. >| > >| >Isn't use of ipAddress flaunting this? >| >| (EJS) Not really. The requirements document was put in place to serve >| as a guideline for writing the model draft, not as an explicit >| 'must follow' for writing the draft. So some things in the requirements >| are not in the draft and vice-versa. This was explained at previous >| ldapext meeting. Just because ipAddress is in the draft and an >| implementation provides it, doesn't mean that the deployment of the >| server needs to use it. > >Hang on. I don't buy this (and I don't remember that particular LDAPEXT >meeting, but I might have been someplace else). As I read SHOULD NOT, we >need a good reason for using ipAddress. I don't see any documentation >of why ipAddress is supported in this draft. At a bare minimum, we should >document (a) why ipAddress is being proposed and (b) make a specific >"Security Consideration" note about ipAddress being easily forgable. >I'd really like for support of ipAddress to be a MAY (with everything else >in the list a MUST), since this document is standards track. > >Ryan (EJS) OK, let's step back for moment and start this discussion again. So far, I think we've all agreed that the supported dnTypes are access-id, group, and role. As for the addition of kerberosID, I haven't heard any violent objections - only that we should look at generalizing it and bringing it in line with the authmeth doc - and I'm looking into that. Now for other dnTypes such as ipAddress. I agree that we should include a note in the Security Considerations section about it being easily forged. ipAddress is useful when all directory updates are forced from a given machine or network domain. Given that this is an easily forged type, it's reasonable to ask the mailing list whether this type should be a MUST, SHOULD, or MAY, or perhaps remove it. So I'd like to hear opinions ipAddress so we can reach consensus. From list@netscape.com Fri Mar 17 11:34:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09519 for ; Fri, 17 Mar 2000 11:34:53 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA00224; Fri, 17 Mar 2000 08:29:05 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA03931; Fri, 17 Mar 2000 08:33:44 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 08:33:44 -0800 (PST) From: "Ryan Moats" To: "Ellen Stokes" , "Richard V Huber" , , Cc: Subject: RE: Comments on the ACL Model draft Date: Fri, 17 Mar 2000 10:32:14 -0600 Message-ID: <002201bf902e$5a3855c0$e3c8090a@schooner.local.windrose.omaha.ne.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: <4.2.2.20000317084652.00a2e240@popmail2.austin.ibm.com> X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Resent-Message-ID: <"Awt2TD.A.J9.n5l04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit | >| >Page 16: | >| > | >| >TECHNICAL: | >| > | >| > Precedence of Privilege Attribute dnTypes within a scope | >| > (highest to lowest): | >| > | >| > - ipAddress | >| > ^^^^^^^^^ | >| > | >| > - access-id, kerberosID (both same precedence) | >| > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | >| > | >| > - group | >| > | >| > - role | >| > | >| > - subtree | >| > | >| >Requirement S6 of the requirements draft states: | >| > | >| > S6. Access policy SHOULD NOT be expressed in terms of | >| > attributes which are easily forged (e.g. IP addresses). | >| > There may be valid reasons for enabling access based on | >| > attributes that are easily forged and the | >| > behavior/implications of doing that should be documented. | >| > | >| >Isn't use of ipAddress flaunting this? | >| | >| (EJS) Not really. The requirements document was put in place to serve | >| as a guideline for writing the model draft, not as an explicit | >| 'must follow' for writing the draft. So some things in the requirements | >| are not in the draft and vice-versa. This was explained at previous | >| ldapext meeting. Just because ipAddress is in the draft and an | >| implementation provides it, doesn't mean that the deployment of the | >| server needs to use it. | > | >Hang on. I don't buy this (and I don't remember that particular LDAPEXT | >meeting, but I might have been someplace else). As I read SHOULD NOT, we | >need a good reason for using ipAddress. I don't see any documentation | >of why ipAddress is supported in this draft. At a bare minimum, | >we should document (a) why ipAddress is being proposed and (b) make | >a specific "Security Consideration" note about ipAddress being easily | > forgable. I'd really like for support of ipAddress to be a MAY (with | everything else in the list a MUST), since this document is standards | >track. | > | >Ryan | | (EJS) OK, let's step back for moment and start this discussion again. | So far, I think we've all agreed that the supported dnTypes are access-id, | group, and role. As for the addition of kerberosID, I haven't heard any | violent objections - only that we should look at generalizing it and | bringing it in line with the authmeth doc - and I'm looking into that. | | Now for other dnTypes such as ipAddress. I agree that we should include | a note in the Security Considerations section about it being | easily forged. ipAddress is useful when all directory updates are forced | from a given machine or network domain. Given that this is an easily | forged type, it's reasonable to ask the mailing list whether this type | should be a MUST, SHOULD, or MAY, or perhaps remove it. So I'd like to | hear opinions ipAddress so we can reach consensus. Seems fair to me (and you already have my opinion :-). Ryan From list@netscape.com Fri Mar 17 13:35:12 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29168 for ; Fri, 17 Mar 2000 13:35:11 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA18323; Fri, 17 Mar 2000 10:31:40 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA22523; Fri, 17 Mar 2000 10:33:55 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 10:33:55 -0800 (PST) Date: Fri, 17 Mar 2000 13:33:15 -0500 Message-Id: <200003171833.NAA25417@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: djbyrne@us.ibm.com Subject: RE: Comments on the ACL Model draft Cc: blakley@dascom.com, ietf-ldapext@netscape.com, stokes@austin.ibm.com Resent-Message-ID: <"CENSdB.A.pfF.Sqn04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Thanks. Now I understand what the "*" for subjectDn means. It would be helpful to include your explanation in the document. It does seem that "*" might result in HUGE responses in some fairly common situations. For example, if the ACI contains a dnType "subtree" for a reasonably large part of the tree, wouldn't the response need to contain every DN in that subtree? Rick Huber : From: djbyrne@us.ibm.com : To: rvh@qsun.mt.att.com : cc: blakley@dascom.com, ietf-ldapext@netscape.com, : Ellen Stokes : Subject: RE: Comments on the ACL Model draft : : : : : My responses prefaced with < djb > : : Page 26 : : TECHNICAL: : : subjectDN LDAPString | "public" | : "this" | "*" : : What does it mean to getEffectiveRights for "everyone who has access to : the entry" (definition of "*" on Page 25)? Return all the ACIs? All : possible subject DNs can't be known. And if all the ACIs are desired : it would be simpler to just read the ldapACI attribute. : : < djb > * is intended to return the effective access for all DNs which are : defined within the ACI. This is different from simply reading the ACI b/c : it does the expansions and evaluations of grant / deny / group memberships : etc and returns the granted rights after evaluation. : : : Page 28: : : TECHNICAL: : : dnType "access-id"|"group"| : "role"|"ipAddress"| : "kerberosID"| : | : "*", : ^^^ : subjectDN LDAPString | "public" | : "this" | "*" : ^^^ : : What would it mean to return "*" as part of the RESPONSE to : getEffectiveRights? Isn't a separate PartialEffectiveRightsList : element needed for each dnType in the response? If "*" is part of the : query, shouldn't the various elements of the response indicate which : specific dnType they refer to rather than repeating the "*"? When : would "*" be returned? And it is even less clear what "*" means for : in the response for subjectDN. : : : We note that the "*" is not allowed in the : ldapGetEffectiveRightsResponse on Page 31. Was it left in : PartialEffectiveRightsList by accident? : : < djb > Yes, it should be removed from the response : : : Thanks, : : Debora Byrne : Manager Secure Way Directory Config / User Interface : INet: djbyrne@us.ibm.com : Phone: (512)838-1930 ( T/L 678 ) From list@netscape.com Fri Mar 17 19:30:14 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17541 for ; Fri, 17 Mar 2000 19:30:13 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA29642; Fri, 17 Mar 2000 16:24:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA00842; Fri, 17 Mar 2000 16:28:59 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 16:28:59 -0800 (PST) Date: Fri, 17 Mar 2000 18:29:24 -0600 From: Mark Wahl Subject: LDAPEXT revised agenda Sender: Mark.Wahl@INNOSOFT.COM To: ietf-ldapext@netscape.com Cc: agenda@ietf.org Cc: paf@swip.net Cc: moore@cs.utk.edu Cc: Ned.Freed@INNOSOFT.COM Reply-to: M.Wahl@INNOSOFT.COM Message-id: <5971.953339364@threadgill.austin.innosoft.com> Resent-Message-ID: <"qU75nD.A.4M.K3s04"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Be sure to read the drafts listed in sections 5-16! What: LDAPEXT Working Group When: Monday, March 27, 2000 1530-1730 1. Agenda review (Mark Wahl) 2. Summary of long-completed work items (Mark Wahl) 3. Last calls completed since November (Mark Wahl) draft-ietf-ldapext-ldapv3-vlv-03 draft-ietf-ldapext-ldap-java-api-10 draft-ietf-ldapext-ldap-java-api-asynch-ext-05 draft-ietf-ldapext-ldap-taxonomy-02 4. Charter progress review (Mark Wahl) 5. Server location with DNS (Paul Leach) draft-ietf-ldapext-locate-01 6. ACL Model (Ellen Stokes) draft-ietf-ldapext-acl-model-05 7. C API (Kurt Zeilenga, Mark Wahl) draft-ietf-ldapext-ldap-c-api-04 8. CLDAP (Roland Hedberg) 9. Subentries (Ed Reed) draft-ietf-ldup-subentry-01 10. LCUP (Olga Natkovich) draft-natkovich-ldap-lcup-00 11. Vendor information (Mark Meredith) draft-mmeredith-rootdse-vendor-info-02 12. DIF SP-DNA BOF info (Farzi Khazai) 13. Password management (Jim Sermersheim, Kurt Zeilenga) draft-behera-ldap-password-policy-01 draft-zeilenga-ldap-authpassword-02 draft-zeilenga-ldap-passwd-exop-01 14. Result codes (Mike Just) draft-just-ldapv3-rescodes-01 15. Schema management (Ellen Stokes) 16. Referrals and knowledge references draft-ietf-ldapext-namedref-00 draft-ietf-ldapext-knowledge-00 17. Any other business Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Fri Mar 17 19:31:35 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18160 for ; Fri, 17 Mar 2000 19:31:34 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA10566; Fri, 17 Mar 2000 16:27:59 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA01963; Fri, 17 Mar 2000 16:30:25 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 16:30:25 -0800 (PST) From: fdgfdo@grupomeyer.com.mx Date: Fri, 17 Mar 2000 15:56:09 Message-Id: <725.454950.642449@mail.mindspring.com> Resent-Message-ID: <"54oRiB.A.Le.g4s04"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Get Your own offshore trust today in the Turks and Caicos Islands! Minimize taxes by trading through your offshore company today! Have your private airplane owned by a trust! Learn what the billionares do! DIVORCE PROOF YOUR MONEY! YOU SPLIT, THAT OLD EX GETS NOTHING guaranteed! HIDE YOUR MONEY FROM CREDITORS LEGALLY! please fax us at 240 352 7546 today for details or leave a message on 888 248 0765! ________________________________________________________________ Get your own offshore bank account or offshore credit card today! Creditor proof your accounts! FULL ATM ACCESSABILITY! FAX 240 352 7546 TODAY FOR DETAILS or leave a message on 888 248 0765! ________________________________________________________________ USE BULK EMAIL TO ADVERTISE YOUR PRODUCT OR SERVICE TODAY! 28,000 email broadcast (opt in) $495.00 500,000 email broadcast $750.00. 1 million Email Broadcast $1200.00. For details call 1 888 248 0765 today!. For our international customers please fax us at 240 352 7546 today! ______________________________________________________________ Stop paying $19.95 per month or more for web space! You can get it from us for only $12.95 per month! This price inlcudes hosting your own domain! All fees are prepaid in advance with a 90 day money back guarantee! A $40.00 set up fee applies to new customers. For details call 1 888 248 0765 today!.. For our international customers please fax us at 240 352 7546 today! _______________________________________________________________ We offer complete web promotion packages in front of millions every month starting at $375.00 for the first month. This is not search engine placement and is only offered when you host your site with us! CALL 888 248 0765 for DETAILS! For our international customers please fax us at 240 352 7546 today! _______________________________________________________________ Need a web page designed? We offer a full line of web design capabilites! CAll 888 248 0765 FOR DETAILS!! For our international customers please fax us at 240 352 7546 today! _______________________________________________________________ Want to start bulk emailing on your own? Make your phone ring off the hook NOW! Get our popular program Direct Mail for only $395.00 to do the mailing you only dreamed about! Better yet for optimal responses you are going to want to email your ad in html format! Purchase our professional mailer program Emerge for only $1500.00 today! To get your own email addresses you will need an email address extractor! Use Nitro to get all the addresses you want for only $495.00! Get your free demo's at 888 248 0765 today! For further details call 888 248 0765 NOW! For our international customers please fax us at 240 352 7546 today! ______________________________________________________________ Get Your own offshore trust today in the Turks and Caicos Islands! Minimize taxes by trading through your offshore company today! Have your private airplane owned by a trust! Learn what the billionares do! DIVORCE PROOF YOUR MONEY! YOU SPLIT, THAT OLD EX GETS NOTHING guaranteed! HIDE YOUR MONEY FROM CREDITORS LEGALLY! please fax us at 240 352 7546 today for details! ______________________________________________________________ Have you been DOWNSIZED, RIGHTSIZED or just plain CAPSIZED? Would an opportunity that allows you to start your own business, be your own boss, work your own hours, take part in the growth of a dynamic health care product manufacturer be of interest to you? Let me show you how others like myself have brought balance into their lives. For free information please contact: Jim 877 205 9117 InterNet Marketing Specialies Toronto, Ontario From list@netscape.com Fri Mar 17 21:29:07 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01811 for ; Fri, 17 Mar 2000 21:29:05 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA23415; Fri, 17 Mar 2000 18:25:25 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA11453; Fri, 17 Mar 2000 18:27:51 -0800 (PST) Resent-Date: Fri, 17 Mar 2000 18:27:51 -0800 (PST) From: crick@pc-evolution.com Subject: FINANCIAL FREEDOM: $100,000+ in 16 weeks!!! Date: Fri, 17 Mar 2000 15:49:09 Message-Id: <273.643139.413894@cheetahtech-inc.com> Resent-Message-ID: <"MhQhD.A.myC.mmu04"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com If you were not the intended recipient of this message, please accept my apologies, disregard, and delete. FINANCIAL FREEDOM: $100,000+ in 16 weeks!!! Dear Friend, In the next 16 weeks you can earn $100,000 or more by sending e-mail. I know what you're thinking… "YEAH RIGHT! Another get rich quick scheme." That's what I thought when I first saw this. Now I thank God that I read it through and didn't delete it. I've made thousands of dollars already with more coming in every day! "AS SEEN ON NATIONAL TV" This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, it's been very exciting to be a part of it lately. You will understand once you experience it. HERE IT IS BELOW: *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $100,000 in less than 16 weeks! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multi-level e-mail order marketing program works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response: "That's why I'm sitting up here and you are all sitting out there!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, my only expense is my time. I am telling you like it is I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it made me. In less than one week, I was starting to receive orders for INSTRUCTIONAL #1 By January 13, I had received 26 orders for INSTRUCTIONAL #1. Your goal is to "RECEIVE at least 20 ORDERS FOR INSTRUCTIONAL #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $100,000 in 16 weeks was done. By January 30, I had received 196 orders for INSTRUCTIONAL #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR INSTRUCTIONAL #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $100,000 GOAL." Well, I had 196 orders for INSTRUCTIONAL #2, 96 more than I needed. So I sat back and relaxed. By April 1, of my e-mailing of 10,000, I received $106,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember, it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work and you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for INSTRUCTIONAL #1, and 100+ orders for INSTRUCTIONAL #2 and you will make $100,000 or more in 16 weeks. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and INSTRUCTIONALS, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined.I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS!I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting program to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use $100,000 or more in the next 16 weeks. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 5 INSTRUCTIONAL's shown on the list below (you can't sell them if you don't order them). * For each INSTRUCTIONAL, send $5.00 CASH (US CURRENCY), the NAME & NUMBER OF THE INSTRUCTIONAL YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the INSTRUCTIONAL. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the five INSTRUCTIONALS. You will need all five INSTRUCTIONALS so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the five INSTRUCTIONALS. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT DO NOT alter the names of the people who are listed next to each INSTRUCTIONAL, or their sequence on the list, in any way other than is instructed below in steps "a" through "g" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available INSTRUCTIONALS. b. After you've ordered the five INSTRUCTIONALS, take this advertisement and remove the name and address under INSTRUCTIONAL #5. This person has made it through the cycle and is no doubt counting their $100,000! c. Move the name and address under INSTRUCTIONAL #4 down to INSTRUCTIONAL #5. d. Move the name and address under INSTRUCTIONAL #3 down to INSTRUCTIONAL #4. e. Move the name and address under INSTRUCTIONAL #2 down to INSTRUCTIONAL #3. f. Move the name under INSTRUCTIONAL #1 down to INSTRUCTIONAL #2. g. Insert your name/address in the INSTRUCTIONAL #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $25). You obviously already have an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for INSTRUCTIONAL #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order INSTRUCTIONAL #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for INSTRUCTIONAL #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for INSTRUCTIONAL #4. Those 10,000 mail out 2,000 programs each for a total of 20,000,000. The 0.5% response rate to that is 100,000 orders for INSTRUCTIONAL #5. That's 100,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 + $500,000 for a total of $555,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! INSTRUCTIONAL #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level-your 10 members with $5..............................$50 2nd level-- 10 members from those 10 ($5 x 100)...............$500 3rd level-- 10 members from those 100 ($5 x 1,000).........$5,000 4th level-- 10 members from those 1,000 ($5 x 10,000).....$50,000 5th level-- 10 members from those 10,000 ($5 x 100,000) $500,000 THIS TOTALS ----------$555,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e- mail them the INSTRUCTIONAL they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the INSTRUCTIONAL! *** Order Each INSTRUCTIONAL by NUMBER and NAME *** Notes: * ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH INSTRUCTIONAL. CHECKS NOT ACCEPTED. * ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. * Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the INSTRUCTIONAL you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE INSTRUCTIONALS NOW: INSTRUCTIONAL #1 "NO COST ADVERTISING" ORDER INSTRUCTIONAL #1 FROM: I Perry 4319 N. 28th Way Phoenix, AZ 85016 INSTRUCTIONAL #2 "MILLIONS OF POTENTIAL CUSTOMERS" ORDER INSTRUCTIONAL #2 FROM: Kelly Pottschmidt 1068 Greenhills Drive Ann Arbor, MI 48105 INSTRUCTIONAL #3 "MLM: Secrets, Facts, and Lies" ORDER INSTRUCTIONAL #3 FROM: E-BIZ #604-530 Proudfoot Lane London,Ontario N6H 1W3 Canada INSTRUCTIONAL #4 "How to Achieve Unlimited Wealth" ORDER INSTRUCTIONAL #4 FROM: Matt Ballard 3560 Pine Grove #230 Port Huron, MI 48060 INSTRUCTIONAL #5 "Money Makes Money: How to Increase the Wealth You've Achieved" ORDER INSTRUCTIONAL #5 FROM: Adrian Clarke 2-1200 London Rd., Suite# 273 Sarnia, ON N7S 1P4 Canada About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the five INSTRUCTIONALS IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/INSTRUCTIONAL. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for INSTRUCTIONAL #1 within two weeks, Continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for INSTRUCTIONAL #2. If you don 't, continue advertising or sending e- mails until you do. Once you have received 100 or more orders for INSTRUCTIONAL #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT INSTRUCTIONAL. You can KEEP TRACK of your PROGRESS by watching which INSTRUCTIONAL people are ordering from you. If you want to generate more income, send another batch of e- mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product which does not Cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense-other than your initial $25 investment-is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW! Take your first step toward achieving financial independence. Order the INSTRUCTIONALS and follow the program outlined above--- SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the INSTRUCTIONAL constitutes no guarantees stated nor implied. In the event that it is determined that this site or INSTRUCTIONAL constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the INSTRUCTIONAL are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. From list@netscape.com Sat Mar 18 17:50:26 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11781 for ; Sat, 18 Mar 2000 17:50:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA28972; Sat, 18 Mar 2000 14:44:37 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA08082; Sat, 18 Mar 2000 14:49:17 -0800 (PST) Resent-Date: Sat, 18 Mar 2000 14:49:17 -0800 (PST) From: ems307@mailcity.com Message-Id: <200003182249.OAA00475@ywing.netscape.com> Subject: Targeted Lists at the LOWEST Prices! Date: Sat, 18 Mar 2000 13:11:53 Resent-Message-ID: <"KnWqyD.A.A-B.ofA14"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com The key to success in marketing online is reaching the people who are really interested in your ad! You need targeted e-mails of business opportunity seekers who are ACTIVELY marketing online and trying to expand their business TODAY! These are going to be the lowest prices for deliverable, fresh, opportunity seekers you are going to find anywhere! http://www.geocities.com/express656/ 10,000 opportunity seekers e-mails for only $15 **New List 3-18-00** 25,000 opportunity seekers e-mails for only $20 50,000 opportunity seekers e-mails for only $35 75,000 opportunity seekers e-mails for only $50 120,000 opportunity seekers e-mails for only $60 - Promotions! **FREE with each order, demo of ListMan e-mail manager software to manage your e-mails list. Easily splits large lists into smaller files. **Order 50,000 or more e-mails and receive Express Mail Server to send your e-mails FREE! -Send your e-mails safely bypassing your ISP's mail server! -This is not a demo but a permanent license for the software! *You can order by MC/Visa/AMEX, Online Check , or Mail Payment!* _______________________________________________________________ I received your e-mail as someone interested in Internet Business Opportunities. If I received your e-mail in error, or you are no longer interested, please reply with "remove" in the subject. _________________________________________________________________ From list@netscape.com Sun Mar 19 17:21:23 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13196 for ; Sun, 19 Mar 2000 17:21:23 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA14147; Sun, 19 Mar 2000 14:15:28 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA24107; Sun, 19 Mar 2000 14:20:02 -0800 (PST) Resent-Date: Sun, 19 Mar 2000 14:20:02 -0800 (PST) From: mlmhistory@ethos.st Date: Sun, 19 Mar 2000 15:20:36 -0700 (MST) Message-Id: <200003192220.PAA17663@missouri.mcn.net> Reply-To: mlmhistory@ethos.st To: mlmhistory@ethos.st Subject: MLM History! Zig Ziglzar Goes MLM! Resent-Message-ID: <"KFd-UC.A.Z4F.RKV14"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Check out the COVER of the latest (May 2000) issue of: Network Marketing Lifestyles magazine! | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | THE SINGLE BIGGEST EVENT IN MLM HISTORY! | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MLM Veterans - DO NOT MISS THIS! Zig Ziglar is going MLM. Zig Ziglar has launched his own new network Company the first week of Febuary. We are recruiting for leaders who instantly recognize the global potential of Zig Ziglar going MLM. This is going to be the biggest thing in Network Marketing History. THOUSANDS are Joining Right Now.... HURRY! For information and consideration Send an Email to: mailto:autoreply@newmail.net?subject=ZZN Note: Please make sure the letters - ZZN - are in the Subject Field. Click here and send: mailto:autoreply@newmail.net?subject=ZZN --------------------------------------------------------------------------------------------------------------------------------- Please note: PS - THIS IS NOT A SPAM. You have received this email because you have either sent us your offer or requested information from us in the past thereby adding yourself on our in-house mailing list. We do not sell our lists to anyone. Removal Instructions: Reply to this Email and type "Remove" in the Subject Field. mailto:mlmhistory@ethos.st?subject=Remove --------------------------------------------------------------------------------------------------------------------------------- From list@netscape.com Sun Mar 19 19:24:38 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27108 for ; Sun, 19 Mar 2000 19:24:37 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA26106; Sun, 19 Mar 2000 16:21:05 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA09486; Sun, 19 Mar 2000 16:23:34 -0800 (PST) Resent-Date: Sun, 19 Mar 2000 16:23:34 -0800 (PST) From: ebusiness@kki.net.pl Message-ID: Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 19 Mar 2000 19:13:17 -0800 Subject: Incredible e-Business Opportunity! To: 2000ad@aol.com Resent-Message-ID: <"X586gD.A.zTC.E-W14"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Dear Friend, How would you like to quit your job, become your own boss, and build up enough residual income to support yourself for the rest of your life? ...Forget the old-days of Network Marketing where you had to "show the plan" and meet at the local high school for a "ra-ra" meeting. Our company offers you an opportunity that can be operated from in front of your computer screen. Imagine the feeling of being able to offer our opportunity and products to millions of people in over 42 Countries and Territories around the World. ...Not only do you have the ability to own a profitable home-based business which is operating in the United States but you also have the potential of having distributors all over the World. Make a well informed decision which will impact your future today ! Simply click below to visit our Award-winning website: http://12.21.33.27/biz2001ad/ You will be glad you did! With My Warmest Regards, Rudy http://12.21.33.27/biz2001ad/ From list@netscape.com Sun Mar 19 23:48:31 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05131 for ; Sun, 19 Mar 2000 23:48:30 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id UAA06128; Sun, 19 Mar 2000 20:40:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id UAA07862; Sun, 19 Mar 2000 20:42:31 -0800 (PST) Resent-Date: Sun, 19 Mar 2000 20:42:31 -0800 (PST) From: totalsuccess@wolf-web.com Date: Sun, 19 Mar 2000 20:41:21 -0800 (PST) Message-Id: <200003200441.UAA09452@xwing.netscape.com> To: Friend@netscape.com Subject: A Special FREE Membership Offer -FWYS X-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"zBShd.A.G6B.1wa14"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Hi, This is an Special FREE membership offer to the unique Post-Launch Program of a leading Internet Company With our Post-Launch program you can: * Access to great savings on shopping, travel, long distance charges,etc,etc * Business opportunity building towards high residual income($2000-$3000 per month) * Extensive free training sites and internet resources * 2000+ VIP members working to build your downline each month. * Membership support, working towards your business success How would you like to know that you have an existing downline and team in place to continue to help you develop a network BEFORE you even sign up or invest a penny ? You have nothing to lose and potentially a lot to gain !!! To receive your Special FREE membership to the Post-Launch just reply to this E-mail with "Post-Launch" in the Subject: Put your First and Last Names in the Message We will confirm your position and send you a special report as soon as possible. mailto:totalsuccess@wolf-web.com You have nothing to lose and potentially a lot to gain !!! What the members are saying: 22/11/99 Richard: New Member Hi. Thank you for your welcome and advice. Hmmm I count myself as a veteran internet marketer having been in the business for 9 mths now. I think the club is one of the best programs I have seen and I have a knack for choosing programs that work. Thanks once again. 29/10/99 Paula: Director The Club is Internet Business at it's best, in short, IT WORKS FOR YOU and IT'S FREE! It is moving faster than I ever imagined. I was amazed to see how quickly my downline grew. There really isn't a better time than right now to belong to the Club. 21/10/99 Chris:Team Leader Members care about each other and offer support to each other---when YOU succeed, WE all succeed and we really mean that! From list@netscape.com Mon Mar 20 04:29:55 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00102 for ; Mon, 20 Mar 2000 04:29:50 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id BAA09550; Mon, 20 Mar 2000 01:23:44 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id BAA01824; Mon, 20 Mar 2000 01:28:26 -0800 (PST) Resent-Date: Mon, 20 Mar 2000 01:28:26 -0800 (PST) From: 5iogh894@dcetsun.syd.dcet.csiro.au Date: Mon, 20 Mar 2000 00:36:40 Message-Id: <731.719099.271469@mail.mindspring.com> Resent-Message-ID: <"PkrRdC.A.Nb.38e14"@glacier> To: ietf-ldapext@netscape.com Resent-From: ietf-ldapext@netscape.com Subject: Unidentified subject! X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more PER MONTH OR MORE TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL OUR OFFICE. YOU CAN CHANGE YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 or fax 240 352 7546 PES WEB HOSTING -- Toronto, Ontario _______________________________________________________________ Want to do bulk email? Ask us how today! For an investment of $395.00 for our Direct Mail mailing program and our highly prized email extractor program Nitro for $495.00, you can be in business today! If your looking to mail HTML code which will double your sales, why not try our Emerge program for only $1495.00? Call 1888 248 0765 for a free demo today! or fax 240 352 7546 _________________________________________________________________ Get your own offshore trust! LEGALLY MINIMIZE YOUR TAXES! PROTECT YOUR PERSONAL ASSETS FROM LAWSUITS! GET THAT OFFSHORE BANK ACCOUNT YOU ALWAYS WANTED! THE PEOPLE IN OUR JURISTICTION GO TO JAIL IF THEY GIVE OUT ANY INFORMATION ABOUT YOU PERSONALLY WITHOUT YOUR PERMISSION! OUR FAX NUMBER WITHIN THE UK IS 0870 163 7598 OR WITHIN THE US 240 352 7546 THANK YOU to be removed email pro@natas.kfa.cx From list@netscape.com Mon Mar 20 13:43:52 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07500 for ; Mon, 20 Mar 2000 13:43:51 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA16432; Mon, 20 Mar 2000 10:40:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA23677; Mon, 20 Mar 2000 10:42:38 -0800 (PST) Resent-Date: Mon, 20 Mar 2000 10:42:38 -0800 (PST) From: lilbuddy@earthlink.net Message-ID: <00003fe979bd$0000663d$00006920@> To: Subject: Self-Reliance... Date: Fri, 17 Mar 2000 00:55:01 -0500 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: lilbuddy@earthlink.net Resent-Message-ID: <"TigMfC.A.cxF.cEn14"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com If you have bad credit and you want to fix it, then this is for you! 100% Legal 100% Effective 100% Guaranteed http://www.sites4free.net/~creditfix/3213.htm From list@netscape.com Mon Mar 20 13:46:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08756 for ; Mon, 20 Mar 2000 13:46:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA17726; Mon, 20 Mar 2000 10:43:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA27502; Mon, 20 Mar 2000 10:45:24 -0800 (PST) Resent-Date: Mon, 20 Mar 2000 10:45:24 -0800 (PST) From: Kyungae_Lim@iris.com Subject: re:draft-ietf-ldapext-acl-model-05 To: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Build V502_10191999 October 19, 1999 Message-ID: Date: Mon, 20 Mar 2000 13:48:05 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 03/20/2000 01:46:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"UKsNHB.A.0sG.CHn14"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I have a few questions after the first reading: On page 11: "..... If the server does not support partial inheritance and both the entry and subtree scope are used, then entry is the prevailing scope". What does this mean, especially "partial inheritance"? On page 14, about browseDN .."To do the search, browse (b) must be set for the entry (you can search only entries that you have permission to search so you can't discover things you don't have permission to)..." If the user does not have browseDN on the base "o=XYZ", but has the permission on "ou=dept ABC,ou=hr,o=XYZ", should ldap_search with the base "o=XYZ" 1) fail - user can't browse on "o=XYZ", nor "ou=hr,o=XYZ", therefore can't discover "ou=dept ABC,ou=hr,o=XYZ" or 2) succeed and return information about "ou=dept ABC,..."? Which one would be the intended behavior of this permission? On page 15-16, collection and attribute I, too, would like to see the multi-attribute syntax restored from the version 4. On page 22, there is an example of ldamodify - delete syntax. "Given an ACI of: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ dn: cn = some Entry changetype: modify delete: ldapACI ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ would yield a remaining ACI on the server of ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ" Given the same ACI, what would the result if the input to modify-delete is: ldapACI:1.2.3.4#subtree#grant;r;collection:[all]#group#cn=Dept XYZ Will the operation fail( no exact match), or will it return ldapACI: 1.2.3.4#subtree#grant;w;collection:[all]#group#cn=Dept XYZ (w instead of r,w) ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr1#group#cn=Dept XYZ What would be result if the input is: ldapACI:1.2.3.4#subtree#grant;w;attribute:attr1#group#cn=DeptXYZ? On page 29, the "public" DN is for setting access to all users. Have you considered to support another DN to represent "authenticated" users, to differentiate "authenticated" from "unauthenticated"? From list@netscape.com Mon Mar 20 20:15:59 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05837 for ; Mon, 20 Mar 2000 20:15:58 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA21745; Mon, 20 Mar 2000 17:11:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA01853; Mon, 20 Mar 2000 17:13:47 -0800 (PST) Resent-Date: Mon, 20 Mar 2000 17:13:47 -0800 (PST) Message-Id: <3.0.5.32.20000320171330.009402a0@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 20 Mar 2000 17:13:30 -0800 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: TLS graceful closure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"xu0ExD.A.IZ.Czs14"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > Either the client or server MAY terminate the TLS connection on an LDAP > association by sending a TLS closure alert. This will leave the LDAP > association intact. >Before closing a TLS connection, the client MUST either wait for any >outstanding LDAP operations to complete, or explicitly abandon them >[LDAPv3]. Does the server have any requirements before it can initiate such a closure? >After the initiator of a close has sent a closure alert, it MUST discard >any TLS messages until it has received an alert from the other party. >It will cease to send TLS Record Protocol PDUs, and following the >reciept of the alert, MAY send and receive LDAP PDUs. Including all client requests (such as unbind) and server notice of disconnect? >The other party, if it receives a closure alert, MUST immediately >transmit a TLS closure alert. It will subequently cease to send TLS >Record Protocol PDUs, and MAY send and receive LDAP PDUs. Any server requirements upon receipt of a closure altert? Such as abandoning all outstanding requests? From list@netscape.com Tue Mar 21 08:31:24 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09682 for ; Tue, 21 Mar 2000 08:31:18 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id FAA16121; Tue, 21 Mar 2000 05:25:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA11369; Tue, 21 Mar 2000 05:29:38 -0800 (PST) Resent-Date: Tue, 21 Mar 2000 05:29:38 -0800 (PST) Message-Id: <4.2.2.20000316165055.00a2aa20@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Mar 2000 07:31:44 -0600 To: rvh@qsun.mt.att.com (Richard V Huber), blakley@dascom.com, djbyrne@us.ibm.com From: Ellen Stokes Subject: ldapACI permissions Cc: ietf-ldapext@netscape.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"e4HpZD.A.AxC.Al314"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Rick/Ryan, Page 12: TECHNICAL: e EditDN Edit an entry's DN b BrowseDN Browse an entry's DN How is EditDN permission different from Write permission on the naming attribute? How is BrowseDN permission different from Search permission on the naming attribute? Can I have EditDN permission on the entry without explicit Write permission on the naming attribute of the entry? What would it mean? (EJS) EditDN and BrowseDN work at the entry level (DN) and equate to permissions to modify/access the DN for ldapmodifyDN/ldapmodifyRDN/ldapSearch operations. Write works at the attribute level on attributes. And do we really need both Search and Compare permissions? (EJS) Yes, search and compare and 2 different operations. >TECHNICAL: What's the interaction between "[entry]" and attributes: if >somebody has add permission for objects but is denied permissions for >certain attributes, what happens? (EJS) None. [entry] applies to the permissions a/d/e/b. [all] applies to the permissions for attributes. If a person has add permission, then he can add an entry and its attributes to that place in the DIT. The permissions for the attributes he added as part of adding that entry are governed by the access control attribute (ldapACI) that is added to that entry. Ellen From list@netscape.com Tue Mar 21 08:41:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12897 for ; Tue, 21 Mar 2000 08:41:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id FAA16931; Tue, 21 Mar 2000 05:35:42 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA14259; Tue, 21 Mar 2000 05:40:24 -0800 (PST) Resent-Date: Tue, 21 Mar 2000 05:40:24 -0800 (PST) Message-Id: <4.2.2.20000321073321.00a2c340@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 21 Mar 2000 07:42:16 -0600 To: "Kurt D. Zeilenga" From: Ellen Stokes Subject: Re: ldapACI: collection and attribute list Cc: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, djbyrne@us.ibm.com, blakley@dascom.com In-Reply-To: <3.0.5.32.20000316181746.00914c30@infidel.boolean.net> References: <4.2.2.20000316123923.00a11410@popmail2.austin.ibm.com> <3.0.5.32.20000315173053.00922100@infidel.boolean.net> <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"jOZTvB.A.eeD.Hv314"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 06:17 PM 3/16/00 -0800, Kurt D. Zeilenga wrote: >At 12:44 PM 3/16/00 -0600, Ellen Stokes wrote: > >(EJS) I'll add back the list of attributes (e.g. attribute: > >*). However, > >collection is still a valuable ease of administration concept. I understand > >that a new collection name that might only be known locally could be a > >concern, but implementation could code around it to say that if it's not > >understood, then it's not supported. I'd like to retain this > construct. Any > >other opinions? > > The keyword "collection" indicates that the string that > follows describes a group of attributes. The method for > grouping attributes is server specific. > >So what if two servers hosting a cover naming context have two >very differnet means for grouping attributes? Would not an >ACI replicated between two such servers which used a collection >understood by each, in its own way, cause the ACI to be evaluated >differently on each server? > >This seems counter to "... one [an access control model] is needed >to ensure consistent secure access across heterogeneous LDAP >implementations." (p3) > >How about you define a collection to be the set of attributes >allowed by an object class? An object class, after all, is >defined (in part) as a collection of allowed attributes. > >[I've been thinking of experimenting with exactly this in >OpenLDAP-devel... I'll try to find the time to implement it.] (EJS) Kurt, One possible solution to this (and I certainly haven't thought this all the way through, but building on your thoughts) might be to define a 'collection' class whose attribute is, for example, called 'list' which contains a list of the attributes in that collection. One could then subclass to define new collections, but this class would never be instantiated in the directory - I would view it as a 'meta' class or schema definition. Is this what you had in mind? Ellen From list@netscape.com Tue Mar 21 09:51:49 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09626 for ; Tue, 21 Mar 2000 09:51:44 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA19760; Tue, 21 Mar 2000 06:47:59 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA27892; Tue, 21 Mar 2000 06:50:28 -0800 (PST) Resent-Date: Tue, 21 Mar 2000 06:50:28 -0800 (PST) Message-Id: <3.0.5.32.20000321065007.00952d10@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 21 Mar 2000 06:50:07 -0800 To: Ellen Stokes From: "Kurt D. Zeilenga" Subject: Re: ldapACI: collection and attribute list Cc: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com, djbyrne@us.ibm.com, blakley@dascom.com In-Reply-To: <4.2.2.20000321073321.00a2c340@popmail2.austin.ibm.com> References: <3.0.5.32.20000316181746.00914c30@infidel.boolean.net> <4.2.2.20000316123923.00a11410@popmail2.austin.ibm.com> <3.0.5.32.20000315173053.00922100@infidel.boolean.net> <4.2.2.20000315092530.00a2a9f0@popmail2.austin.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"E2wNNB.A.izG.zw414"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 07:42 AM 3/21/00 -0600, Ellen Stokes wrote: >(EJS) Kurt, One possible solution to this (and I certainly haven't >thought this all the way through, but building on your thoughts) might >be to define a 'collection' class whose attribute is, for example, called >'list' which contains a list of the attributes in that collection. One could >then subclass to define new collections, but this class would never be >instantiated in the directory - I would view it as a 'meta' class or schema >definition. Is this what you had in mind? I had in mind using instantiatable (and other) object classes. I draw this suggestion from my longstanding desire to be able to limit returned results by object class. Lately, I've been thinking of extending search attribute lists to accept things like: person;objectclass mailRecipient;objectclass The presense of one of these attributes descriptions would cause all attributes of the named object classes to be 'requested'. The same mechanism could be applied to ACIs... the ACI would apply to all attributes of the named object class. As far as the 'collection' class idea, I would argue that we already have such... 'auxiliary'. From list@netscape.com Tue Mar 21 10:05:01 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14100 for ; Tue, 21 Mar 2000 10:05:00 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA21416; Tue, 21 Mar 2000 07:01:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA02767; Tue, 21 Mar 2000 07:03:41 -0800 (PST) Resent-Date: Tue, 21 Mar 2000 07:03:41 -0800 (PST) Date: Tue, 21 Mar 2000 10:02:43 -0500 Message-Id: <200003211502.KAA19578@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: blakley@dascom.com, djbyrne@us.ibm.com, stokes@austin.ibm.com Subject: Re: ldapACI permissions Cc: ietf-ldapext@netscape.com Resent-Message-ID: <"z9GBCD.A.9q.M9414"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Our comments are embedded in the copy of the email. : Rick/Ryan, : : : Page 12: : : TECHNICAL: : : e EditDN Edit an entry's DN : b BrowseDN Browse an entry's DN : : How is EditDN permission different from Write permission on the naming : attribute? How is BrowseDN permission different from Search permission : on the naming attribute? Can I have EditDN permission on the entry : without explicit Write permission on the naming attribute of the : entry? What would it mean? : : (EJS) EditDN and BrowseDN work at the entry level (DN) and equate to : permissions : to modify/access the DN for ldapmodifyDN/ldapmodifyRDN/ldapSearch operations. : Write works at the attribute level on attributes. But now you have two different permissions that apply to the same data. What is the precedence between them? How should the server interpret the case where there is EditDN permission on the entry without explicit Write permission on the naming attribute of the entry? "deny" is the default when there is no ACI, and "deny" takes precedence over "grant". Would this mean that the DN cannot be changed even though EditDN is granted? : And do we really need both Search and Compare permissions? : (EJS) Yes, search and compare and 2 different operations. OK. The difference is so slight I had thought we might be able to use one permission to cover both. : >TECHNICAL: What's the interaction between "[entry]" and attributes: if : >somebody has add permission for objects but is denied permissions for : >certain attributes, what happens? : : (EJS) None. [entry] applies to the permissions a/d/e/b. [all] applies to the : permissions for attributes. If a person has add permission, then he can add : an entry and its attributes to that place in the DIT. The permissions for the : attributes he added as part of adding that entry are governed by the access : control attribute (ldapACI) that is added to that entry. So inherited access rights on attributes don't apply when a new object is being created; the only thing that applies is the permission to create a new entry. A person can write all attributes of a newly created object even if inherited attribute rights say the person canNOT write some of those attributes. But as soon as the entry has been created, the creating entity can not change any attribute unless inherited rights permit it. Also, the creating entity CAN create a new ldapACI attribute as part of the new entry and thus override any inherited rights. Taken together, this means that entry level a/d rights mean you can change anything in an entry since you can always delete, then re-add with whatever attribute values you want. This makes us nervous. : Ellen Rick and Ryan From list@netscape.com Tue Mar 21 18:32:04 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23542 for ; Tue, 21 Mar 2000 18:31:54 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA07876; Tue, 21 Mar 2000 15:28:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA22776; Tue, 21 Mar 2000 15:30:30 -0800 (PST) Resent-Date: Tue, 21 Mar 2000 15:30:30 -0800 (PST) From: djbyrne@us.ibm.com X-Lotus-FromDomain: IBMUS To: rvh@qsun.mt.att.com (Richard V Huber) cc: blakley@dascom.com, stokes@austin.ibm.com, ietf-ldapext@netscape.com Message-ID: <852568A9.00811CDC.00@d54mta08.raleigh.ibm.com> Date: Tue, 21 Mar 2000 17:22:08 -0600 Subject: Re: ldapACI permissions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"p_89JB.A.mjF.UYA24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My Comments preceded by < djb > Thanks, Debora Byrne Manager Secure Way Directory Config / User Interface INet: djbyrne@us.ibm.com Phone: (512)838-1930 ( T/L 678 ) : >TECHNICAL: What's the interaction between "[entry]" and attributes: if : >somebody has add permission for objects but is denied permissions for : >certain attributes, what happens? : : (EJS) None. [entry] applies to the permissions a/d/e/b. [all] applies to the : permissions for attributes. If a person has add permission, then he can add : an entry and its attributes to that place in the DIT. The permissions for the : attributes he added as part of adding that entry are governed by the access : control attribute (ldapACI) that is added to that entry. So inherited access rights on attributes don't apply when a new object is being created; the only thing that applies is the permission to create a new entry. A person can write all attributes of a newly created object even if inherited attribute rights say the person canNOT write some of those attributes. But as soon as the entry has been created, the creating entity can not change any attribute unless inherited rights permit it. Also, the creating entity CAN create a new ldapACI attribute as part of the new entry and thus override any inherited rights. Taken together, this means that entry level a/d rights mean you can change anything in an entry since you can always delete, then re-add with whatever attribute values you want. This makes us nervous. < djb > I agree with your analysis that having both delete and add permission on the object essentially means that one could delete the object, and re-add it, filling in attributes, and access control as it liked. If the concern is that users would circumvent the access control checks by doing this sort of thing, I might suggest that an auditing facility is needed for that directory. Is the suggestion here that when creating an entry, a user can only set the values on those attributes to which he also has 'write' permission? Does this also mean the user needs 'write/delete' permission on all attributes which have values when he is deleting the entry? While the draft maintains that the inheritance model is server dependant, from our own experience, I'd suggest caution when restricting what can be done at object creation time. We did ( at one point ) consider an inheritance system where setting access control on newly created objects was controlled by parent inheritance. We ended up removing the feature because our exploiters had great difficulty ensuring their applications could install and use the directory. It required that everyone who could install something needed to have an enormous amount of access to ensure that they could instantiate the needed application objects. From list@netscape.com Tue Mar 21 19:48:43 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22442 for ; Tue, 21 Mar 2000 19:48:40 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA11734; Tue, 21 Mar 2000 16:42:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id QAA13138; Tue, 21 Mar 2000 16:47:07 -0800 (PST) Resent-Date: Tue, 21 Mar 2000 16:47:07 -0800 (PST) From: Farnham@InfoBank.zzn.com Date: Tue, 21 Mar 2000 16:46:43 -0800 (PST) Message-Id: <200003220046.QAA21016@xwing.netscape.com> To: @netscape.com Subject: Quick Cash Secret Banking System X-Reply-To: Farnham@InfoBank.zzn.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"5IhXCC.A.1MD.JgB24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Thank you for your interest in our program. We are happy to announce that after two long years of research, revision and testing, our famous cash program: "Quick Cash Secret Banking System", (QCSBS) is now being released again to the general public, to benefit anyone who is interested in generating a guaranteed $1,500+/ week FAST cash without any hard work or large investment! Quick Cash Secret Banking System (QCSBS) is the fastest and the easiest money making system today in the world, used by all multi-millionaires. It is 100% legal, easy, fast and fun! There are no scams or shady transactions! It is NOT any kind of banking transaction you may have heard about or know! It's Approved by all government agencies, including the US Treasury Dept., American and International Banking Associations, The Fed, World Bank and US Post Office! In our "Quick Cash Secret Banking " Cash kit, you'll discover one of the most powerful cash generating secrets of the Rich and famous! How to open a "SPECIAL Bank Account", do 1-2hrs daily legal bank transactions and rake in $1,500+/week in solid cash!(100% legal and guaranteed, no scam. You can do it from any country, at anytime and whenever you like! You'll also get Four FREE bonus reports! Test us! Allow to us stuff at least $1,500 in easy fast CASH in your pocket starting next week! Blast into the new millennium with a new lease in life, financial Security, Success, Prosperity and happiness! Hurry and email this minute for FREE details to: Farnham@infobank.zzn.com SheilaFarnham@excite.com This is a legitimate business announcement, being sent in compliance with all rules & regulations that govern internet commerce. We respect your privacy. Your name is not in our mailing list so, you'll get this e-mail only once! You must respond within 24hrs to take advantage of our "special offer! Thank you and have a nice day! From list@netscape.com Wed Mar 22 04:52:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29041 for ; Wed, 22 Mar 2000 04:52:48 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id BAA19609; Wed, 22 Mar 2000 01:46:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id BAA19189; Wed, 22 Mar 2000 01:51:39 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 01:51:39 -0800 (PST) Message-ID: <38D89780.F574A8B3@stl.es> Date: Wed, 22 Mar 2000 10:50:57 +0100 From: Julio =?iso-8859-1?Q?S=E1nchez=20Fern=E1ndez?= Organization: Poca X-Mailer: Mozilla 4.7 [en]C-STL/0.1 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-ldapext@netscape.com" Subject: Detecting errors in ldap_get_values Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ymHuaD.A.hrE.qeJ24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit According to the C API draft, NULL is returned both when no values for the attribute type are present in the entry and when some kind of error happened. I have seen code in sendmail 8.10.0 that tries to tell which is it by calling ldap_get_option with LDAP_OPT_ERROR_NUMBER and checking if the returned value is LDAP_SUCCESS. However, it might not be because of an earlier error. Apparently, the code I am looking at is working correctly with the Netscape libraries, but fails with the OpenLDAP development version. I am about to fix this problem, but I don't know what is the correct solution. Should the hidden stored field that LDAP_OPT_ERROR_NUMBER manages be set to LDAP_SUCCESS before calling ldap_get_values and then, if NULL is returned, LDAP_OPT_ERROR_NUMBER will be LDAP_SUCCESS indicating no values were retrieved and something else if an error happened? Thanks in advance, Julio From list@netscape.com Wed Mar 22 06:17:42 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01566 for ; Wed, 22 Mar 2000 06:17:42 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA03132; Wed, 22 Mar 2000 03:14:04 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA02751; Wed, 22 Mar 2000 03:16:36 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 03:16:36 -0800 (PST) Message-ID: <38D8AB37.E9D44016@stl.es> Date: Wed, 22 Mar 2000 12:15:03 +0100 From: Julio =?iso-8859-1?Q?S=E1nchez=20Fern=E1ndez?= Organization: Poca X-Mailer: Mozilla 4.7 [en]C-STL/0.1 (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-ldapext@netscape.com" Subject: Re: Detecting errors in ldap_get_values References: <38D89780.F574A8B3@stl.es> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Resent-Message-ID: <"HrcvMC.A.tq.SuK24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit Julio Sánchez Fernández wrote: > > According to the C API draft, NULL is returned both when no values for > the attribute type are present in the entry and when some kind of error > happened. I have seen code in sendmail 8.10.0 that tries to tell which > is it by calling ldap_get_option with LDAP_OPT_ERROR_NUMBER and checking > if the returned value is LDAP_SUCCESS. Well, silly me, it was not ldap_get_values, but ldap_first_entry and ldap_next_entry. Still, the question stands and is a general API question: When a function uses the same return value to indicate data exhaustion and error, a program making use of that API *must* clear the error number before calling such a function? Or should the API implementation set the error number to LDAP_SUCCESS on all successful calls to such functions? Which is it? Do I fix OpenLDAP or should I make a patch to send the sendmail maintainers? Thanks in advance, Julio From list@netscape.com Wed Mar 22 08:22:48 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12018 for ; Wed, 22 Mar 2000 08:22:47 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id FAA10600; Wed, 22 Mar 2000 05:19:01 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA21855; Wed, 22 Mar 2000 05:21:26 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 05:21:26 -0800 (PST) From: Kyungae_Lim@iris.com Subject: Re: ldapACI permissions To: ietf-ldapext@netscape.com Cc: djbyrne@us.ibm.com X-Mailer: Lotus Notes Build V502_10191999 October 19, 1999 Message-ID: Date: Wed, 22 Mar 2000 08:24:03 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 03/22/2000 08:21:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"Jw3Yp.A.NVF.VjM24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com > < djb > I agree with your analysis that having both delete and add > permission on the object essentially means that one could delete the > object, and re-add it, filling in attributes, and access control as it > liked. If the concern is that users would circumvent the access control > checks by doing this sort of thing, I might suggest that an auditing > facility is needed for that directory. > Is the suggestion here that when creating an entry, a user can only set > the values on those attributes to which he also has 'write' permission? > Does this also mean the user needs 'write/delete' permission on all > attributes which have values when he is deleting the entry? I think both 'add' on entry and 'write' on attributes SHOULD be checked when creating an entry. Otherwise there is no way to prevent a user with 'add' permission only from filling in ldapACI or other security-sensitive attribute values. Auditing can help detecting the problem( after the fact), but shouldn't be a substitue for access checking. From list@netscape.com Wed Mar 22 09:21:57 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04064 for ; Wed, 22 Mar 2000 09:21:57 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA15628; Wed, 22 Mar 2000 06:18:18 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA04337; Wed, 22 Mar 2000 06:20:43 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 06:20:43 -0800 (PST) Message-Id: <3.0.5.32.20000322062023.0098a100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 22 Mar 2000 06:20:23 -0800 To: Julio =?iso-8859-1?Q?S=E1nchez?= =?iso-8859-1?Q?_Fern=E1ndez?= From: "Kurt D. Zeilenga" Subject: Re: Detecting errors in ldap_get_values Cc: "ietf-ldapext@netscape.com" In-Reply-To: <38D8AB37.E9D44016@stl.es> References: <38D89780.F574A8B3@stl.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"Jz6-VB.A.fDB.6aN24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04064 Julio, The current draft is somewhat unclear as to the behavior of LDAP_OPT_ERROR_NUMBER, however it does describe the value as: The code of the most recent LDAP error that occurred for this session Also, each of the routines that return NULL say something like: ldap_first/next_XXX will return NULL when no more XXX exist in the result set to be returned. NULL is also returned if an error occurs while stepping through the entries, in which case the error parameters in the session handle ld will be set to indicate the error. Given these statements, I believe it inappropriate for an API to set LDAP_OPT_ERROR_NUMBER unless an API error has occurred. So, much like POSIX errno, I believe the caller has the responsibility to clear past error codes. The document should avoid the term "LDAP error" and, instead use "LDAP resultCode" and "API error code". The latter being described as being LDAP resultCodes which are reserved by for API use. At 12:15 PM 3/22/00 +0100, Julio Sánchez Fernández wrote: >Do I fix OpenLDAP or should I make a patch to send the >sendmail maintainers? <> I suggest applications experimenting with implementations of LDAP C APIs clear LDAP_OPT_ERROR_NUMBER. From list@netscape.com Wed Mar 22 09:55:49 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16014 for ; Wed, 22 Mar 2000 09:55:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA07764; Wed, 22 Mar 2000 06:49:43 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA14525; Wed, 22 Mar 2000 06:54:31 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 06:54:31 -0800 (PST) From: djbyrne@us.ibm.com X-Lotus-FromDomain: IBMUS To: ietf-ldapext@netscape.com Message-ID: <852568AA.0051DC4C.00@d54mta08.raleigh.ibm.com> Date: Wed, 22 Mar 2000 08:45:59 -0600 Subject: re:draft-ietf-ldapext-acl-model-05 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"5Bg9WC.A.riD.m6N24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My answers prefaced by Thanks, Debora Byrne Manager Secure Way Directory Config / User Interface INet: djbyrne@us.ibm.com Phone: (512)838-1930 ( T/L 678 ) Kyungae_Lim@iris.com on 03/20/2000 12:48:05 PM To: ietf-ldapext@netscape.com cc: Subject: re:draft-ietf-ldapext-acl-model-05 I have a few questions after the first reading: On page 11: "..... If the server does not support partial inheritance and both the entry and subtree scope are used, then entry is the prevailing scope". What does this mean, especially "partial inheritance"? < djb > The ldapAci attribute is multivalued. The syntax we have defined for the attribute value has a property called 'scope'. It is therefore possile for two ldapAci attributes to have different scopes; one might contain 'entry' and another might contain 'subtree'. This implies that some ldapAci values inherit down the tree, and others do not; partial inheritance of the ldapAci attribute. This draft is not meant to define the inheritance model behavior. However, we did want to clarify the expected behavior of servers which only support inheriting the entire ldapAci attribute. On page 22, there is an example of ldamodify - delete syntax. "Given an ACI of: ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ dn: cn = some Entry changetype: modify delete: ldapACI ldapACI: 1.2.3.4#subtree#grant;r; attribute:attr1#group#cn=Dept XYZ would yield a remaining ACI on the server of ldapACI: 1.2.3.4#subtree#grant;r,w; collection:[all]#group#cn=Dept XYZ" Given the same ACI, what would the result if the input to modify-delete is: ldapACI:1.2.3.4#subtree#grant;r;collection:[all]#group#cn=Dept XYZ Will the operation fail( no exact match), or will it return ldapACI: 1.2.3.4#subtree#grant;w;collection:[all]#group#cn=Dept XYZ (w instead of r,w) ldapACI: 1.2.3.4#subtree#grant;r;attribute:attr1#group#cn=Dept XYZ < djb > According to LDAPModify-delete semantics, the operation should fail because no exact match is found. What would be result if the input is: ldapACI:1.2.3.4#subtree#grant;w;attribute:attr1#group#cn=DeptXYZ? < djb > Again, no match is found so the operation should fail. If the client wants to map the error to success, that is up to the client. Section from the RFC : - modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively: add: add values listed to the given attribute, creating the attribute if necessary; *** delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion; replace: replace all existing values of the given attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and is ignored if the attribute does not exist. The result of the modify attempted by the server upon receipt of a Modify Request is returned in a Modify Response, defined as follows: ModifyResponse ::= [APPLICATION 7] LDAPResult Upon receipt of a Modify Request, a server will perform the necessary modifications to the DIT. Wahl, et. al. Standards Track [Page 33] RFC 2251 LDAPv3 December 1997 The server will return to the client a single Modify Response indicating either the successful completion of the DIT modification, or the reason that the modification failed. Note that due to the requirement for atomicity in applying the list of modifications in the Modify Request, the client may expect that no modifications of the DIT have been performed if the Modify Response received indicates any sort of error, and that all requested modifications have been performed if the Modify Response indicates successful completion of the Modify Operation. If the connection fails, whether the modification occurred or not is indeterminate. The Modify Operation cannot be used to remove from an entry any of its distinguished values, those values which form the entry's relative distinguished name. An attempt to do so will result in the server returning the error notAllowedOnRDN. The Modify DN Operation described in section 4.9 is used to rename an entry. *** If an equality match filter has not been defined for an attribute type, clients MUST NOT attempt to delete individual values of that attribute from an entry using the "delete" form of a modification, and MUST instead use the "replace" form. Note that due to the simplifications made in LDAP, there is not a direct mapping of the modifications in an LDAP ModifyRequest onto the EntryModifications of a DAP ModifyEntry operation, and different implementations of LDAP-DAP gateways may use different means of representing the change. If successful, the final effect of the operations on the entry MUST be identical. On page 29, the "public" DN is for setting access to all users. Have you considered to support another DN to represent "authenticated" users, to differentiate "authenticated" from "unauthenticated"? < djb > We have considered this, and have had similar requests from others. I agree that authenticated vs unauthenticated is a very useful distinction. Would anyone have an object to adding another 'pseudo user' which represents all authenticated users, regardless of method of authentication ? While I understand that method of authentication is another useful distinction, I do not ( at this point ) want to get tied up back in the authentication question. From list@netscape.com Wed Mar 22 11:41:56 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24601 for ; Wed, 22 Mar 2000 11:41:55 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA04113; Wed, 22 Mar 2000 08:38:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA25312; Wed, 22 Mar 2000 08:40:24 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 08:40:24 -0800 (PST) From: George_Robert_Blakley_III@tivoli.com X-Lotus-FromDomain: TIVOLI SYSTEMS To: rvh@qsun.mt.att.com (Richard V Huber) cc: blakley@dascom.com, djbyrne@us.ibm.com, stokes@austin.ibm.com, ietf-ldapext@netscape.com Message-ID: <862568AA.004E0A27.00@tivmta4.tivoli.com> Date: Wed, 22 Mar 2000 10:38:23 -0600 Subject: Re: Comments on the ACL Model draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"FvyCd.A.OLG.3dP24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My comments are preceded by This is a joint set of comments from Ryan Moats and Rick Huber. We've been discussing them internally for a while, so they may repeat some of the last day's discussion on the list, but there is a fair amount of new material here. Rick Huber Page 5: EDITORIAL: A "subject' is an entity which initiate actions in an ^ ^^^^^^^^ information system. The quotes on subject don't match. Also, "initiate" should be either "may initiate" or "initiates". TECHNICAL: How is a "role" really different from a "group" which contains all of the subjects in the organizational position that the role represents? In Ellen's response to Dave Chadwick's questions, she quotes Bob Blakley's previous posting on this. Bob's posting talks about having different semantics for combinations (union semantics vs. intersection semantics), but the model in the draft does not seem to allow for different merging semantics, so some of the reason to separate roles and groups is not present. I'm not sure I understand exactly the question here. But let me try again... precedence insures that either groups or roles but not both will be used to make an access decision. In the case where both are present and relevant, precendence will ensure that the decision will be based on the policy stated in the "group" entries corresponding to the user's group memberships. This is in support of using groups as an exception mechanism to override the more general policies enforced by the "role" entries. You're correct that the current draft does not allow for "role" entries to be combined using intersection semantics, which is a function some people might want. However, another way to handle the same requirement is to ensure at credential construction time that each user has only one role entry in his or her credential, thus enforcing role exclusivity. Not everyone agrees that roles should have exclusivity semantics or intersection semantics, so we don't want to require this -- in the future it might be good to specify the semantics of entry combination explicitly in the ACL but for now we've stuck with union default for all entry types to simplify the resolution algorithm. We'll clarify in the document that both "group" and "role" entries are combined using union semantics and that "group" entries and "role entries are not combined with each other. TECHNICAL: More specific policies must override less specific ones (e.g. individual user entry in ACI takes precedence over ^^^^ group entry). The "e.g." makes us very nervous. There needs to be a solid definition of what "more specific" means to avoid problems of interpretation by different developers. In the new draft we state the precedence rules explicitly Also, what would happen if a DN was a member of two groups, where one had rights while the other did not? An example on page 20 says to take the union of rights, but this behavior should be specifically defined in the text, not just in an example. Are union semantics always used for dnTypes at the same precedence? Yes. This will be clarified. --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit From list@netscape.com Wed Mar 22 11:58:47 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01782 for ; Wed, 22 Mar 2000 11:58:46 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA22373; Wed, 22 Mar 2000 08:52:46 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA01218; Wed, 22 Mar 2000 08:57:12 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 08:57:12 -0800 (PST) From: "Ryan Moats" To: "LDAPEXT Mailing List" Subject: Re: ldapACI permissions Date: Wed, 22 Mar 2000 10:54:57 -0600 Message-ID: <000001bf941f$5af0f0e0$e3c8090a@schooner.local.windrose.omaha.ne.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Resent-Message-ID: <"n7DpVD.A.cS.mtP24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit We made a number of comments on this section that are driven by two different concerns. First, there are several cases where two or more permissions will apply to a single LDAP operation and the precedence of those permissions is not clear in the text. The particular example in this email deals with the interaction of the "a/d" permissions for entries and the "w" permission for attributes; some of our other comments dealt with other interactions. We feel the document needs to go through these cases and explain how potential permission conflicts are resolved. In this particular case, the intent seems to be that "d" permission at the entry level allows deletion of all attributes in the entry even if "w" permission is denied for some or all of those attributes, and that "a" permission for entries allows any attribute in the created entry to be given values even if "w" permission is denied for some or all attributes. This should be stated in the text. The second concern is that we are nervous about the consequences of allowing "a" permission to provide values for attributes where the subject may not have "w" permission for some attributes. Surprises should always be avoided in security, and here we have a case where an explicit denial of permission can be overridden by granting a different permission. We also agree with the previous comment on the list that auditing only helps after the fact (or were you suggesting an audit tool that looks for conflicts between "a/d" permissions on entries and "w" permissions on the attributes of those entries?). On the other hand, we recognize the validity of your argument about object creation in the last paragraph of your message below. To date, we have been unable to come up with a real-world example where a subject with "a/d" entry permissions would not also need/have "w" permissions on the objects created. Given that fact, we can live with our nervousness and accept the behavior as long as it is described in the document. Rick Huber Ryan Moats : From: djbyrne@us.ibm.com : To: rvh@qsun.mt.att.com (Richard V Huber) : cc: blakley@dascom.com, stokes@austin.ibm.com, ietf-ldapext@netscape.com : Subject: Re: ldapACI permissions My Comments preceded by < djb > Thanks, Debora Byrne Manager Secure Way Directory Config / User Interface INet: djbyrne@us.ibm.com Phone: (512)838-1930 ( T/L 678 ) : >TECHNICAL: What's the interaction between "[entry]" and attributes: if : >somebody has add permission for objects but is denied permissions for : >certain attributes, what happens? : : (EJS) None. [entry] applies to the permissions a/d/e/b. [all] applies to the : permissions for attributes. If a person has add permission, then he can add : an entry and its attributes to that place in the DIT. The permissions for the : attributes he added as part of adding that entry are governed by the access : control attribute (ldapACI) that is added to that entry. So inherited access rights on attributes don't apply when a new object is being created; the only thing that applies is the permission to create a new entry. A person can write all attributes of a newly created object even if inherited attribute rights say the person canNOT write some of those attributes. But as soon as the entry has been created, the creating entity can not change any attribute unless inherited rights permit it. Also, the creating entity CAN create a new ldapACI attribute as part of the new entry and thus override any inherited rights. Taken together, this means that entry level a/d rights mean you can change anything in an entry since you can always delete, then re-add with whatever attribute values you want. This makes us nervous. < djb > I agree with your analysis that having both delete and add permission on the object essentially means that one could delete the object, and re-add it, filling in attributes, and access control as it liked. If the concern is that users would circumvent the access control checks by doing this sort of thing, I might suggest that an auditing facility is needed for that directory. Is the suggestion here that when creating an entry, a user can only set the values on those attributes to which he also has 'write' permission? Does this also mean the user needs 'write/delete' permission on all attributes which have values when he is deleting the entry? While the draft maintains that the inheritance model is server dependant, from our own experience, I'd suggest caution when restricting what can be done at object creation time. We did ( at one point ) consider an inheritance system where setting access control on newly created objects was controlled by parent inheritance. We ended up removing the feature because our exploiters had great difficulty ensuring their applications could install and use the directory. It required that everyone who could install something needed to have an enormous amount of access to ensure that they could instantiate the needed application objects. From list@netscape.com Wed Mar 22 12:21:24 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10233 for ; Wed, 22 Mar 2000 12:21:19 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA26096; Wed, 22 Mar 2000 09:15:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA11053; Wed, 22 Mar 2000 09:20:11 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 09:20:11 -0800 (PST) From: George_Robert_Blakley_III@tivoli.com X-Lotus-FromDomain: TIVOLI SYSTEMS To: Kyungae_Lim@iris.com cc: ietf-ldapext@netscape.com, djbyrne@us.ibm.com Message-ID: <862568AA.0051BD16.00@tivmta4.tivoli.com> Date: Wed, 22 Mar 2000 11:10:25 -0600 Subject: Re: ldapACI permissions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"k3RAVB.A.bsC.KDQ24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com All, > < djb > I agree with your analysis that having both delete and add > permission on the object essentially means that one could delete the > object, and re-add it, filling in attributes, and access control as it > liked. If the concern is that users would circumvent the access control > checks by doing this sort of thing, I might suggest that an auditing > facility is needed for that directory. > Is the suggestion here that when creating an entry, a user can only set > the values on those attributes to which he also has 'write' permission? > Does this also mean the user needs 'write/delete' permission on all > attributes which have values when he is deleting the entry? I think both 'add' on entry and 'write' on attributes SHOULD be checked when creating an entry. Otherwise there is no way to prevent a user with 'add' permission only from filling in ldapACI or other security-sensitive attribute values. Auditing can help detecting the problem( after the fact), but shouldn't be a substitue for access checking. Note that implementations can use the "Policy Owner" attribute to insure that ldapACI attributes can't be changed by anyone other than security administrators - including at object creation time. Given that there is this level of control (assuming an appropriate implementation), it should be possible to insure that the system configures a new entry's default Access Control policy to ensure what you want without having to force all implementations to do this in a particular way. What we're really talking about here is the default policy which applies to a newly created object. Our choices here seem to be: (1) Allow the creator of the object to set values for specified attributes (including ldapACI) based on permissions governed by an ACL inherited from an ancestor entry. (2) Allow the creator of the object to set values for all attributes EXCEPT ldapACI attributes -- only the policy owner can change the ldapACI attributes (3) Allow the creator of the object to set values for ALL attributes - in this case control over the ldapACI for the newly created object is governed by the ACL on the containing directory. Can we get some discussion toward a consensus here? --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit From list@netscape.com Wed Mar 22 12:44:09 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18414 for ; Wed, 22 Mar 2000 12:44:08 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA29315; Wed, 22 Mar 2000 09:37:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA23433; Wed, 22 Mar 2000 09:42:27 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 09:42:27 -0800 (PST) From: George_Robert_Blakley_III@tivoli.com X-Lotus-FromDomain: TIVOLI SYSTEMS To: Ellen Stokes cc: George_Robert_Blakley_III@tivoli.com Message-ID: <862568AA.0053C60B.01@tivmta4.tivoli.com> Date: Wed, 22 Mar 2000 11:24:53 -0600 Subject: Re: Fwd: Comments on the ACL Model draft Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"36W6yC.A.ftF.CYQ24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com All --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit >Page 21: > >TECHNICAL: > >We are not sure we understand the purpose of Section 7. Is it just a >set of high level examples of sequence of operations? Section 7 is necessary because LDAP is only a protocol specification, not an implementation specification. Implementations are free to build richer access control semantics than those specified in the LDAP ACL Model draft, and they are also free to provide "proprietary" administrative interfaces and protocols which can cause - from the viewpoint of LDAP clients - "silent" and even undefined changes in the access control policy. Section 7 describes two things: (1) The effect of LDAP access control administrative operations on the access decision which will subsequently be made by a server implementation (that is, the semantics of indidividual ldap ACL admin operations), and (2) under what circumstances administrative operations performed on the server implementation but not performed through the LDAP access control administration protocol will result in the semantics of access control policy being undefined from the viewpoint of an LDAP client. >TECHNICAL: > > - Datastore Access Control Policy Update Actions: any > operation implemented by the server which LDAP is > using as its datastore which changes the access > policy enforced with respect to attempts to access > LDAP directory entries and their attributes. > >Is this meant to say that the underlying DBMS/filesystem/etc may impose >policy which overrides the policies expressed by LDAP ACIs? Or is it >meant to say that non-LDAP means (SQL for an underlying RDBMS >datastore) may change the data stored in ldapACI attributes? While >either may be true in general, is it not part of the job of the server >developer to make sure it doesn't happen? Shouldn't LDAP access >control be the way that access control policy is expressed for an LDAP >directory? The server is free to support any policy it wants to as long as that policy is capable of expressing the semantics defined in the LDAP ACL model draft. The server is responsible for enforcing the policy which has been defined. The underlying server's policy *IS* the LDAP policy; this draft merely provides an implementation-independent way of administering the subset of that (underlying) policy which supports the LDAP access control semantics. The underlying server administrator may make changes in the policy, without using the LDAP protocol and *perhaps* without having any LDAP privileges. The changes this administrator makes will be enforced even for LDAP resources. We've had a long set of discussions in the working group about whether all LDAP-supporting repositories must support identical policy semantics, and the consensus has been that this is not feasible. From list@netscape.com Wed Mar 22 12:44:26 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18527 for ; Wed, 22 Mar 2000 12:44:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA29654; Wed, 22 Mar 2000 09:38:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA24314; Wed, 22 Mar 2000 09:42:57 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 09:42:57 -0800 (PST) From: George_Robert_Blakley_III@tivoli.com X-Lotus-FromDomain: TIVOLI SYSTEMS To: Ellen Stokes , ietf-ldapext@netscape.com cc: George_Robert_Blakley_III@tivoli.com Message-ID: <862568AA.0053C60B.00@tivmta4.tivoli.com> Date: Wed, 22 Mar 2000 11:43:16 -0600 Subject: Re: Fwd: Re: please publish (draft-ietf-ldapext-acl-model-05.txt) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"cRiRBB.A.Z7F.gYQ24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Comments prefaced by below. > > >ii) I made a comment on 04 about ReadDN that I don't believe has been > > >addressed yet. There is a difference between letting someone have > > >access to an entry they know exists, and ones they don't know exist. > > >I.e. there is a difference in permissions needed for the base object > > >of a Search and the entries beneath the base object (the latter is a > > >greater permission than the former). At the moment BrowseDN gives the > > >latter permission, but there is not the lesser permission of > > >accessing an entry whose name you already know. This would call for a > > >ReadDN permission I believe. Comments please on this. > > > > (EJS) BrowseDN is ReadDN. > >I know that. What I was saying is that there is not a lesser >permission than BrowseDN that only allows a read if you know the >name beforehand. (Consider web access for example. There are >many web pages that you can only access if you know the URL >beforehand, but cannot browse to look for them) > > >BrowseDN allows that DN in a search. This > > allows someone access to only information that he has been authorized > > for. A person may know that an entry exists, but just because he does > > have that knowledge does not mean he can access it. Likewise, if a > > person doesn't know an entry exists doesn't mean that he should be > > able to discover it. > >Agreed, but you do not currently have a way of allowing someone to >access something they know exists and not have access to >something they dont know exists. This is what I am suggesting >should be added. We could call this the "GuessDN" permission -- if you correctly guess a DN, then the entry whose name you've guessed is returned. If on the other hand, you're sitting at the same entry's superior entry and you have BrowseDN permission but don't know the DN of the entry you're looking for, your Browse attempt will not return the entry. Hmmmmmm...... I don't know if I like this or not -- need to see a compelling example of a problem this lets me solve. < djb > Currently, the "BrowseDN" permission works as follows: 1. If you know the entry, and have browse permission, the DN can be returned 2. If you know the entry, and do not have browse permission, the DN is not returned. 3. If you have browse permission on the entry, the DN can be returned, *regardless* of whether you have browse permission on all ancestors. I think case number 3 solves the web URL problem you mention above. > > >iii) Precedence of privilege dnTypes. I would argue that role comes > > >higher than group as it is more specific. By this I mean that group > > >membership is usually conferred on more people than are roles (and as > > >you said in October, roles can be regarded as groups with > > >permissions). I would expect my role of abc administrator to have > > >more weight than simply a member of the IETF LDAP group. > > > > The following is a cut and paste from Bob Blakley's reasoning in his > > prior email on the precedence stated in this current draft. > > > > The underlying implementation of the access decision function (which > > looks at ACL entries and compares them against the subject's > > credentials to render a yes/no decision about a particular access > > request) may treat "group" entries differently from "role" entries. > > For example, it might implement "union semantics" for groups but > > "intersection semantics" for roles. Thus if an ACL contained 4 > > entries: > > > > group1 : grant (read, search) > > group2 : grant (update) > > role1 : grant (read, search) > > role2 : grant (update) > > > > A subject belonging to group1 and group2 would be granted access > > (because union semantics grants access if any group grants access), > > but a subject belonging to role1 and role2 would be denied access > > (because intersection semantics grants access only if all roles grant > > access). > > > > This ability to distinguish groups and roles semantically is > > important. It permits security administrators to have two different > > subject collection constructs with different granularities and > > different dynamism. Roles (not role attributes -- actual roles) are > > typically defined at a fairly high organizational level and changed > > infrequently. The authorizations granted to role attributes mirror the > > organizational responsibilities associated with the roles. > > > > However in modern organizations roles don't describe the "entire job" > > of an individual -- the VP of marketing may be assigned (for a short > > time) to a task force evaluating the technical competitiveness of a > > product. To participate in this activity, she may need access to > > engineering data to which her job role (or roles) as marketing VP > > don't entitle her. The CFO and the East Region Helpdesk Director may > > also be on the taskforce, and may need access to the same data. To > > grant the desired access to all three of these individuals, it would > > be possible to individually authorize them to the data -- but this > > would be bad for several reasons. The first is scale -- for three > > people this would be feasible, but for 30 it would be unpleasant, and > > for 3000 it would be impractical (especially in organizations which > > run lots of task forces or have lots of matrix management). The second > > is that if you simply put individual entries on the ACL, you might > > forget who the individuals are and why they're on the ACL. In this > > case you'd very likely forget to take them off the ACL when the task > > force ended, thus creating a need-to-know violation. > > > > On the other hand, defining a new "role" for the task force is bad > > also: task force membership isn't really a role; it's really an > > assignment. Adding lots of roles to the role namespace pollutes the > > policy environment and makes it very difficult for the enterprise > > policy administrators, whose job is defining work roles and their > > proper authorizations, to do their work. > > > > What's really called for is defining a "group" -- an ad-hoc collection > > of users who can be authorized to the specific set of resources for > > the duration of the project as an *exception* to the role-based > > policy. The group should be given an evocative name (like the name of > > the project) and should be authorized to the resource. When the > > project ends, the group can be deleted, and its entries can be removed > > from the associated resource ACLs. > > > > As this example suggests, in order to support using groups as > > exceptions to roles, group attributes and role attributes need to have > > different precedence. As the example also suggests, I think groups > > should have *higher* precedence than roles, since roles are > > essentially a coarse-grained, static, subject collection, and groups > > are a fine-grained, dynamic subject collection. > > > > Note that many existing security models, including ISO, ECMA-138, > > CORBA, and others include both groups and roles (and type-distinguish > > the two). > >I follow this and agree with the example as far as it goes, but fail to >see how the example supports the case for multiple role permissions >to be intersection and not union, which appeared to be the rationale >for the example, did it not? Also Bob has not said how role and >group should combine together - would it be union or intersection? If >it were union, then the precedence of group could be below role and >his example would still work, would it not? Therefore can Bob explain >why the example is arguing for group above role. As I said in my earlier note, we don't propose (in this version of the draft) to provide support for using an intersection combinator for roles -- just as with groups we use union here and assume that if you want exclusivity you will insure at credential acquistion time that only one role attribute is in the user's credential. Roles & groups aren't combined -- dnType precendence insures that groups are used where present and relevant; roles are used if groups aren't present or relevant. Strict union for groups & roles together wouldn't work, because "deny" for a role and conflicting "grant" for a group would result in "deny" -- a violation of group precendence over role. --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit From list@netscape.com Wed Mar 22 13:14:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00238 for ; Wed, 22 Mar 2000 13:14:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id KAA21141; Wed, 22 Mar 2000 10:10:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id KAA09897; Wed, 22 Mar 2000 10:12:35 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 10:12:35 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 22 Mar 2000 11:12:13 -0700 From: "Jim Sermersheim" To: , Subject: Re: ldapACI permissions Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"ZjRaED.A.XaC.S0Q24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00238 I think it would be very hard and not very useful to allow one to have 'a' or 'd' rights, and not 'w'. This is especially true when the identity with 'a' rights doesn't have 'w' rights to mandatory attributes. I think certain rights should imply other rights. Maybe a set of 'implication rules' is needed. Something like: Right Implies s c r s, c w r, s, c <- not sure about that one e b a r, w, s, c, e, b d r, w, s, c, e, b note that c and b don't imply any other right, and nothing implies a or d Jim >>> "Ryan Moats" 3/22/00 9:57:36 AM >>> We made a number of comments on this section that are driven by two different concerns. First, there are several cases where two or more permissions will apply to a single LDAP operation and the precedence of those permissions is not clear in the text. The particular example in this email deals with the interaction of the "a/d" permissions for entries and the "w" permission for attributes; some of our other comments dealt with other interactions. We feel the document needs to go through these cases and explain how potential permission conflicts are resolved. In this particular case, the intent seems to be that "d" permission at the entry level allows deletion of all attributes in the entry even if "w" permission is denied for some or all of those attributes, and that "a" permission for entries allows any attribute in the created entry to be given values even if "w" permission is denied for some or all attributes. This should be stated in the text. The second concern is that we are nervous about the consequences of allowing "a" permission to provide values for attributes where the subject may not have "w" permission for some attributes. Surprises should always be avoided in security, and here we have a case where an explicit denial of permission can be overridden by granting a different permission. We also agree with the previous comment on the list that auditing only helps after the fact (or were you suggesting an audit tool that looks for conflicts between "a/d" permissions on entries and "w" permissions on the attributes of those entries?). On the other hand, we recognize the validity of your argument about object creation in the last paragraph of your message below. To date, we have been unable to come up with a real-world example where a subject with "a/d" entry permissions would not also need/have "w" permissions on the objects created. Given that fact, we can live with our nervousness and accept the behavior as long as it is described in the document. Rick Huber Ryan Moats : From: djbyrne@us.ibm.com : To: rvh@qsun.mt.att.com (Richard V Huber) : cc: blakley@dascom.com, stokes@austin.ibm.com, ietf-ldapext@netscape.com : Subject: Re: ldapACI permissions My Comments preceded by < djb > Thanks, Debora Byrne Manager Secure Way Directory Config / User Interface INet: djbyrne@us.ibm.com Phone: (512)838-1930 ( T/L 678 ) : >TECHNICAL: What's the interaction between "[entry]" and attributes: if : >somebody has add permission for objects but is denied permissions for : >certain attributes, what happens? : : (EJS) None. [entry] applies to the permissions a/d/e/b. [all] applies to the : permissions for attributes. If a person has add permission, then he can add : an entry and its attributes to that place in the DIT. The permissions for the : attributes he added as part of adding that entry are governed by the access : control attribute (ldapACI) that is added to that entry. So inherited access rights on attributes don't apply when a new object is being created; the only thing that applies is the permission to create a new entry. A person can write all attributes of a newly created object even if inherited attribute rights say the person canNOT write some of those attributes. But as soon as the entry has been created, the creating entity can not change any attribute unless inherited rights permit it. Also, the creating entity CAN create a new ldapACI attribute as part of the new entry and thus override any inherited rights. Taken together, this means that entry level a/d rights mean you can change anything in an entry since you can always delete, then re-add with whatever attribute values you want. This makes us nervous. < djb > I agree with your analysis that having both delete and add permission on the object essentially means that one could delete the object, and re-add it, filling in attributes, and access control as it liked. If the concern is that users would circumvent the access control checks by doing this sort of thing, I might suggest that an auditing facility is needed for that directory. Is the suggestion here that when creating an entry, a user can only set the values on those attributes to which he also has 'write' permission? Does this also mean the user needs 'write/delete' permission on all attributes which have values when he is deleting the entry? While the draft maintains that the inheritance model is server dependant, from our own experience, I'd suggest caution when restricting what can be done at object creation time. We did ( at one point ) consider an inheritance system where setting access control on newly created objects was controlled by parent inheritance. We ended up removing the feature because our exploiters had great difficulty ensuring their applications could install and use the directory. It required that everyone who could install something needed to have an enormous amount of access to ensure that they could instantiate the needed application objects. From list@netscape.com Wed Mar 22 16:24:48 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08496 for ; Wed, 22 Mar 2000 16:24:33 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA02596; Wed, 22 Mar 2000 13:18:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA07141; Wed, 22 Mar 2000 13:23:14 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 13:23:14 -0800 (PST) From: Kyungae_Lim@iris.com Subject: Re: ldapACI permissions To: George_Robert_Blakley_III@tivoli.com Cc: djbyrne@us.ibm.com, ietf-ldapext@netscape.com X-Mailer: Lotus Notes Build V502_10191999 October 19, 1999 Message-ID: Date: Wed, 22 Mar 2000 16:25:15 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 03/22/2000 04:23:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"5mRNuD.A.TvB.BnT24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com George_Robert_Blakley_III@ tivoli.com To: Kyungae_Lim@iris.com cc: ietf-ldapext@netscape.com, djbyrne@us.ibm.com 03/22/00 12:10 PM Subject: Re: ldapACI permissions All, > < djb > I agree with your analysis that having both delete and add > permission on the object essentially means that one could delete the > object, and re-add it, filling in attributes, and access control as it > liked. If the concern is that users would circumvent the access control > checks by doing this sort of thing, I might suggest that an auditing > facility is needed for that directory. > Is the suggestion here that when creating an entry, a user can only set > the values on those attributes to which he also has 'write' permission? > Does this also mean the user needs 'write/delete' permission on all > attributes which have values when he is deleting the entry? I think both 'add' on entry and 'write' on attributes SHOULD be checked when creating an entry. Otherwise there is no way to prevent a user with 'add' permission only from filling in ldapACI or other security-sensitive attribute values. Auditing can help detecting the problem( after the fact), but shouldn't be a substitue for access checking. Note that implementations can use the "Policy Owner" attribute to insure that ldapACI attributes can't be changed by anyone other than security administrators - including at object creation time. Given that there is this level of control (assuming an appropriate implementation), it should be possible to insure that the system configures a new entry's default Access Control policy to ensure what you want without having to force all implementations to do this in a particular way. If I understand the draft correctly, it does not mandate how the "Policy Owner" attribute should be implemented. I suppose in some implementations the "Policy Owner" can be expressed as another ACI - write access to the ldapACI attribute, on the basis that if you have write access to ldapACI, you essentially have full access to that object. In such implementation the "Policy Owner" checking is equivalent to write access checking on the attribute. What we're really talking about here is the default policy which applies to a newly created object. It is not just ldapACI - the question is, should a user with the 'add' permission be allowed to set ANY attribute value during object creation time, or is there a way for the administrator to restrict access to enter certain (sensitive) attributes while still granting the 'add' permission? Our choices here seem to be: (1) Allow the creator of the object to set values for specified attributes (including ldapACI) based on permissions governed by an ACL inherited from an ancestor entry. (2) Allow the creator of the object to set values for all attributes EXCEPT ldapACI attributes -- only the policy owner can change the ldapACI attributes (3) Allow the creator of the object to set values for ALL attributes - in this case control over the ldapACI for the newly created object is governed by the ACL on the containing directory. Can we get some discussion toward a consensus here? How is 3) different from 1)? --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit From list@netscape.com Wed Mar 22 17:17:25 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28029 for ; Wed, 22 Mar 2000 17:17:23 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA28627; Wed, 22 Mar 2000 14:13:36 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA03866; Wed, 22 Mar 2000 14:16:07 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 14:16:07 -0800 (PST) Date: Wed, 22 Mar 2000 14:15:02 -0800 (PST) Message-Id: <200003222215.OAA27729@ywing.netscape.com> From: bigideas@TKRB.proudmama.com To: ietf-ldapext@netscape.com Subject: 50k in 90 days!! X-Reply-To: bigid77@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"seABhD.A.I8.mYU24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit INCREDIBLE! $0 TO $50,000 IN 90 DAYS!!! Dear Friend, You can earn $50,000 or more in the next 90 days sending e-mail. Seems Impossible? Read on for details. "AS SEEN ON NATIONAL TV" Thank you for your time and interest. This is the letter you have been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in the program. HERE IT IS BELOW: (Print This Now For Future Reference) ************************************* The following income opportunity is one that I'm sure will grab your attention! It can be started with VERY LITTLE investment and the income return is TREMENDOUS! If you would like to make at least $50,000 in less than 90 days Please read the enclosed program ...THEN READ IT AGAIN!!! THIS IS A LEGITIMATE, LEGAL, MONEYMAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multilevel e-mail order marketing program works perfectly...l00% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action! MULTILEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multilevel methods by the mid to late 1990's. This is a Multi- Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaire's everyday through Multilevel Marketing. Not long ago Donald Trump was a guest on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and deadpanned his response: "That's why I 'm sitting up here and you are all sitting out there." After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT?" Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling you like it is. I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it made me. Remember that it won't work if you don't try it. This program does work but you must follow it EXACTLY! Especially follow the rule about not changing the position of your name on the list. It won't work and you'll lose out on a lot of money! In order for this program to work, you must follow the program as described. A Note from the Founder: By the time you have read the enclosed program and reports, you should have concluded that an amateur could, not have created such a program, and one that is legal. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. (I should also point out that I will not see a penny of this money, nor will anyone else who has provided a testimonial for this program.) I have already made over 4 MILLION DOLLARS! I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000, and your name will be on every one of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA ********************************* Instructions: HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS. This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say, "BULL....", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multilevel businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multilevel business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multilevel Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember that this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY. 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE There are two primary methods of building your down line: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of that 0.5%, 100 people respond and order REPORT #2. Those 100 responses in turn mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 per each net connection and e-mail is FREE!! ! REPORT #2 will show you the best methods for bulk e-mailing; tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the Internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 down line members. Follow this example to achieve the STAGGERING results below: 1st level--your 10 members with $5 = $50 2nd level--10 members from those 10 ($5 x 100) = $500 3rd level--10 members from those 100 ($5 x 1,000) = $5,000 4th level--10 members from those 1,000 ($5 x 10,000) = $50,000 THIS TOTALS: $55,550!! Remember friends; this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants. THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER and NAME *** Notes: *ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. *ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. *Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) The number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: BIG IDEAS PO Box 156 Taylors Falls, MN 55084 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: TTS PO Box 686 Buffalo, TX 75831 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: WT ENTERPRISES 3352 WOOLSEY ROAD WINDSOR, CA 95492 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Touchstone PO BOX 914 NEW CASTLE, IN 47362 Tips for Success: **TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. **Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. **Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! **ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ***** YOUR SUCCESS GUIDELINES***** Follow these guidelines to guarantee your success. If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product, which does not cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense, other than your initial $20 investment, is your time. 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER!!! From list@netscape.com Wed Mar 22 17:21:25 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29250 for ; Wed, 22 Mar 2000 17:21:25 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA29932; Wed, 22 Mar 2000 14:17:52 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA07699; Wed, 22 Mar 2000 14:20:24 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 14:20:24 -0800 (PST) Message-Id: <3.0.5.32.20000322142008.0098c100@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 22 Mar 2000 14:20:08 -0800 To: "Jim Sermersheim" From: "Kurt D. Zeilenga" Subject: Re: ldapACI permissions Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"xv-DUD.A.B4B.ncU24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com At 11:12 AM 3/22/00 -0700, Jim Sermersheim wrote: >I think it would be very hard and not very useful to allow one to have 'a' or 'd' rights, and not 'w'. This is especially true when the identity with 'a' rights doesn't have 'w' rights to mandatory attributes. I think certain rights should imply other rights. Maybe a set of 'implication rules' is needed. Something like: > This is just food for thought: Have used access levels ("write" => "read" => "search" => "compare") in OpenLDAP for some time, I have only found a couple of cases (such as disallow search of readable attribute) where discrete permissions would have been extermely useful. These cases were enough to convince me that we should add support for such. What our devel code now supports both, it can be viewed (simplification): "write" is "=wrsc" "read" is "=rsc" "search" is "=sc" "compare" is "=c" where the "=" sign is used to flag indicate the value is a discrete set of permissions. If you wanted to grant "r" but not "sc", you'd say "=r". From list@netscape.com Wed Mar 22 18:32:43 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23771 for ; Wed, 22 Mar 2000 18:32:28 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA09893; Wed, 22 Mar 2000 15:28:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA05812; Wed, 22 Mar 2000 15:31:19 -0800 (PST) Resent-Date: Wed, 22 Mar 2000 15:31:19 -0800 (PST) From: djbyrne@us.ibm.com X-Lotus-FromDomain: IBMUS To: ietf-ldapext@netscape.com cc: Kyungae_Lim@iris.com Message-ID: <852568AA.00813148.00@d54mta08.raleigh.ibm.com> Date: Wed, 22 Mar 2000 17:22:59 -0600 Subject: Re: ldapACI permissions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Resent-Message-ID: <"OJxukB.A.haB.GfV24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com My response < djb > Thanks, Debora Byrne Manager Secure Way Directory Config / User Interface INet: djbyrne@us.ibm.com Phone: (512)838-1930 ( T/L 678 ) George_Robert_Blakley_III@ tivoli.com To: Kyungae_Lim@iris.com cc: ietf-ldapext@netscape.com, djbyrne@us.ibm.com 03/22/00 12:10 PM Subject: Re: ldapACI permissions All, What we're really talking about here is the default policy which applies to a newly created object. It is not just ldapACI - the question is, should a user with the 'add' permission be allowed to set ANY attribute value during object creation time, or is there a way for the administrator to restrict access to enter certain (sensitive) attributes while still granting the 'add' permission? Our choices here seem to be: (1) Allow the creator of the object to set values for specified attributes (including ldapACI) based on permissions governed by an ACL inherited from an ancestor entry. (2) Allow the creator of the object to set values for all attributes EXCEPT ldapACI attributes -- only the policy owner can change the ldapACI attributes (3) Allow the creator of the object to set values for ALL attributes - in this case control over the ldapACI for the newly created object is governed by the ACL on the containing directory. Can we get some discussion toward a consensus here? How is 3) different from 1)? < djb > We were not specific enough in option 3. In option 3, we allow all values to be set at object creation time. After creation, the attributes are controlled by the ldapACI attribute. In option 1, the attributes which can be specified at object creation time are determined by an ancestor entries ldapACI. The creator would need 'write' access to the attributes (s)he wants to set. After creation time, they are controlled by the ldapACI attribute at the entry ( possibly the value is inherited from an ancestor ) ( Option 2 is similar to option 3 except that the ldapACI value can not set ) --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit From list@netscape.com Thu Mar 23 09:55:36 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02417 for ; Thu, 23 Mar 2000 09:55:21 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id GAA00346; Thu, 23 Mar 2000 06:49:18 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id GAA24619; Thu, 23 Mar 2000 06:53:54 -0800 (PST) Resent-Date: Thu, 23 Mar 2000 06:53:54 -0800 (PST) Date: Thu, 23 Mar 2000 09:53:43 -0500 Message-Id: <200003231453.JAA05335@qsun.mt.att.com> From: rvh@qsun.mt.att.com (Richard V Huber) To: George_Robert_Blakley_III@tivoli.com Subject: Section 7 of ACL Model draft Cc: ietf-ldapext@netscape.com, jayhawk@qsun.mt.att.com Resent-Message-ID: <"5gS4DD.A.XAG.BAj24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com We'd like to summarize our understanding of your email and of Section 7 to make sure we understand properly. We think you are saying that an implementation may provide access control syntax and semantics beyond those described in the draft. If they do so, the additional permissions may cause behavior that is undefined by the LDAP Access Control Model. In that case, shouldn't section 7 contain a statement along the lines of: Implementations MAY implement additional access control mechanisms beyond those described in this standard. However, implementations that wish to be completely consistent with the standard for over-the-wire exchange of access control information MUST avoid use of mechanisms that cannot be expressed using the model defined in this document. Rick Huber Ryan Moats >Page 21: > >TECHNICAL: > >We are not sure we understand the purpose of Section 7. Is it just a >set of high level examples of sequence of operations? Section 7 is necessary because LDAP is only a protocol specification, not an implementation specification. Implementations are free to build richer access control semantics than those specified in the LDAP ACL Model draft, and they are also free to provide "proprietary" administrative interfaces and protocols which can cause - from the viewpoint of LDAP clients - "silent" and even undefined changes in the access control policy. Section 7 describes two things: (1) The effect of LDAP access control administrative operations on the access decision which will subsequently be made by a server implementation (that is, the semantics of indidividual ldap ACL admin operations), and (2) under what circumstances administrative operations performed on the server implementation but not performed through the LDAP access control administration protocol will result in the semantics of access control policy being undefined from the viewpoint of an LDAP client. >TECHNICAL: > > - Datastore Access Control Policy Update Actions: any > operation implemented by the server which LDAP is > using as its datastore which changes the access > policy enforced with respect to attempts to access > LDAP directory entries and their attributes. > >Is this meant to say that the underlying DBMS/filesystem/etc may impose >policy which overrides the policies expressed by LDAP ACIs? Or is it >meant to say that non-LDAP means (SQL for an underlying RDBMS >datastore) may change the data stored in ldapACI attributes? While >either may be true in general, is it not part of the job of the server >developer to make sure it doesn't happen? Shouldn't LDAP access >control be the way that access control policy is expressed for an LDAP >directory? The server is free to support any policy it wants to as long as that policy is capable of expressing the semantics defined in the LDAP ACL model draft. The server is responsible for enforcing the policy which has been defined. The underlying server's policy *IS* the LDAP policy; this draft merely provides an implementation-independent way of administering the subset of that (underlying) policy which supports the LDAP access control semantics. The underlying server administrator may make changes in the policy, without using the LDAP protocol and *perhaps* without having any LDAP privileges. The changes this administrator makes will be enforced even for LDAP resources. We've had a long set of discussions in the working group about whether all LDAP-supporting repositories must support identical policy semantics, and the consensus has been that this is not feasible. From list@netscape.com Thu Mar 23 10:06:12 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07197 for ; Thu, 23 Mar 2000 10:06:11 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA25911; Thu, 23 Mar 2000 07:02:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA28443; Thu, 23 Mar 2000 07:04:39 -0800 (PST) Resent-Date: Thu, 23 Mar 2000 07:04:39 -0800 (PST) Message-Id: <4.2.2.20000323085110.00a26d70@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 23 Mar 2000 09:06:39 -0600 To: "Kurt D. Zeilenga" , "Jim Sermersheim" From: Ellen Stokes Subject: Re: ldapACI permissions Cc: , In-Reply-To: <3.0.5.32.20000322142008.0098c100@infidel.boolean.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"gymca.A.H8G.GKj24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Although it is tempting to 'imply' permissions as articulated in Jim's and Kurt's notes, this is dangerous in that it allows some desired policies not be able to be expressed. An example is the administrator who needs the capability to reset a user's password (the admin needs 'write''), but should not / must not have the capability to read or compare that user's password values. The counter argument to this would be to additionally deny the admin read and compare. But that's more rules on the ACL. Also, if you go back to the requriements document, it is stated that 'safer is better' - in this context, explicitly specify the permissions so you know what you get instead of implying permissions. See S13, G1, and G2 in the requirements document. Ellen At 02:20 PM 3/22/00 -0800, Kurt D. Zeilenga wrote: >At 11:12 AM 3/22/00 -0700, Jim Sermersheim wrote: > >I think it would be very hard and not very useful to allow one to have > 'a' or 'd' rights, and not 'w'. This is especially true when the identity > with 'a' rights doesn't have 'w' rights to mandatory attributes. I think > certain rights should imply other rights. Maybe a set of 'implication > rules' is needed. Something like: > > > >This is just food for thought: > >Have used access levels ("write" => "read" => "search" => "compare") in >OpenLDAP >for some time, I have only found a couple of cases (such as disallow search >of readable attribute) where discrete permissions would have been extermely >useful. These cases were enough to convince me that we should add support >for such. > >What our devel code now supports both, it can be viewed (simplification): > "write" is "=wrsc" > "read" is "=rsc" > "search" is "=sc" > "compare" is "=c" > >where the "=" sign is used to flag indicate the value is a discrete set of >permissions. If you wanted to grant "r" but not "sc", you'd say "=r". From list@netscape.com Thu Mar 23 12:01:18 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20769 for ; Thu, 23 Mar 2000 12:01:18 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA14577; Thu, 23 Mar 2000 08:55:20 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA10423; Thu, 23 Mar 2000 08:59:59 -0800 (PST) Resent-Date: Thu, 23 Mar 2000 08:59:59 -0800 (PST) From: "Alexis Bor" To: "Richard V Huber" , Cc: , Subject: RE: Section 7 of ACL Model draft Date: Thu, 23 Mar 2000 08:59:55 -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.2911.0) Importance: Normal In-Reply-To: <200003231453.JAA05335@qsun.mt.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Resent-Message-ID: <"fSljtC.A.liC.O2k24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I wonder if it needs to be even stronger, perhaps even mentioning that replication is very likely to break and potentially referrals as well. -- Alexis Alexis Bor Directory Works, Inc. alexis.bor@directoryworks.com http://www.directoryworks.com -----Original Message----- From: Richard V Huber [mailto:rvh@qsun.mt.att.com] Sent: Thursday, March 23, 2000 6:54 AM To: George_Robert_Blakley_III@tivoli.com Cc: ietf-ldapext@netscape.com; jayhawk@qsun.mt.att.com Subject: Section 7 of ACL Model draft We'd like to summarize our understanding of your email and of Section 7 to make sure we understand properly. We think you are saying that an implementation may provide access control syntax and semantics beyond those described in the draft. If they do so, the additional permissions may cause behavior that is undefined by the LDAP Access Control Model. In that case, shouldn't section 7 contain a statement along the lines of: Implementations MAY implement additional access control mechanisms beyond those described in this standard. However, implementations that wish to be completely consistent with the standard for over-the-wire exchange of access control information MUST avoid use of mechanisms that cannot be expressed using the model defined in this document. Rick Huber Ryan Moats >Page 21: > >TECHNICAL: > >We are not sure we understand the purpose of Section 7. Is it just a >set of high level examples of sequence of operations? Section 7 is necessary because LDAP is only a protocol specification, not an implementation specification. Implementations are free to build richer access control semantics than those specified in the LDAP ACL Model draft, and they are also free to provide "proprietary" administrative interfaces and protocols which can cause - from the viewpoint of LDAP clients - "silent" and even undefined changes in the access control policy. Section 7 describes two things: (1) The effect of LDAP access control administrative operations on the access decision which will subsequently be made by a server implementation (that is, the semantics of indidividual ldap ACL admin operations), and (2) under what circumstances administrative operations performed on the server implementation but not performed through the LDAP access control administration protocol will result in the semantics of access control policy being undefined from the viewpoint of an LDAP client. >TECHNICAL: > > - Datastore Access Control Policy Update Actions: any > operation implemented by the server which LDAP is > using as its datastore which changes the access > policy enforced with respect to attempts to access > LDAP directory entries and their attributes. > >Is this meant to say that the underlying DBMS/filesystem/etc may impose >policy which overrides the policies expressed by LDAP ACIs? Or is it >meant to say that non-LDAP means (SQL for an underlying RDBMS >datastore) may change the data stored in ldapACI attributes? While >either may be true in general, is it not part of the job of the server >developer to make sure it doesn't happen? Shouldn't LDAP access >control be the way that access control policy is expressed for an LDAP >directory? The server is free to support any policy it wants to as long as that policy is capable of expressing the semantics defined in the LDAP ACL model draft. The server is responsible for enforcing the policy which has been defined. The underlying server's policy *IS* the LDAP policy; this draft merely provides an implementation-independent way of administering the subset of that (underlying) policy which supports the LDAP access control semantics. The underlying server administrator may make changes in the policy, without using the LDAP protocol and *perhaps* without having any LDAP privileges. The changes this administrator makes will be enforced even for LDAP resources. We've had a long set of discussions in the working group about whether all LDAP-supporting repositories must support identical policy semantics, and the consensus has been that this is not feasible. From list@netscape.com Thu Mar 23 17:07:17 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08745 for ; Thu, 23 Mar 2000 17:07:07 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA24888; Thu, 23 Mar 2000 14:00:54 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA23678; Thu, 23 Mar 2000 14:05:44 -0800 (PST) Resent-Date: Thu, 23 Mar 2000 14:05:44 -0800 (PST) From: jeffallen@sourcenet.org To: ietf-ldapext@netscape.com Subject: Information you requested about savings on your current utilities Date: Thu, 23 Mar 2000 17:11:41 Message-Id: <673.317008.436103@sourcenet.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"RczUGC.A.mxF.2Up24"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com You requested information on how you could save 30% on your phone bill and receive up to 8% back each month on your utilities. http://www.acninc.com RUID# 0392753 ACN is a cooperative marketing company capitalizing on the world-wide deregulation of the utilities industries (Telecommunications / Internet / Gas and Electricity). ACN's services are attractively priced: FREE* paging service, FREE* unlimited Internet service, Long Distance as low as 5-cents a minute with ONE second billing (no rounding to the nearest minute) with a FREE 800 number! Try the long distance service 5 cents per minute 24/7 and pay no switching fees and if you decide after a month or two that you want to go back we'll switch you back for free. With the free 800#, give it out to your kids and other family members. When they call you it won't cost them anything and will only cost you 10 cents per minute. The company I am with is saving 50% on their long distance because our rates are half of what they were with the other carrier. This long distance works well with both businesses as well as residences. Our company signed up as a rep so that we could offer this as a service to all our customers and suppliers, and we get up to 8% each and every month based on the amount of their usage. I used to use AT&T for all my long distance and cellular services. They first called me up because I was using another company and making a lot of international calls. They said they were competitive with my current carrier with better customer service. Well, they switched over my long distance but for to put me onto their international plan. I got a good discount for calls within the United States but my International rates went up over 1000%. Their customer service refused to give me any credit whatsoever and I decided to look around for other options. That's how I found the CAN. I now earn up to 8% on everybody I refer to this service. Whether you sign up as a customer or representative, you can't lose. Worse case scenario, you'll only save money. I will follow up again later and let you know more about the business opportunity of sharing this with people you know. Jeffrey Solochek 912-826-1311 . From list@netscape.com Fri Mar 24 10:10:54 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19256 for ; Fri, 24 Mar 2000 10:10:53 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id HAA11124; Fri, 24 Mar 2000 07:04:51 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id HAA09147; Fri, 24 Mar 2000 07:09:43 -0800 (PST) Resent-Date: Fri, 24 Mar 2000 07:09:43 -0800 (PST) From: Kyungae_Lim@iris.com Subject: Re: ldapACI permissions To: djbyrne@us.ibm.com Cc: ietf-ldapext@netscape.com X-Mailer: Lotus Notes Build V502_10191999 October 19, 1999 Message-ID: Date: Fri, 24 Mar 2000 10:12:19 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V503_03082000 |March 8, 2000) at 03/24/2000 10:09:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Resent-Message-ID: <"iPG8bD.A.pOC.2U424"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com So to recap what the options are: option 1 - "add", and "write" permission to the parent option 2 - "add", except when ldapACI is specified, in which case the "policyOwner" is also checked option 3 - "add". I'm for the option 1. The option 2 requires the implementation of the "policyOwner" independent of ldapACI, which is not my interpretation of the draft. In either the option 2 or 3, there is not a way to restrict write access to certain attributes when an entry is created. As a system administrator I may want to give someone permissions to add an entry but does not necessarily want to give the person to fill in certain attribute values at the same time, for the same reason for not granting that person "write" permissions on those attributes. djbyrne@us.ib m.com To: ietf-ldapext@netscape.com cc: Kyungae_Lim@iris.com 03/22/00 Subject: Re: ldapACI permissions 06:22 PM My response < djb > Thanks, Debora Byrne Manager Secure Way Directory Config / User Interface INet: djbyrne@us.ibm.com Phone: (512)838-1930 ( T/L 678 ) George_Robert_Blakley_III@ tivoli.com To: Kyungae_Lim@iris.com cc: ietf-ldapext@netscape.com, djbyrne@us.ibm.com 03/22/00 12:10 PM Subject: Re: ldapACI permissions All, What we're really talking about here is the default policy which applies to a newly created object. It is not just ldapACI - the question is, should a user with the 'add' permission be allowed to set ANY attribute value during object creation time, or is there a way for the administrator to restrict access to enter certain (sensitive) attributes while still granting the 'add' permission? Our choices here seem to be: (1) Allow the creator of the object to set values for specified attributes (including ldapACI) based on permissions governed by an ACL inherited from an ancestor entry. (2) Allow the creator of the object to set values for all attributes EXCEPT ldapACI attributes -- only the policy owner can change the ldapACI attributes (3) Allow the creator of the object to set values for ALL attributes - in this case control over the ldapACI for the newly created object is governed by the ACL on the containing directory. Can we get some discussion toward a consensus here? How is 3) different from 1)? < djb > We were not specific enough in option 3. In option 3, we allow all values to be set at object creation time. After creation, the attributes are controlled by the ldapACI attribute. In option 1, the attributes which can be specified at object creation time are determined by an ancestor entries ldapACI. The creator would need 'write' access to the attributes (s)he wants to set. After creation time, they are controlled by the ldapACI attribute at the entry ( possibly the value is inherited from an ancestor ) ( Option 2 is similar to option 3 except that the ldapACI value can not set ) --bob Bob Blakley Chief Scientist Tivoli SecureWay Business Unit From list@netscape.com Sat Mar 25 16:47:55 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23835 for ; Sat, 25 Mar 2000 16:47:54 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA15372; Sat, 25 Mar 2000 13:41:44 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id NAA09266; Sat, 25 Mar 2000 13:46:38 -0800 (PST) Resent-Date: Sat, 25 Mar 2000 13:46:38 -0800 (PST) Date: Sat, 25 Mar 2000 13:46:23 -0800 (PST) Message-Id: <200003252146.NAA10391@ywing.netscape.com> From: "B Metcal" To: Income.Seekers.HUQB@netscape.com Subject: I seek permission... -ECWG X-Reply-To: B Metcalf bmetcalf@yoyomail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"mP1AAC.A.cQC.9OT34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Your address has been given to me as someone who is interested in NEW OPPORTUNITIES to supplement your income. I have one of those opportunities. I would like to send it to you. If you do not wish to receive my offer, please send a return message with "REMOVE FROM LIST" Thank you. From list@netscape.com Sat Mar 25 18:46:33 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01244 for ; Sat, 25 Mar 2000 18:46:28 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA03317; Sat, 25 Mar 2000 15:42:48 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA22500; Sat, 25 Mar 2000 15:45:22 -0800 (PST) Resent-Date: Sat, 25 Mar 2000 15:45:22 -0800 (PST) From: mail.toyou@algeria.com Date: Sat, 25 Mar 2000 15:45:19 -0800 (PST) Message-Id: <200003252345.PAA22307@ywing.netscape.com> To: klfldfjk@mail.com Subject: No suit! No Commute!! Resent-Message-ID: <"v0X1LD.A.GfF.R-U34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com LOOKING FOR GEMS! It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays... We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000 per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income! Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme? If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need. Call NOW our TOLL FREE, PRE-RECORDED Message:1-800-320-9895 ext. 7455 We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you. You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now! The call is FREE, and there is absolutely no obligation, So what have you got to lose? Call Toll Free 1-800-320-9895 ext. 7455 P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life! Please, serious inquiries only. We apologize for any inconvenience hitting the delete key has caused if you did not wish to receive this message. This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301). "Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, From list@netscape.com Sun Mar 26 03:27:10 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04750 for ; Sun, 26 Mar 2000 03:27:09 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id AAA18686; Sun, 26 Mar 2000 00:23:31 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id AAA15494; Sun, 26 Mar 2000 00:26:04 -0800 (PST) Resent-Date: Sun, 26 Mar 2000 00:26:04 -0800 (PST) Message-Id: <3.0.5.32.20000324091340.0091c370@infidel.boolean.net> X-Sender: guru@infidel.boolean.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 24 Mar 2000 09:13:40 +0900 To: ietf-ldapext@netscape.com From: "Kurt D. Zeilenga" Subject: ExtendedPartialResponse Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"hI27qD.A.0xD.bmc34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I would like to see this mechanims further generalized. That is, I see no reason to restrict this response to ExtendedRequests. I believe it would be useful for other operations as well. For example, this request could be sent in response to a compare/delete/modify with some sort of subtree control. I would prefer the ExtendedPartialResponse be allowed in response to any request (including search) where they are solicited by control or extended operation defintion. That is, a server should not blind side clients with such responses. I also suggest that we deprecate ExtendedResponse as an allowed search response. Is this capability in use? Kurt From list@netscape.com Sun Mar 26 20:00:18 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23119 for ; Sun, 26 Mar 2000 20:00:17 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA17272; Sun, 26 Mar 2000 15:37:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA29390; Sun, 26 Mar 2000 15:40:00 -0800 (PST) Resent-Date: Sun, 26 Mar 2000 15:40:00 -0800 (PST) From: biz@uk2.net To: Date: Mon, 27 Mar 2000 03:07:52 Message-Id: <550.866735.204797@server02> Subject: $120 PER HOUR VIEWING ADS! Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"CbJwSD.A.8KH.P_p34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit You are receiving this message because you or someone else has requested information from us in the past. THIS IS A ONE TIME MAILING ONLY - NO other e-mails will be sent to you by us regarding this offer! Thank you for your kind consideration. ========================================= Beleive it or not! This company is paying people $120 per hour to watch full screen ads on their computer, with the option of sound and motion. You choose which ads you want to watch and when you want to watch them. 11,000 people are signing up every day,worldwide! The more people join, the more advertisers will pay! This is without doubt the best GENUINE "work from home" online opportunity around. For full details click on the link below: http://www.bizoppreview.co.uk/users Thanks D.S. Media biz@uk2.net This message is sent in compliance of the new e-mail bill:section 301 Per Section 301. Paragraph (a)(2)(c) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html Further transmissions to you by the sender of this e-mail may be stopped, by sending a reply with the word "remove" in the subject line to: biz@uk2.net From list@netscape.com Sun Mar 26 20:01:50 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23818 for ; Sun, 26 Mar 2000 20:01:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id QAA20577; Sun, 26 Mar 2000 16:58:07 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA10140; Sun, 26 Mar 2000 17:00:41 -0800 (PST) Resent-Date: Sun, 26 Mar 2000 17:00:41 -0800 (PST) From: jeffallen@sourcenet.org Date: Sun, 26 Mar 2000 17:00:38 -0800 (PST) To: Subject: ACN- More Info 1 RUID# 0392753 Message-Id: Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gKwzUB.A.KeC.4Kr34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Here is the information you requested. If I could save you 30% on your long distance each month would you be interested in giving it a try? Or at least receiving more information? It doesn't cost you anything to take advantage of the service's ACN is offering. ACN is a cooperative marketing company capitalizing on the world-wide deregulation of the utilities industries (Telecommunications / Internet / Gas and Electricity). ACN's services are attractively priced: FREE* paging service, FREE* unlimited Internet service, Long Distance as low as 5-cents a minute with ONE second billing (no rounding to the nearest minute) with a FREE 800 number! Try the long distance service 5 cents per minute 24/7 and pay no switching fees and if you decide after a month or two that you want to go back we'll switch you back for free. With the free 800#, give it out to your kids and other family members. When they call you it won't cost them anything and will only cost you 10 cents per minute. The company I am with is saving 50% on their long distance because our rates are half of what they were with the other carrier. This long distance works well with both businesses as well as residences. Our company signed up as a rep so that we could offer this as a service to all our customers and suppliers, and we get up to 8% each and every month based on the amount of their usage. ACN is a cooperative marketing company capitalizing on the world-wide deregulation of the utilities industries(Telecommunications / Internet / Gas and Electricity). It provides a solid opportunity to earn a lifelong, continuous RESIDUAL income every time someone makes a local or long-distance phone call, uses a pager, uses the internet, orders a product from the internet, or turns on their lights or air conditioning. Our representatives are simply helping people save money on basic services that they need every month, as well as helping other people make extra money by helping expand our business. The company is a proven entity: cash rich, debt free, with over $100 million in annual revenue in 1998, and with billings projected to be around $1 billion in 2000. Its just under seven years old with over 100,000 active independent representatives throughout the USA, Canada and Europe. Over 75 people have achieved the company's top position of Regional Vice President with average RESIDUAL income of $33,000 per month. Some earn over $100,000 per month. But more important, there are a lot of "average" people making a "more-than-average" extra income. ACN has been featured in Success magazine and was listed as the 22nd fastest growing company in Inc. magazine’s list of the 500 top privately held companies in America. The growth in the next 2 years will be tremendous: The telecom Industry will be the world’s first Trillion-dollar industry by the end of the year. Our market share is currently less than 1 percent. With only a small increase in market share, we’ll grow tremendously because the industry is growing so rapidly. The same growth is expected for ACN's Internet business. The deregulation that took place in the Telecommunications Industry in the USA over the past 15 years is now taking place in Canada and Europe where we are positioning our business in all of the western European markets. ACN is currently established in the UK, Germany, Holland, Denmark, Finland, and Sweden and is getting itself established in Switzerland, Austria, France, Italy, Spain and the benelux countries within the upcoming months. European entrepreneurs have received ACN with enthusiasm, because the ACN cooperative marketing business model taking advantage of the deregulation of telecommunications has already been tested and proven in the USA. Plus, ACN provides savvy business people the opportunity to immediately position themselves in the multi-billion European telecommunications industry as the big government monopolies are being deregulated, all without any major capital investments simply by utilizing the talents of average people seeking an opportunity to make ! ! ! ! some extra income for themselves. Deregulation of gas & electric utilities is taking place throughout the USA. ACN Energy is currently marketing gas and/or electricity in 43 public utility service areas in New York, New Jersey, Pennsylvania, Ohio, Virginia, Maryland, Washington DC, Georgia, and California. In the past year ACN Energy has become the #1 alternate energy provider for residential service in the state of California and #4 in the nation. ACN Energy is currently being registered with additional Public utility commissions and is positioning as an alternate energy provider in all 50 states as they deregulate. In just the past year, we have acquired over 125,000 gas and electric customers for ACN Energy. ACN will be "bundling" services if the near future, whereby our customers will be given the opportunity to get their long distance, local calling, gas, electricity, Internet, paging, and possibly even wireless or cable TV services all from one source on one bill. The advantage to our customers being that the more services they choose to include in the bundle, the greater discount they receive. Establishing a large representative organization and resultant customer base now, will position you for tremendous increases in residual income when the company markets directly to your customer base by stuffing their bills with notices of new services and greater discounts whenever these new services become available in their area. Basically the company will be doing the work of getting existing customers to try new services, but the ACN representatives will get he commissions, month after month for as long as they're a customer. Studies have shown that for each service included in a b! ! ! ! undle, the customer retention increases by as much as 50 percent. ACN is different in many respects from traditional direct marketing companies. ACN is simply a "customer acquisition" machine, with a win-win-win situation for all. The utility providers get customers with no up-front advertising costs; the customer gets a discount on quality services they have to buy anyway; and we get on-going commissions over and over as long as they remain a customer. Sell it once, and get paid forever. The attraction is threefold: 1) There are no monthly requirements to purchase or sell "products". There is no inventory…..we’re simply in the business of acquiring customers for services that everyone needs and must get every month. 2) No money changes hands when a service is sold…we’re merely giving away discounts on services people already use. They still get their bill from their utility provider. We sell the customer once…and they are on it month after month, year after year. 3) There is a unique opportunity to be awarded stock options because the company is sharing twenty-five percent of its stock over the next 10 years to those representatives who lead the expansion of the business and achieve the position of Regional Vice President (RVP). With the proper work ethic, you too could earn the right to be in the pool of representative who will share in these bonuses. (FYI, $5 million in pre-IPO stock options were awarded to the top 52 representative for 1998......which should be worth about $50 million in the next year after the company goes public) I have owned my own company for the past 15 years, I started in this type of business part time as an exit strategy from the problems with traditional business. I was able to make the transition to full time in just under a year. Now I work out of my home and am available to the family since I am now in full control of my time. We were recruited as part of a team by the founders of ACN to help them in their expansion programs in the USA, Canada and in Europe because of our successful track record in this industry. My sponsors are top producing Regional Vice Presidents Ron and Jan Malezis, who have 15 years experience in the industry and they are sponsored directly by the company. They are two of the nicest and most supportive people you would ever want to meet. Ron was a mortgage broker before he ventured into network marketing and he achieved the top position of RVP with ACN in a record-breaking seven months. Jan was a nurse before getting involved in network marketing and was just recently promoted to ACN's top position of RVP independent of her husband. She has consistently been in the top-10 producers within ACN. Ron and Jan get paid residuals on a customer base of over 150,000 customers and they developed this over the past three years all from their home in the small town of Elizabethton, Tennessee. We also have a massive advertising and lead generation program, as well as an extensive array of recruiting and training tools via telephone, fax, websites, email, audio tape, video tape. All the infrastructure is in place and works. Our Reps just need to use it. Do your homework…and determine: 1) does it make business sense? 2) can you master the business? and..... 3) is it a duplicable process such that anybody can do it? Find out more by calling our recorded Info-line Holland 020-346-3881 Both English and Dutch UK 0171-744-0096 You can also learn about ACN at the corporate web site @ www.acninc.com just click on your countries flag. You can see a complete "Briefing" and even a "Quick Start" training as well as read all the info on the company in your language. You can view our opportunity video by going to our group support website www.acngfg.com. Information about ACN Energy can be found at website www.acnenergy.com For a third-party independent review of the ACN business opportunity, go to website: www.mlmreview.com/mlmreview/ACN003.html ###24-hour recorded Information at (212) 322-6225.####### I'm also inviting you to listen in to our LIVE 20-minute EUROPEAN CONFERENCE CALL Tuesdays and Thursdays 001-580-431-8050 pin 2261# 19:30 UK 20:30 Holland, Sweden, Germany, Denmark 21:30 Finland Wednessdays 001-423-362-4150 pin 9414# 19:15pm UK, 20:15pm Holland, Germany, Sweden, Denmark 21:15pm Finland Just call this number at the above time and punch in the pin when prompted. The call will start shortly therafter and will explain the opportunity, compensation plan, and company information. You will here people from all over Europe, Canada, and the USA on the call. Please be on the call on time. If you're looking for a fun new challenge with a tremendous upside potential with true time leveraged residual income where you can leverage your European connections , but without the inherent risk associated with startup companies, and without giving up what your already doing, give this careful consideration. Please call me after you've reviewed this preliminary information and I'll send you a separate email with an overview of the compensation plan which we can discuss over the phone. Remember to ask me about the special bonuses that make it possible for the average person to earn an extra $2,000 to $3,000 in the next months. Sincerely, Jeff Solochek RUID# 0392753 912-826-1311 From list@netscape.com Sun Mar 26 23:20:25 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13564 for ; Sun, 26 Mar 2000 23:20:24 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id UAA18096; Sun, 26 Mar 2000 20:14:24 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id UAA10448; Sun, 26 Mar 2000 20:19:20 -0800 (PST) Resent-Date: Sun, 26 Mar 2000 20:19:20 -0800 (PST) Message-Id: <4.2.2.20000326221756.00a45670@popmail2.austin.ibm.com> X-Sender: stokes@popmail2.austin.ibm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 26 Mar 2000 22:21:06 -0600 To: "Alexis Bor" , "Richard V Huber" , From: Ellen Stokes Subject: RE: Section 7 of ACL Model draft Cc: , In-Reply-To: References: <200003231453.JAA05335@qsun.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Resent-Message-ID: <"oJnD8.A.-iC.IFu34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Yes, we need to add the text as described below and try to be explicit as possible to what may break. Along similar lines, we agreed to add text to the security considerations section re: access control behavior/interaction with other directory features/functions needs to be discussed in the replication docs. Ellen At 08:59 AM 3/23/00 -0800, Alexis Bor wrote: >I wonder if it needs to be even stronger, perhaps even mentioning that >replication is very likely to break and potentially referrals as well. > >-- Alexis > >Alexis Bor >Directory Works, Inc. >alexis.bor@directoryworks.com >http://www.directoryworks.com > >-----Original Message----- >From: Richard V Huber [mailto:rvh@qsun.mt.att.com] >Sent: Thursday, March 23, 2000 6:54 AM >To: George_Robert_Blakley_III@tivoli.com >Cc: ietf-ldapext@netscape.com; jayhawk@qsun.mt.att.com >Subject: Section 7 of ACL Model draft > >We'd like to summarize our understanding of your email and of Section 7 >to make sure we understand properly. > >We think you are saying that an implementation may provide access >control syntax and semantics beyond those described in the draft. If >they do so, the additional permissions may cause behavior that is >undefined by the LDAP Access Control Model. > >In that case, shouldn't section 7 contain a statement along the lines >of: > > Implementations MAY implement additional access control mechanisms > beyond those described in this standard. However, implementations > that wish to be completely consistent with the standard for > over-the-wire exchange of access control information MUST avoid use > of mechanisms that cannot be expressed using the model defined in > this document. > >Rick Huber >Ryan Moats > > > >Page 21: > > > >TECHNICAL: > > > >We are not sure we understand the purpose of Section 7. Is it just a > >set of high level examples of sequence of operations? > > Section 7 is necessary because LDAP is only a protocol specification, >not > an implementation specification. Implementations are free to build >richer > access control semantics than those specified in the LDAP ACL Model >draft, > and they are also free to provide "proprietary" administrative >interfaces > and protocols which can cause - from the viewpoint of LDAP clients - >"silent" > and even undefined changes in the access control policy. > > Section 7 describes two things: > > (1) The effect of LDAP access control administrative >operations on the > access decision which will subsequently be made by a server >implementation > (that is, the semantics of indidividual ldap ACL admin >operations), and > > (2) under what circumstances administrative operations >performed on the > server implementation but not performed through the LDAP >access control > administration protocol will result in the semantics of >access control > policy being undefined from the viewpoint of an LDAP client. > > >TECHNICAL: > > > > - Datastore Access Control Policy Update Actions: any > > operation implemented by the server which LDAP is > > using as its datastore which changes the access > > policy enforced with respect to attempts to access > > LDAP directory entries and their attributes. > > > >Is this meant to say that the underlying DBMS/filesystem/etc may impose > >policy which overrides the policies expressed by LDAP ACIs? Or is it > >meant to say that non-LDAP means (SQL for an underlying RDBMS > >datastore) may change the data stored in ldapACI attributes? While > >either may be true in general, is it not part of the job of the server > >developer to make sure it doesn't happen? Shouldn't LDAP access > >control be the way that access control policy is expressed for an LDAP > >directory? > > The server is free to support any policy it wants to as long as that > policy is capable of expressing the semantics defined in the LDAP ACL > model draft. The server is responsible for enforcing the >policy which > has been defined. The underlying server's policy *IS* the >LDAP policy; > this draft merely provides an implementation-independent way of > administering the subset of that (underlying) policy which >supports the > LDAP access control semantics. The underlying server >administrator may > make changes in the policy, without using the LDAP protocol and > *perhaps* without having any LDAP privileges. The changes > this administrator makes will be enforced even for LDAP resources. > > We've had a long set of discussions in the working group >about whether >all > LDAP-supporting repositories must support identical policy semantics, >and > the consensus has been that this is not feasible. From list@netscape.com Sun Mar 26 23:38:45 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21679 for ; Sun, 26 Mar 2000 23:38:44 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id UAA00480; Sun, 26 Mar 2000 20:35:00 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id UAA13519; Sun, 26 Mar 2000 20:37:35 -0800 (PST) Resent-Date: Sun, 26 Mar 2000 20:37:35 -0800 (PST) From: Search-Magic@mx.connectfree.co.uk Message-Id: <200003270439.GAA09958@uwm.edu.pl> To: Magic@yahoo.com Date: Sun, 26 Mar 00 21:09:42 EST Subject: Search Engine Secrets Discovered Resent-Message-ID: <"6970-C.A.xSD.OWu34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com "Amazing Search Engine Secrets Discovered By A Computer Illiterate Man in Massachusetts Can Practically Hand You the Top Search Engine Positions...And Add 1,550 Hits a Day to Web Site Overnight!" Dear Friend, Remember the first time you built a web site. You stayed up until the early morning working it out so that it would be just perfect. Then, you were finally done and you sat back and thought, "The World is Good." After that, you've dreamed of all the visitors your site would have, how they would all see your ad and buy your product. Then it hit you, like a ton of bricks....How was anyone going to find your web site? You thought about it for a while and eventually thought you had the answer....submit your site to the search engines. But after you submitted your site you checked it out and couldn't find it. So you waited a few days.....and still nothing You couldn't even find your site if you looked up your own name!!! Then, you got discouraged....after all that hard work NOTHING?!?!? And this is where most people give up..... BUT You Don't Have To... You can achieve top 20 positioning for your web site...and the tens of thousands of hits which come with it...if you have the "Right" information available to you. For Example, did you know: * Infoseek, Alta Vista, and HotBot ban web sites which break their rules (many of the 'insider' techniques most experts recommend will get you banned faster than you could imagine). * Many search engines limit the number of pages you can submit from your domain (some only allow you to submit one page for best results), although we can show you a technique we use to get hundreds of our pages listed. * Yahoo only lists about 1% of the web in their actual directory. To even get your page listed, you may have to use the "backdoor". * Using a so-called search engine submission software that submits your site to 1,000 or more search engines could actually get your page deleted from the major search engines. * 95% of Internet traffic originates at one of the 10 major search engines...If you're not listed, you might as well not even have a web site! * Choosing the most effective 'keywords' is one of the major keys to a successful web site submission...Pick the right ones and your web site will look like Grand Central Station during rush hour! It has taken us over 2 years to learn how to consistently and without fail place any type of web site in the top 20 of the major search engines. Normally, we charge $500 per keyword that you want a top ranking on (plus a monthly fee of $150 for keeping that rank), but we have found we just don't have enough time for all of the clients that desperately need our services... So, we have produced a "Search Engine Magic" interactive CD-ROM that will show you step by step how to create pages which storm the search engines and lay hold to the precious Top 20 positions that millions of people are trying to reach. The Search Engine Magic CD-ROM consists of 21 interactive video and audio lessons that will run on any IBM compatible computer showing you the exact step-by-step process we use to traffic thousands of visitors to our web sites every single day. You will learn: * Three Different Methods We Use to Pick the Best Traffic Producing Keywords for any web site...and how you can have a list of hundreds of popular keywords in only a few minutes. * How Quick and Easy it is to Create 'Doorway' and 'Hallway' pages for the search engines so that you could possibly have thousands of different pages on your domain all pulling in visitors for your site 24 hours a day 7 days a week. * The Secret Weapon that gives you an "Unfair Advantage" over your competition...and virtually assures you will reach the top positions (don't let your competitors hear about this one first or you will be in trouble). * How to Submit Your Pages to the Search Engines and assure that every single one of them gets listed. (if you listen to one of those amateurs tell you how to list your site, you may just get banned for life). * How to Use Pay-Per-Click search engines to receive over 10,000 visitors for only $100 * The Infamous Yahoo backdoor...You can get listed and we will show you the quickest and easiest method for doing so! * And much, much more... Even Better, You'll Get the Same Results For A Fraction of What Everyone Else Had to Pay! Listen: A lot of people all over the world are gonna be furious with me for sharing these "Insider Secrets" with you...especially since you won't be paying even part of what they had to shell out for one top positioning page! That's just too bad. It's been a secret for too long. So, let me tell you what the deal is.... Contact us today using the below Risk-Free Response Form and you can have all of our secrets for only $139.00. This price wouldn't even buy you 10 minutes of our time at our regular submission fees, but you can own the top search engine positions for less than the cost of a few classified ads! You will be learning everything we know about top positioning! That, my friend, is the bargain of a lifetime for a serious Internet marketer like yourself. What’s more, the money is actually irrelevant, because... You Also Get a 90 Day No-Risk 100% Money-Back Guarantee! Here's how it works. Order your personal copy of this CD-ROM, and use it like you own it. If...For any reason or no reason at all, you aren't completely satisfied after 90 days (by which I had over 47 Top 20 positions for my own web site), just send the CD-ROM back in any condition, and I personally guarantee you to get a complete refund of your purchase price. No questions asked. No problems or forms to fill out. No problems at all. PLUS, You Will Also Receive What is Considered to be by most experts as the "Ultimate Bonus!" For the first 50 people who fill out the below response form and send it in, you will also receive UNLIMITED REPRINT AND REPRODUCTION RIGHTS to this CD-ROM for LIFE! I am not going to allow this CD-ROM to become like many of those over-advertised products you see out there, so only the first 50 will receive these rights. This means that you will be able to use this exact same sales letter, copy the CD-ROM yourself, and sell it For $139.00 a copy, one sell will have breaking even. Sell two copies and you will be in profit.This isn't even counting what the CD-ROM package will do for you! Since only 50 people are going to have these rights... you must take action today! Yours in Success, Michael Burgess To rush order this "Search Engine Magic CD-ROM" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM -------------------------------------------------------- Please send to: Your Name: _____________________________________________ Your Address: __________________________________________ Your City: _____________________________________________ State / Zip: ___________________________________________ Your Country: __________________________________________ Phone #: _______________________________________________ (For problems with your order only. No salesmen will call.) Email Address: ___________________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard, American Express and Discover. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $144 ($139 + 5.00 Shipping) Credit Card Number:________________________________ Expiration Date:___________________________ Signature:_________________________ Date:____________________ * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing or mailing my credit card number. (Note your card will be charged for $144.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $144.00! Note - If ordering outside continental US, please add $5 to S&H P.S. If you send in your order and you are not one of the first 50 to receive the Reprint and Reproduction Rights, I will notify you immediately and give you the opportunity to cancel your order. _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ If you have received this message in error and would like to be removed from future mailings, please reply with the word remove in the subject. x _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ From list@netscape.com Mon Mar 27 17:40:55 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25906 for ; Mon, 27 Mar 2000 17:40:55 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id OAA13903; Mon, 27 Mar 2000 14:37:15 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id OAA16337; Mon, 27 Mar 2000 14:39:51 -0800 (PST) Resent-Date: Mon, 27 Mar 2000 14:39:51 -0800 (PST) From: TGullotta@enablesolutions.com Message-ID: <4C71A343EBC6D311B9E1006008360637059DB3@ENABLEMAILSRV> To: ietf-ldapext@netscape.com Subject: acess control to entry attributes Date: Mon, 27 Mar 2000 14:47:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Resent-Message-ID: <"mXWVsD.A._-D.2M-34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I'm new to this mailing list, so I hope I don't sound uneducated. I've been reviewing the access control draft and I keep thinking of a scenario that I don't think is covered. The way our customers usually like the access control is to grant or deny priveledges to attributes within the context of an object class. So, for instance, I would like to give group1 access to all attributes of Person objects within a subtree. Then give group2 only access to attributes cn and sn for Person objects within the same subtree. This is not the same as simply giving them access to all cn and sn attributes, because I don't want them to have those permissions on non-Person objects that use the cn and sn attributes. I know this can be done by placing the ACIs directly on each Person entry, but this seems like a lot of work. I'd like to do if for the subtree per object class. Even beyond that, if the namespace is flat, it would be beneficial to not only use the class as a filter, but maybe a more extensive search criteria. If I'm being clear enough, how would the new specs handle these scenarios? Thanks, Tony Gullotta From list@netscape.com Mon Mar 27 18:59:50 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27387 for ; Mon, 27 Mar 2000 18:59:49 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id PAA04143; Mon, 27 Mar 2000 15:53:45 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id PAA21936; Mon, 27 Mar 2000 15:58:43 -0800 (PST) Resent-Date: Mon, 27 Mar 2000 15:58:43 -0800 (PST) Message-Id: <200003272358.BAA07648@njal.it.su.se> X-Mailer: exmh version 2.0.3 To: stokes@austin.ibm.com cc: ietf-ldapext@netscape.com Subject: kerberos identity syntax Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Mar 2000 01:58:15 +0200 From: Leif Johansson Resent-Message-ID: <"wOq7dC.A.eWF.yW_34"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com I believe that the syntax for kerberosID in the acl draft does not accurately reflect all possible forms of a principal. It would be better to refer to section 7 of RFC 1510 where the various forms of principal names are listed. Note that one possible form of princpal names are directory distinguished names which cannot be matched using caseIgnoreMatch. This would seem to make caseIgnoreMatch a poor choice for aci matchingrule. Cheers, Leif Johansson Phone: +46 8 164541 Department of Mathematics Fax : +46 8 6126717 Stockholm University email: leifj@matematik.su.se From list@netscape.com Mon Mar 27 20:16:14 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28451 for ; Mon, 27 Mar 2000 20:16:13 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id RAA06615; Mon, 27 Mar 2000 17:12:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id RAA21733; Mon, 27 Mar 2000 17:14:46 -0800 (PST) Resent-Date: Mon, 27 Mar 2000 17:14:46 -0800 (PST) Date: Mon, 27 Mar 2000 19:16:31 -0600 From: Mark Wahl Subject: FYI: LDIF approved by IESG Sender: Mark.Wahl@INNOSOFT.COM To: ietf-ldapext@netscape.com Message-id: <14333.954206191@threadgill.austin.innosoft.com> Resent-Message-ID: <"CHn6cC.A.TTF.FeA44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Last week the IESG completed its review of the LDIF spec draft-good-ldap-ldif-06.txt and it will be published as a proposed standard RFC. Mark Wahl, Directory Product Architect Innosoft International, Inc. From list@netscape.com Tue Mar 28 01:50:34 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10478 for ; Tue, 28 Mar 2000 01:50:34 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id WAA06347; Mon, 27 Mar 2000 22:44:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA07031; Mon, 27 Mar 2000 22:49:28 -0800 (PST) Resent-Date: Mon, 27 Mar 2000 22:49:28 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 27 Mar 2000 23:34:45 -0700 From: "Vithalprasad Gaitonde" To: "<" Subject: Ldap packets capture Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"DrCasD.A.jtB.3XF44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA10478 Hi, Do you know of any packet capturing tools on Win95/98/NT/UNIX which can capture LDAP and LDAP with SSL packets and display them. Thanks & Regards Prasad From list@netscape.com Tue Mar 28 12:45:40 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24269 for ; Tue, 28 Mar 2000 12:45:39 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id JAA24153; Tue, 28 Mar 2000 09:41:23 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id JAA24085; Tue, 28 Mar 2000 09:43:54 -0800 (PST) Resent-Date: Tue, 28 Mar 2000 09:43:54 -0800 (PST) Sender: kristian@netscape.com (John Kristian) Message-ID: <38E0EF57.7ED448E2@netscape.com> Date: Tue, 28 Mar 2000 09:43:51 -0800 From: John Kristian Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en-US,en MIME-Version: 1.0 To: Vithalprasad Gaitonde CC: ietf-ldapext@netscape.com, ldap@umich.edu Subject: Re: Ldap packets capture References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"4ZKKHC.A.C4F.Z9O44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Vithalprasad Gaitonde wrote: > Do you know of any packet capturing tools on Win95/98/NT/UNIX which can capture LDAP and LDAP with SSL packets and display them. On Windows NT, `netmon` can analyze LDAP traffic. I don't know whether it supports LDAPS. From list@netscape.com Tue Mar 28 14:22:35 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25272 for ; Tue, 28 Mar 2000 14:22:34 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA04547; Tue, 28 Mar 2000 11:15:34 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id LAA11526; Tue, 28 Mar 2000 11:20:25 -0800 (PST) Resent-Date: Tue, 28 Mar 2000 11:20:25 -0800 (PST) From: djop@mo.com Date: Tue, 28 Mar 2000 21:18:25 +0200 Message-Id: <200003281918.VAA32514@friko.sos.com.pl> X-Authentication-Warning: friko.sos.com.pl: jcvmfl-as-5-ip-21.atlantic.net [209.208.47.52] didn't use HELO protocol To: djop@mo.com Subject: Welcome Online Marketer Resent-Message-ID: <"RKl1bB.A.wzC.4XQ44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Dear Online Marketer, How would you like to quit your job, become your own boss, and build up enough residual income to support yourself for the rest of your life? ..Forget the old-days of Network Marketing where you had to "show the plan" and meet at the local highschool for a "ra-ra" meeting. Our company offers you an opportunity that can be operated from in-front of your computer screen. Imagine the feeling of being able to offer our opportunity and products to millions of people in over 42 Countries and Territories around the World. ..Not only do you have the ability to own a profitable hme-based business which is operating in the United States but you also have the potential of having distributors all over the World. Make a well informed decision which will impact your future today! Simply click below to receive the award-winning website URL--via email promptly: profits@music.com?subject=send-URL You will be glad that you did! With My Warmest Regards, Lynn & PatsyAnn If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. From list@netscape.com Tue Mar 28 23:44:00 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04504 for ; Tue, 28 Mar 2000 23:44:00 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id UAA13711; Tue, 28 Mar 2000 20:37:39 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id UAA09974; Tue, 28 Mar 2000 20:42:30 -0800 (PST) Resent-Date: Tue, 28 Mar 2000 20:42:30 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Tue, 28 Mar 2000 21:09:31 -0700 From: "Ed Reed" To: , Subject: Re: Ldap packets capture Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"AT3Vs.A.kbC.1mY44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA04504 I'm not sure what you're asking for - do you mean to capture and decode the LDAP queries inside the SSL packets? That's what SSL is explicitly designed to NOT allow you to do. You'd need the Diffie-Hellman secrets of the two participants to decode messages sent to each of them. Or, are you just trying to see if the SSL packets look like SSL packets? Anything should do that - tcpdump, Snifferpro, whatever... >>> "Vithalprasad Gaitonde" 3/28/00 4:19:30 PM >>> Hi, Do you know of any packet capturing tools on Win95/98/NT/UNIX which can capture LDAP and LDAP with SSL packets and display them. Thanks & Regards Prasad From list@netscape.com Wed Mar 29 06:22:06 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19109 for ; Wed, 29 Mar 2000 06:22:03 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id DAA07032; Wed, 29 Mar 2000 03:15:33 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id DAA24639; Wed, 29 Mar 2000 03:20:29 -0800 (PST) Resent-Date: Wed, 29 Mar 2000 03:20:29 -0800 (PST) From: mike@yxxybecker2a910.net.netscape.com Date: Wed, 29 Mar 2000 10:28:22 +0900 (KST) Message-Id: <200003290128.KAA23792@ynjc1.yeungnam-c.ac.kr> To: Subject: ADV: Search Engine Registration MIME-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Resent-Message-ID: <"2UTB9C.A.kAG.7be44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Removal instructions below I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 To be removed call: 888-800-6339 X1377 From list@netscape.com Thu Mar 30 02:49:31 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13756 for ; Thu, 30 Mar 2000 02:49:29 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id XAA10998; Wed, 29 Mar 2000 23:43:09 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id XAA10367; Wed, 29 Mar 2000 23:48:10 -0800 (PST) Resent-Date: Wed, 29 Mar 2000 23:48:10 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Thu, 30 Mar 2000 00:46:03 -0700 From: "Ed Reed" To: , Subject: LDAP Subentry and naming Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"tS-JZD.A.6gC.4aw44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13756 During the LDUP discussion of the LDAP Subentry draft the matter of naming attributes came up again, and we need to settle what the draft needs to say. Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory. Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN. The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry. Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above. There might be several possible solutions: 1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named. 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users; 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. Option 1 takes ldapSubEntry further and further away from the X.500 definition. That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted. Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room. At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem? Option 3, it seems to me, should be our fall back if concensus can't be reached quickly - by the end of April, for instance. LDUP doesn't particularly care. That would mean leaving it as it is (I think). Please reply by 23 April with your feelings, if you care. If not, stay tuned to see what develops. I plan to submit this for last call by the end of April, 2000. Regards, Ed Reed From list@netscape.com Thu Mar 30 02:57:33 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13807 for ; Thu, 30 Mar 2000 02:57:33 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id XAA17996; Wed, 29 Mar 2000 23:53:51 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id XAA12820; Wed, 29 Mar 2000 23:56:30 -0800 (PST) Resent-Date: Wed, 29 Mar 2000 23:56:30 -0800 (PST) Message-ID: <009c01bf9a1d$6c08ac20$d4c0d0a9@aus.sun.com> From: "Anil SRIVASTAVA" To: "Ed Reed" , , References: Subject: Re: LDAP Subentry and naming Date: Wed, 29 Mar 2000 23:56:00 -0800 Organization: Sun | Netscape Alliance (http://www.iPlanet.com) 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.00.2919.6600 Disposition-Notification-To: "Anil SRIVASTAVA" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Resent-Message-ID: <"3rGj0.A.CID.tiw44"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit I would vote for option 1. Not too hung up on the name and ldapSE sounds as good as any other. _________ Anil Srivastava anil.srivastava@Eng.Sun.COM ----- Original Message ----- From: "Ed Reed" To: ; Sent: Wednesday, March 29, 2000 11:46 PM Subject: LDAP Subentry and naming During the LDUP discussion of the LDAP Subentry draft the matter of naming attributes came up again, and we need to settle what the draft needs to say. Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory. Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN. The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry. Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above. There might be several possible solutions: 1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named. 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users; 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. Option 1 takes ldapSubEntry further and further away from the X.500 definition. That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted. Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room. At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem? Option 3, it seems to me, should be our fall back if concensus can't be reached quickly - by the end of April, for instance. LDUP doesn't particularly care. That would mean leaving it as it is (I think). Please reply by 23 April with your feelings, if you care. If not, stay tuned to see what develops. I plan to submit this for last call by the end of April, 2000. Regards, Ed Reed From list@netscape.com Thu Mar 30 08:26:27 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16284 for ; Thu, 30 Mar 2000 08:26:26 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id FAA00077; Thu, 30 Mar 2000 05:20:16 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA14339; Thu, 30 Mar 2000 05:25:18 -0800 (PST) Resent-Date: Thu, 30 Mar 2000 05:25:18 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 30 Mar 2000 06:24:36 -0700 From: "Vithalprasad Gaitonde" To: Subject: LDAP Schema Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"TgN-a.A.xfD.9W144"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA16284 Hi, In LDAP can we have two different schemas in the same tree for two different naming contexts Also what is the advantage of turning schema checking off. Thanks & Regards Prasad From list@netscape.com Thu Mar 30 11:16:52 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17471 for ; Thu, 30 Mar 2000 11:16:52 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id IAA15331; Thu, 30 Mar 2000 08:10:42 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id IAA03212; Thu, 30 Mar 2000 08:15:44 -0800 (PST) Resent-Date: Thu, 30 Mar 2000 08:15:44 -0800 (PST) Message-ID: <38E37DF8.EEA7658@netscape.com> Date: Thu, 30 Mar 2000 11:16:56 -0500 From: mcs@netscape.com (Mark C Smith) Organization: iPlanet E-Commerce Solutions X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ed Reed CC: ietf-ldup@imc.org, ietf-ldapext@netscape.com Subject: Re: LDAP Subentry and naming References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hzTb6.A.6x.u2344"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit On the choice of a naming attribute for ldapSubEntry objects, I think the safest choice is to define a new attribute type and say that people MAY use it for naming. I would call it "ldapSubEntryName" and still leave it as an optional ("MAY") type in the objectclass definition in case someone wants to use a different attribute for naming. So... I am basically endorsing option 1 of the three you proposed. -- Mark Smith Directory Product Development / iPlanet E-Commerce Solutions My words are my own, not my employer's. Got LDAP? From list@netscape.com Fri Mar 31 01:02:02 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28409 for ; Fri, 31 Mar 2000 01:02:02 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id VAA28126; Thu, 30 Mar 2000 21:55:40 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id WAA04560; Thu, 30 Mar 2000 22:00:43 -0800 (PST) Resent-Date: Thu, 30 Mar 2000 22:00:43 -0800 (PST) Reply-To: From: "Steven Legg" To: "'Ed Reed'" , , Subject: RE: LDAP Subentry and naming Date: Fri, 31 Mar 2000 16:02:04 +1000 Message-ID: <000601bf9ad6$a4091240$b05508cb@osmium.adacel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal In-Reply-To: Resent-Message-ID: <"k5FBsB.A.bGB.K8D54"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit Ed, There's a fourth option which is to keep CN as the naming attribute but recommend a convention for naming subentries that makes a name clash very unlikely. The convention could be as simple as "the CN of subentries should begin with the text `subentry:' ". I've been habitually using CN=Subschema for the subschema subentry for years and it hasn't been a problem yet so I'm wondering how real a problem this is. Mysterious name clashes are nothing new either since a user could easily (and perhaps more likely) enter a name that clashes with an existing entry that is invisible due to access controls. Any software automatically generating subentries ought to have a backoff strategy trying alternative names until one works, whatever the naming attribute is, so I don't see a problem there. I don't like the idea of leaving the choice of naming attribute to the developers for such an important component of directory operation. All the necessary definitions for LDUP subentries should be widely known. Regards, Steven -----Original Message----- From: owner-ietf-ldup@mail.imc.org [mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Ed Reed Sent: Thursday, 30 March 2000 17:46 To: ietf-ldup@imc.org; ietf-ldapext@netscape.com Subject: LDAP Subentry and naming During the LDUP discussion of the LDAP Subentry draft the matter of naming attributes came up again, and we need to settle what the draft needs to say. Mark Wahl notes that some vendors have objected that CN is a poor choice for naming ldapSubEntry entries in the directory. Since they'll not be visible to users and administrators, unless specifically requested, they'll be in a position to cause mysterious naming clashes with other entries named by CN. The example being that if an ldapSubEntry exists with the name CN=fred, and an administrator attempts to create a person with CN=fred, the administrator will likely get a "duplicate entry name" like error (there's already an entry with the name CN=fred), but the administrator won't see the subentry. Since many ldapSubEntry entries will be created automatically by software in the operation of the directory, it's reasonable to name them something that won't cause such mysterious seeming errors as the one described above. There might be several possible solutions: 1) define a new attribute, say ldapSE, of type DirectoryString, with which ldapSubEntry entries may be named. 2) leave supplying of the naming attribute to developers who use an ldapSubEntry class to hold their information - this seems troublesome, as the ldapSubEntry class is a STRUCTURAL class, meaning that SOME naming rule is likely to be required, which could get in the way of subsequent users; 3) punt, and leave it the way X.500 defines it, and leave experiments surrounding solving this problem to future innovators. Option 1 takes ldapSubEntry further and further away from the X.500 definition. That's not a problem to the author, if that's desireable because we've learned a change to the X.500 model is warranted. Option 2 seems, to me, to take us toward makeing ldapSubEntry an AUXILIARY class itself, instead of a STRUCTURAL class, but I confess I don't understand the nuances being navigated by the X.500 vendors in the room. At any event, this would be an even more serious diversion from the original X.500 model Subentry class definition, wouldn't it? - is that a problem? Option 3, it seems to me, should be our fall back if concensus can't be reached quickly - by the end of April, for instance. LDUP doesn't particularly care. That would mean leaving it as it is (I think). Please reply by 23 April with your feelings, if you care. If not, stay tuned to see what develops. I plan to submit this for last call by the end of April, 2000. Regards, Ed Reed From list@netscape.com Fri Mar 31 08:26:18 2000 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13370 for ; Fri, 31 Mar 2000 08:26:18 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id FAA11874; Fri, 31 Mar 2000 05:22:29 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id FAA14436; Fri, 31 Mar 2000 05:25:09 -0800 (PST) Resent-Date: Fri, 31 Mar 2000 05:25:09 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 31 Mar 2000 06:24:10 -0700 From: "Vithalprasad Gaitonde" To: Subject: Re: Ldap packets capture Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Resent-Message-ID: <"GV4PiC.A.QhD.0cK54"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA13370 Hi, Thanks a lot for all the replies. By decoding SSL packets I didnt mean that we look into the appication data flowing over SSL. But at least the Server and Cient Hello and the trusted certificate exchange could be seen. Do u know of any tool on Winodws or Unix that can do that. Also can Netpro be downloaded from a site. pls let me know. Thanks & Regards Prasad >>> "Ed Reed" 03/29/00 10:12AM >>> I'm not sure what you're asking for - do you mean to capture and decode the LDAP queries inside the SSL packets? That's what SSL is explicitly designed to NOT allow you to do. You'd need the Diffie-Hellman secrets of the two participants to decode messages sent to each of them. Or, are you just trying to see if the SSL packets look like SSL packets? Anything should do that - tcpdump, Snifferpro, whatever... >>> "Vithalprasad Gaitonde" 3/28/00 4:19:30 PM >>> Hi, Do you know of any packet capturing tools on Win95/98/NT/UNIX which can capture LDAP and LDAP with SSL packets and display them. Thanks & Regards Prasad From list@netscape.com Fri Mar 31 21:40:40 2000 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21020 for ; Fri, 31 Mar 2000 21:40:39 -0500 (EST) Received: from aka.mcom.com (aka.mcom.com [205.217.237.180]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA00021; Fri, 31 Mar 2000 18:34:21 -0800 (PST) Received: (from list@localhost) by aka.mcom.com (8.8.5/8.7.3) id SAA02301; Fri, 31 Mar 2000 18:39:26 -0800 (PST) Resent-Date: Fri, 31 Mar 2000 18:39:26 -0800 (PST) Date: Fri, 31 Mar 2000 18:09:01 -0800 (PST) Message-Id: <200004010209.SAA23842@ywing.netscape.com> From: moneyontheweb@DAIG.beer.com, oceanofwealth@mail.com To: @netscape.com Subject: Earn at Least $5,000?Week. FREE 32 Page Booklet! X-Reply-To: oceanofwealth@getresponse.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_4i4q.A.ti.cFW54"@glacier> Resent-From: ietf-ldapext@netscape.com X-Mailing-List: X-Loop: ietf-ldapext@netscape.com Precedence: list Resent-Sender: ietf-ldapext-request@netscape.com Content-Transfer-Encoding: 7bit You can earn more than $5,000 a week within 28 days with our amazing new Internet Marketing program. InfoShare is a breakthrough Web Marketing concept that cannot fail. Find out how to earn more money than you ever dreamed possible. Download our FREE 32 page booklet "Inside Secrets to Wealth on the Web" NOW! Just hit reply and type "Send the Book" in the subject line, the auto-responder will forward it immediately