From hyc@highlandsun.com Wed Aug 5 04:15:42 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8723A691A for ; Wed, 5 Aug 2009 04:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alHPpN9YolZ8 for ; Wed, 5 Aug 2009 04:15:40 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id E1BBB3A68E3 for ; Wed, 5 Aug 2009 04:15:40 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 63C0F83EFA for ; Wed, 5 Aug 2009 07:15:43 -0400 (EDT) Message-ID: <4A7969DD.4090903@highlandsun.com> Date: Wed, 05 Aug 2009 04:15:41 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: ldapext@ietf.org References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> In-Reply-To: <4A52986B.80001@highlandsun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 11:15:42 -0000 Howard Chu wrote: > And also an extended op "ExternalBind" for allowing external authentication > providers to interact with the existing policy. I.e., this op will supply an > LDAP username and a success/fail code to the directory server, and the server > will execute the policy mechanisms accordingly. (E.g., if a Fail code is > supplied then the failure time and any relevant lockouts are recorded.) Thinking about this some more, I don't think a new exop is the right approach. Instead, I would use a new ppolicy control which can be attached to a Search request. It would only be valid for searches of Base scope. It would result in a ppolicy response control being attached to the search entry that fulfills the search request. This would allow an external authentication mechanism to discover if the account is already locked, password is expired, etc. The response control would also include an opaque cookie. We would also define a new ppolicy control which can be attached to a Simple Bind request. This control would carry the cookie from the previous response control, and a boolean success/fail value. If the cookie is valid, the credentials of the Bind request will be ignored and the boolean success/fail code is used to update the ppolicy state for the specified user. At this point I'm preparing a new draft of the behera-ppolicy document with the several additions I've mentioned. I am also preparing a new revision of the RFC2307 schema, and a draft of a Kerberos 5 schema. Both of these latter documents will depend on the ppolicy draft. I plan to post these in the next couple of days. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From Kurt.Zeilenga@Isode.com Thu Aug 6 09:27:46 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42FBE3A6DF5 for ; Thu, 6 Aug 2009 09:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwpIMPzAMyvs for ; Thu, 6 Aug 2009 09:27:45 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 534763A6DCC for ; Thu, 6 Aug 2009 09:27:45 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 6 Aug 2009 17:27:47 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <7056861A-C18F-44B5-A4A9-251D6C13BE36@Isode.com> From: Kurt Zeilenga To: Howard Chu In-Reply-To: <4A7969DD.4090903@highlandsun.com> Date: Thu, 6 Aug 2009 09:27:44 -0700 References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> <4A7969DD.4090903@highlandsun.com> X-Mailer: Apple Mail (2.936) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 16:27:46 -0000 On Aug 5, 2009, at 4:15 AM, Howard Chu wrote: > Howard Chu wrote: >> And also an extended op "ExternalBind" for allowing external >> authentication >> providers to interact with the existing policy. I.e., this op will >> supply an >> LDAP username and a success/fail code to the directory server, and >> the server >> will execute the policy mechanisms accordingly. (E.g., if a Fail >> code is >> supplied then the failure time and any relevant lockouts are >> recorded.) > > Thinking about this some more, I don't think a new exop is the right > approach. Instead, I would use a new ppolicy control which can be > attached to a Search request. I suggest that such new protocol mechanisms, whether they be exop based or control based, be specified separately from the Password Policy document. While they may be related, it would seem reasonable that an implementation might one to implement one but not the other. Modularization is a good thing. Here I think it will aide in getting security right. Looking forward to discussing the devils in your details (I-Ds)... -- Kurt From hyc@highlandsun.com Fri Aug 7 16:44:38 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5013A67D2 for ; Fri, 7 Aug 2009 16:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEYqFi9sLrWT for ; Fri, 7 Aug 2009 16:44:36 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 22D8F3A6875 for ; Fri, 7 Aug 2009 16:44:08 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 14F8183EFA for ; Fri, 7 Aug 2009 19:44:10 -0400 (EDT) Message-ID: <4A7CBC4A.2070106@highlandsun.com> Date: Fri, 07 Aug 2009 16:44:10 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ldapext] RFC4523 certificateMatch subjectAltName X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2009 23:44:38 -0000 Why was the subjectAltName match only defined with the AltNameType as an argument? This makes it rather useless for actually matching things, if you can't specify a corresponding value. It seems to be unique among the CertificateAssertion options in that it doesn't permit a value, while all the other options do. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Sat Aug 8 20:21:22 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881C23A6933 for ; Sat, 8 Aug 2009 20:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvauZCQbQaFA for ; Sat, 8 Aug 2009 20:21:21 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 68DF13A68DB for ; Sat, 8 Aug 2009 20:21:21 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 8896A83EFA; Sat, 8 Aug 2009 23:21:24 -0400 (EDT) Message-ID: <4A7E40B3.5050005@highlandsun.com> Date: Sat, 08 Aug 2009 20:21:23 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Jim Sermersheim References: <42F209AD0200001C000383DC@lyle.provo.novell.com> In-Reply-To: <42F209AD0200001C000383DC@lyle.provo.novell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Duane Buss , Hal Henderson , "Kurt D. Zeilenga" , Tammy Green , ldapext@ietf.org Subject: Re: [ldapext] Splitting Password Policy X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 03:21:22 -0000 Hm, just tripped over this again in my Inbox. Was there any progress on this work? I've just now finished reformatting draft-behera-...-09 into XML and updating it to reference RFC4511-4517, in preparation for making further additions. But if there's already been work done on splitting the document, I'd rather continue from there. IMO, we really do need a spec for "Login Policy" not just password policy, and we need to expose it such that other mechanisms (e.g. Kerberos, SASL) can utilize it consistently with simple requests (i.e., without having to reimplement the guts of the policy themselves). Likewise, in my edit of RFC2307 I am recommending that LDAP password policy be used instead of the shadowAccount schema for login authorization. Jim Sermersheim wrote: > After talking this over, we've decided to try both. In other words, > splitting the document into four different drafts like this: > 1) LDAP authentication control for password policy > 2) LDAP update control for password policy > 3) LDAP password-based authentication policy > 4) LDAP password update policy > #1 and #2 will essentially define the protocol elements and the > various policy decisions to be made. > #3 and #4 will define the schema elements and how to use them to > implement the policy decisions defined in #1 and #2. > We can probably find better names than the ones I've jotted down here. > > >>> "Kurt D. Zeilenga" 10/26/04 6:21:25 PM >>> > Just a thought, but it might also be useful to split the > protocol elements from the schema elements. The protocol > controls could be genericized to support expiration of > other kinds of credentials. > > At 09:00 AM 10/26/2004, Jim Sermersheim wrote: > >All, > > > >Speaking on behalf of some people on the CC list, it is seen as > desirable to place password update policy in one specification, and > place password use policy in another specification. > > > >This started as an act of associating password use policy (such as > intruder detection policy) with login policy (such as allowable login > times, addresses, etc). > > > >It then diverged from that and ended up being described as: Password > policy is policy that applies only to simple bind passwords. Login > policy involves policy that can be applied to *any* kind of credentials. > > > >My argument was that policy like password expiration (while enforced > at authN time) is intimately tied to password updates. Thus, if we > were to split this into two I-Ds, there would be some amount of cross > referencing, and cross requirements (password expiration would require > actions during password update). > > > >I know some people in the community have asked for more "login > policy" type things to be added to the I-D, and we've pushed against > adding those. > > > >What are other's feelings in this area? (Tammy, Duane, Hal, feel free > to clarify these positions). > > > >Jim > >_______________________________________________ > >Ldapext mailing list > >_ Ldapext@ietf.org _ > >_ https://www1.ietf.org/mailman/listinfo/ldapext_ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Sun Aug 9 01:04:17 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDBCF3A6AC4 for ; Sun, 9 Aug 2009 01:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w60Y4NpaLvRs for ; Sun, 9 Aug 2009 01:04:16 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 30DFB3A6BE0 for ; Sun, 9 Aug 2009 01:04:11 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 7914283EFA; Sun, 9 Aug 2009 04:04:14 -0400 (EDT) Message-ID: <4A7E82FE.2090700@highlandsun.com> Date: Sun, 09 Aug 2009 01:04:14 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Kurt Zeilenga References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> <4A7969DD.4090903@highlandsun.com> <7056861A-C18F-44B5-A4A9-251D6C13BE36@Isode.com> In-Reply-To: <7056861A-C18F-44B5-A4A9-251D6C13BE36@Isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 08:04:18 -0000 Kurt Zeilenga wrote: > > On Aug 5, 2009, at 4:15 AM, Howard Chu wrote: >> Thinking about this some more, I don't think a new exop is the right >> approach. Instead, I would use a new ppolicy control which can be >> attached to a Search request. > I suggest that such new protocol mechanisms, whether they be exop > based or control based, be specified separately from the Password > Policy document. While they may be related, it would seem reasonable > that an implementation might one to implement one but not the other. > Modularization is a good thing. Here I think it will aide in getting > security right. > Looking forward to discussing the devils in your details (I-Ds)... After further thought, I didn't add anything on this front at all. I've submitted a new draft, the announcement should be going out soon. https://datatracker.ietf.org/idst/status.cgi?passed_filename=draft-behera-ldap-password-policy Summarizing the differences from version 09: 1) changed explicit reference to user lockout in the Abstract to "deter password guessing attacks". In general, we want to deprecate explicit lockouts and encourage other mechanisms, to avoid DoS. 2) Updated various references: RFC2251 -> RFC4511, RFC222 -> RFC4422, etc. 3) New section 4.1.1 (perhaps I should have appended instead of inserting and causing the others to be renumbered. Oh well.) "Password Validity Policy" describes mechanisms for enabling/disabling an account based on absolute start time, end time, and idle time since last successful login. This also provides a more straightforward means of locking out an account without overloading the pwdAccountLockedTime attribute. 4) Added delays for failed authentication to "Password Guessing Limit" section (now 4.1.2, was 4.1.1). 5) In 5.1, added pwdMaxLength, pwdGraceExpiry, pwdMinDelay, pwdMaxDelay, and pwdMaxIdle policy attributes. Their full descriptions are in subsequent sections. 6) In 5.3, added pwdStartTime, pwdEndTime, pwdLastSuccess state attributes. 7) tweaked the comments for the pwdHistory syntax; couldn't use xref inside a block so moved the references out of the comments. 8) In 7.1 added new lockout conditions based on pwdStartTime, pwdEndTime, and pwdMaxIdle + pwdLastSuccess. 9) In 7.4 (oops. forgot to take pwdGraceExpiry into account on this edit.) 10) In 7.6, renamed section from "Intruder Detection Check" to "Intruder Lockout Check", added new section "Intruder Delay Check". 11) In Password Too Young Check (now 7.8, was 7.7) added exception to allow changing password if the Must Change check returned true. 12) In 8., note that if a single password value is stored in multiple formats simultaneously, it still counts as just a single password value. It's common when centralizing multiple systems (SASL, Samba, Kerberos, NSS) into LDAP to need to have the password in multiple forms. They are all equivalent and are always changed simultaneously, so they are effectively only one password. 13) In 8.1.2.1 update the pwdLastSuccess attribute on successful authentication. In actual implementations I would make this optional, based on whether the pwdMaxIdle policy is configured or not. 14) Fixed a format/indent error, 8.1.2.5 and following are now 8.1.3 15) 8.1.2.5.2 "Lock on intruder detection" is now 8.1.3.2 "Handle Intruder Detection" where Lock is only one of the possible actions, Delay is the other possibility. 16) 9.5 Other Operations - also allow accountLocked result. This allows Search+ppolicy control to be used by SASL etc., instead of the ExternalBind stuff I mentioned in previous emails. 17) In 10. Administration, note that only one policy may be in effect for an attribute of an entry. If multiple policies overlap, the behavior is undefined. 18) In 11. Replication, replace "MUST be replicated" with "SHOULD be replicated", noting there are situations where replication of certain policy state attributes is not desired. 19) Author's Addresses - I know this is messed up; Jim Sermersheim is no longer at Novell, and I probably screwed up the format of Ludovic's address. Things I didn't fix in this revision: There are still several TODO sections from 09 which I didn't touch. We've talked about more explicit pwdQualityRules, I haven't added any definitions for that yet. Responses to draft-zeilenga-ldap-passwords Appendix A: intruder detection check: added language to discourage use of this feature, added login delay policy. pwdAccountLock overloading: added other mechanisms for explicit lockout. pwdGrace use: I added pwdGraceExpiry to the policy, but forgot to incorporate it in the grace check section. Will add that shortly. pwdAllowUserChange: I left this alone; we've already got it and it doesn't seem worth the trouble to delete it. The language already indicates it's only needed if the server doesn't already support access control, so in all likelihood it will never be used. If nobody speaks up and says "we can't live without this" I guess we can drop it from the next revision. protocol extensions: Basically left this alone. application to other operations: Basically left this alone. It's useful for external authentication mechanisms to interact with the policy. require DSA-generated passwords: I didn't add this on this revision. Probably should add it on the next edit. pwdMaxLength: added. pwdHistory: I didn't add the time-based restriction. I think fixing the password-too-young check addresses the main problem, and I think that only using a time-based restriction may allow the history to grow without bound. pwdHistory storage: I'm neutral on this; we already have it and it doesn't seem to be doing any harm, so again, more trouble than it's worth to delete it. I agree that it's DSA-specific, but the current definition works and it's likely that any DSA-specific implementation is going to look much like this anyway. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Sun Aug 9 14:41:42 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDE03A6935 for ; Sun, 9 Aug 2009 14:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtECTN67jrSq for ; Sun, 9 Aug 2009 14:41:41 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 418403A680B for ; Sun, 9 Aug 2009 14:41:40 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id CD4C810F96 for ; Sun, 9 Aug 2009 17:41:42 -0400 (EDT) Message-ID: <4A7F4296.2070807@highlandsun.com> Date: Sun, 09 Aug 2009 14:41:42 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [ldapext] Fwd: Manual Post Requested for draft-howard-rfc2307bis X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2009 21:41:42 -0000 I guess this will show up in a couple of days. Major differences from version 01 of the rfc2307bis document: 1) Added host and hostos attribute options to allow system-specific values for attributes when needed. (E.g. to accommodate different homeDirectory locations on various machines.) 2) Added integerOrderingMatch ORDERING rules to attributes with integer syntax. Admins frequently need to search for things like (uidNumber>=1000) and the lack of the ORDERING rules was a great impediment. 3) Added new groupOfMembers structural objectclass with "member" as an optional attribute, to support groups with zero members. This class should be used whenever a structural group class is needed. The use of groupOfUniqueNames (and groupOfNames) is deprecated. 4) Added references to PAM and LDAP Password Policy. The use of LDAP information for authentication via NSS mechanisms is deprecated. The use of shadowAccount information for password policy is deprecated. 5) Added Naming Considerations section with caveats re: user and group naming. -------- Original Message -------- Subject: Manual Post Requested for draft-howard-rfc2307bis Date: Sun, 9 Aug 2009 14:31:24 -0700 (PDT) From: IETF I-D Submission Tool To: internet-drafts@ietf.org CC: hyc@symas.com,lukeh@padl.com Manual Posting Requested for following Internet-Draft: I-D Submission Tool URL: https://datatracker.ietf.org/idst/status.cgi?submission_id=17311 Filename: draft-howard-rfc2307bis Version: 02 Staging URL: http://www.ietf.org/staging/draft-howard-rfc2307bis-02.txt Title: An Approach for Using LDAP as a Network Information Service Creation_date: 2009-08-09 WG ID: Indvidual Submission Number_of_pages: 32 Abstract: This document describes a mechanism for mapping entities related to TCP/IP and the UNIX system [UNIX] into [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4511]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. Submitter: Howard Chu (hyc@symas.com) Author(s): Luke Howard, lukeh@padl.com Howard Chu, hyc@symas.com Comment: The form grabbed too much text for the Abstract, trimmed it back down to the proper text. From hyc@highlandsun.com Mon Aug 10 20:19:48 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCFC3A6F15 for ; Mon, 10 Aug 2009 20:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV0-rlx0auyY for ; Mon, 10 Aug 2009 20:19:47 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 52FCB3A6F5C for ; Mon, 10 Aug 2009 20:19:32 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 8D52F10F96 for ; Mon, 10 Aug 2009 23:19:35 -0400 (EDT) Message-ID: <4A80E346.90701@highlandsun.com> Date: Mon, 10 Aug 2009 20:19:34 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090809 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: ldapext@ietf.org References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> <4A7969DD.4090903@highlandsun.com> <7056861A-C18F-44B5-A4A9-251D6C13BE36@Isode.com> <4A7E82FE.2090700@highlandsun.com> In-Reply-To: <4A7E82FE.2090700@highlandsun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 03:19:48 -0000 Howard Chu wrote: > 9) In 7.4 (oops. forgot to take pwdGraceExpiry into account on this edit.) Fixed, will be in next draft. > 12) In 8., note that if a single password value is stored in multiple formats > simultaneously, it still counts as just a single password value. It's common > when centralizing multiple systems (SASL, Samba, Kerberos, NSS) into LDAP to > need to have the password in multiple forms. They are all equivalent and are > always changed simultaneously, so they are effectively only one password. Equivalent text probably belongs in 4.3. > 16) 9.5 Other Operations - also allow accountLocked result. This allows > Search+ppolicy control to be used by SASL etc., instead of the ExternalBind > stuff I mentioned in previous emails. This appears to be a mistake, I'm reverting this to the 09 version. > There are still several TODO sections from 09 which I didn't touch. TODOs: do we need to have configurable backoff algorithms for login delays? seems like overkill. password safe modification, intruder detection - one possibility is to force the session to immediately terminate on failure. That then accomplishes the aim of requiring users to authenticate first. pwdCheckQuality, checking during authentication. Sounds like a good idea; should it be done always, only when the stored password is hashed, or as a configurable choice? The result should be that pwdReset is effectively set when the verification succeeds. advertisement and discovery - the control should be advertised in supportedControls in the rootDSE, what else needs to be said? administrativeRole - will use another OID under the current arc. ppolicy and replication - I think there are enough caveats in here now. IANA considerations - I've filled these in according to RFC4520. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From jim@willeke.com Tue Aug 11 02:35:13 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1796B3A7030 for ; Tue, 11 Aug 2009 02:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57qM13NjsK2e for ; Tue, 11 Aug 2009 02:35:11 -0700 (PDT) Received: from mail-gx0-f213.google.com (mail-gx0-f213.google.com [209.85.217.213]) by core3.amsl.com (Postfix) with ESMTP id A505F3A7035 for ; Tue, 11 Aug 2009 02:34:43 -0700 (PDT) Received: by gxk9 with SMTP id 9so4925681gxk.13 for ; Tue, 11 Aug 2009 02:34:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.102.5 with SMTP id e5mr10317065ybm.123.1249983285636; Tue, 11 Aug 2009 02:34:45 -0700 (PDT) In-Reply-To: <4A80E346.90701@highlandsun.com> References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> <4A7969DD.4090903@highlandsun.com> <7056861A-C18F-44B5-A4A9-251D6C13BE36@Isode.com> <4A7E82FE.2090700@highlandsun.com> <4A80E346.90701@highlandsun.com> Date: Tue, 11 Aug 2009 05:34:45 -0400 Message-ID: From: Jim Willeke To: Howard Chu , ldapext@ietf.org Content-Type: multipart/alternative; boundary=0015174beb76b72f520470da69e0 Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2009 09:35:13 -0000 --0015174beb76b72f520470da69e0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit pwdCheckQuality Enforcement, I think, must be a choice on Auth and on all operations. There are conditions where this could force everyone who authenticates to change their password in a single day. With 1,000's or 1,000,000's of users, an organization would be overwhelmed. Some conditions I could think of are: - Change to the password policy - Transitioning to a new LDAP server or version. Where the "old" LDAP server did not use the or enforce the password policy. - Synchronization engines used to sync a password from a system whith a weaker policy to a system with a stronger policy. It sometimes difficult to match password policys between different vendors/versions of LDAP servers. -jim Jim Willeke On Mon, Aug 10, 2009 at 11:19 PM, Howard Chu wrote: > Howard Chu wrote: > >> 9) In 7.4 (oops. forgot to take pwdGraceExpiry into account on this edit.) >> > > Fixed, will be in next draft. > > 12) In 8., note that if a single password value is stored in multiple >> formats >> simultaneously, it still counts as just a single password value. It's >> common >> when centralizing multiple systems (SASL, Samba, Kerberos, NSS) into LDAP >> to >> need to have the password in multiple forms. They are all equivalent and >> are >> always changed simultaneously, so they are effectively only one password. >> > > Equivalent text probably belongs in 4.3. > > 16) 9.5 Other Operations - also allow accountLocked result. This allows >> Search+ppolicy control to be used by SASL etc., instead of the >> ExternalBind >> stuff I mentioned in previous emails. >> > > This appears to be a mistake, I'm reverting this to the 09 version. > > There are still several TODO sections from 09 which I didn't touch. >> > > TODOs: > do we need to have configurable backoff algorithms for login delays? seems > like overkill. > > password safe modification, intruder detection - one possibility is to > force the session to immediately terminate on failure. That then > accomplishes the aim of requiring users to authenticate first. > > pwdCheckQuality, checking during authentication. Sounds like a good idea; > should it be done always, only when the stored password is hashed, or as a > configurable choice? The result should be that pwdReset is effectively set > when the verification succeeds. > > advertisement and discovery - the control should be advertised in > supportedControls in the rootDSE, what else needs to be said? > > administrativeRole - will use another OID under the current arc. > > ppolicy and replication - I think there are enough caveats in here now. > > IANA considerations - I've filled these in according to RFC4520. > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www.ietf.org/mailman/listinfo/ldapext > --0015174beb76b72f520470da69e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0pwdCheckQuality Enforcement, I think, must be a choice on Auth and on a= ll operations.

There are conditions where this could force everyone = who authenticates to change their password in a single day. With 1,000'= s or 1,000,000's of users, an organization would be overwhelmed.

Some conditions I could think of are:
- Change to the password polic= y
- Transitioning to a new LDAP server or version. Where the "old&q= uot; LDAP server did not use the or enforce the password policy.
- Synch= ronization engines used to sync a password from a system whith a weaker pol= icy to a system with a stronger policy. It sometimes difficult to match pas= sword policys between different vendors/versions of LDAP servers.

-jim
Jim Willeke


On Mon, Aug 10, 2009 at 11:19 PM, Howard= Chu <hyc@highl= andsun.com> wrote:
Howard Chu wrote:
9) In 7.4 (oops. forgot to take pwdGraceExpiry into account on this edit.)<= br>

Fixed, will be in next draft.


12) In 8., note that if a single password value is stored in multiple forma= ts
simultaneously, it still counts as just a single password value. It's c= ommon
when centralizing multiple systems (SASL, Samba, Kerberos, NSS) into LDAP t= o
need to have the password in multiple forms. They are all equivalent and ar= e
always changed simultaneously, so they are effectively only one password.

Equivalent text probably belongs in 4.3.


16) 9.5 Other Operations - also allow accountLocked result. This allows
Search+ppolicy control to be used by SASL etc., instead of the ExternalBind=
stuff I mentioned in previous emails.

This appears to be a mistake, I'm reverting this to the 09 version.

There are still several TODO sections from 09 which I didn't touch.

TODOs:
=A0do we need to have configurable backoff algorithms for login delays? se= ems like overkill.

=A0password safe modification, intruder detection - one possibility is to = force the session to immediately terminate on failure. That then accomplish= es the aim of requiring users to authenticate first.

=A0pwdCheckQuality, checking during authentication. Sounds like a good ide= a; should it be done always, only when the stored password is hashed, or as= a configurable choice? The result should be that pwdReset is effectively s= et when the verification succeeds.

=A0advertisement and discovery - the control should be advertised in suppo= rtedControls in the rootDSE, what else needs to be said?

=A0administrativeRole - will use another OID under the current arc.

=A0ppolicy and replication - I think there are enough caveats in here now.=

=A0IANA considerations - I've filled these in according to RFC4520.


--
=A0-- Howard Chu
=A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 http://www.symas.com
=A0Director, Highland Sun =A0 =A0 http://highlandsun.com/hyc/
=A0Chief Architect, OpenLDAP =A0http://www.openldap.org/project/
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/ldapext

--0015174beb76b72f520470da69e0-- From michael@stroeder.com Fri Aug 14 12:31:35 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB483A6A2F for ; Fri, 14 Aug 2009 12:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3IxTzoXw6U0 for ; Fri, 14 Aug 2009 12:31:35 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id A00F53A6A21 for ; Fri, 14 Aug 2009 12:31:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 8D4F94E164; Fri, 14 Aug 2009 21:31:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrw25eVXpCIW; Fri, 14 Aug 2009 21:31:31 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 2D0CF4E173; Fri, 14 Aug 2009 21:31:28 +0200 (CEST) Message-ID: <4A85976A.6050807@stroeder.com> Date: Fri, 14 Aug 2009 18:57:14 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090606 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Howard Chu References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> <4A7969DD.4090903@highlandsun.com> In-Reply-To: <4A7969DD.4090903@highlandsun.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 19:31:35 -0000 Howard Chu wrote: > Howard Chu wrote: >> And also an extended op "ExternalBind" for allowing external >> authentication providers to interact with the existing policy. I.e., this >> op will supply an LDAP username and a success/fail code to the directory >> server, and the server will execute the policy mechanisms accordingly. >> (E.g., if a Fail code is supplied then the failure time and any relevant >> lockouts are recorded.) > > Thinking about this some more, I don't think a new exop is the right > approach. Instead, I would use a new ppolicy control which can be > attached to a Search request. It would only be valid for searches of > Base scope. It would result in a ppolicy response control being attached > to the search entry that fulfills the search request. This would allow > an external authentication mechanism to discover if the account is > already locked, password is expired, etc. The response control would > also include an opaque cookie. Thinking in this direction a bit further I wonder how requests with Proxy Authz control attached should be handled in case of (temporarily) locked accounts. > We would also define a new ppolicy control which can be attached to a > Simple Bind request. This control would carry the cookie from the > previous response control, and a boolean success/fail value. If the > cookie is valid, the credentials of the Bind request will be ignored and > the boolean success/fail code is used to update the ppolicy state for > the specified user. What's the use-case for that? > At this point I'm preparing a new draft of the behera-ppolicy document > with the several additions I've mentioned. I am also preparing a new > revision of the RFC2307 schema, and a draft of a Kerberos 5 schema. Both > of these latter documents will depend on the ppolicy draft. I plan to > post these in the next couple of days. This all sounds very reasonable. Ciao, Michael. From hyc@highlandsun.com Fri Aug 14 14:28:37 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531373A69EC for ; Fri, 14 Aug 2009 14:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpgwQcY7goIS for ; Fri, 14 Aug 2009 14:28:36 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 4A4343A68FF for ; Fri, 14 Aug 2009 14:28:36 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 361C010F96; Fri, 14 Aug 2009 17:28:39 -0400 (EDT) Message-ID: <4A85D706.1050601@highlandsun.com> Date: Fri, 14 Aug 2009 14:28:38 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090809 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> <4A7969DD.4090903@highlandsun.com> <4A85976A.6050807@stroeder.com> In-Reply-To: <4A85976A.6050807@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2009 21:28:37 -0000 Michael Ströder wrote: > Howard Chu wrote: >> Howard Chu wrote: >>> And also an extended op "ExternalBind" for allowing external >>> authentication providers to interact with the existing policy. I.e., this >>> op will supply an LDAP username and a success/fail code to the directory >>> server, and the server will execute the policy mechanisms accordingly. >>> (E.g., if a Fail code is supplied then the failure time and any relevant >>> lockouts are recorded.) >> >> Thinking about this some more, I don't think a new exop is the right >> approach. Instead, I would use a new ppolicy control which can be >> attached to a Search request. It would only be valid for searches of >> Base scope. It would result in a ppolicy response control being attached >> to the search entry that fulfills the search request. This would allow >> an external authentication mechanism to discover if the account is >> already locked, password is expired, etc. The response control would >> also include an opaque cookie. > > Thinking in this direction a bit further I wonder how requests with Proxy > Authz control attached should be handled in case of (temporarily) locked accounts. > >> We would also define a new ppolicy control which can be attached to a >> Simple Bind request. This control would carry the cookie from the >> previous response control, and a boolean success/fail value. If the >> cookie is valid, the credentials of the Bind request will be ignored and >> the boolean success/fail code is used to update the ppolicy state for >> the specified user. > > What's the use-case for that? I have already dropped this line of thought, so it's a moot point now. I was thinking of SASL, Kerberos, and Samba ("external authentication agents"), which each can use LDAP as an authentication store, but perform the actual credential verification themselves. I wanted the ppolicy control attached to the Search request, to indicate that an authentication was being started. And I wanted the control to be attached to a Bind request, to allow the external agent to tell LDAP what the outcome of the authentication attempt was. This way the directory server can continue to maintain all the policy state thru the Bind mechanism. The external agent cannot simply issue an LDAP Simple Bind because they won't have the plaintext credentials on hand. I wanted a cookie in the control to authenticate that this Bind was a legitimate followon to the earlier Search, to prevent arbitrary clients from sending bogus "Bind/Failed" requests to the directory and thus effortlessly locking out any user of their choice. But the existing ppolicy spec already allows external authentication, by virtue of the Compare request. After an external agent retrieves the secret and verifies the client, it just needs to do a Compare request to update the directory's policy state. Since it has already retrieved the actual credentials, it can do a Compare with the current value to indicate a successful authentication, and a Compare with some different value to indicate a failed authentication. And the issue of bogus requests is mitigated by using access controls to restrict who can do search/compare on the authentication secret. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Sat Aug 15 02:27:04 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CAFA28C1E1 for ; Sat, 15 Aug 2009 02:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+XdEKPuFfdl for ; Sat, 15 Aug 2009 02:27:02 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id D20C928C1DF for ; Sat, 15 Aug 2009 02:27:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 0FA8C10F96; Sat, 15 Aug 2009 05:27:06 -0400 (EDT) Message-ID: <4A867F6A.9060407@highlandsun.com> Date: Sat, 15 Aug 2009 02:27:06 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090809 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: "Keutel, Jochen" References: <20070924194342.GA9926@tile.skills-1st.co.uk> <47625E32.7010504@keutel.de> In-Reply-To: <47625E32.7010504@keutel.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ldapext , Andrew Findlay Subject: Re: [ldapext] Summary of group discussion X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 09:27:04 -0000 Keutel, Jochen wrote: > Hello Andrew, > I'm definitely late in commenting this ... I just missed the > discussion in September, sorry. > > One thing I'd like to add: X.501 defines the X.500 access control > schema. Esp. it defines: > > ACIItem ::= SEQUENCE { > identificationTag DirectoryString { ub-tag }, > precedence Precedence, > authenticationLevel AuthenticationLevel, > itemOrUserFirst CHOICE { > itemFirst [0] SEQUENCE { > protectedItems ProtectedItems, > itemPermissions SET OF ItemPermission }, > userFirst [1] SEQUENCE { > userClasses UserClasses, > userPermissions SET OF UserPermission } } } > > UserClasses ::= SEQUENCE { > allUsers [0] NULL OPTIONAL, > thisEntry [1] NULL OPTIONAL, > name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, > userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, > -- dn component shall be the name of an > -- entry of GroupOfUniqueNames > subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL } > > The referenced NameAndOptionalUID is defined in X.520: > > NameAndOptionalUID ::= SEQUENCE { > dn DistinguishedName, > uid UniqueIdentifier OPTIONAL } > > So here we have a unique identifier twice: Inside the groupOfUniqueNames > and in the NameAndOptionalUID structure. Both are not used in the real > world ... (at least I've never seen it). > > The problem I see: Products using this ACI schema (esp. X.500 based > products as e.g. Siemens DirX or CriticalPath) do only work if the > userGroup component of UserClasses is really a groupOfuniqueNames. Of > course you can put the DN of a groupOfNames or groupOfEntries or ... > into this field - but ACI checking won't work. > > So I see 2 points: > > 1. Shall X.501 be changed as well? In X.501(1993), which is the spec that LDAP conforms to, section 16.4.2.5 "Determining group membership" clause (b) says The entry named by the userGroup specification must be an instance of the object class groupOfNames or groupOfUniqueNames. So from that perspective, we're not completely cutting things off. > 2. Shall this ACI issue be mentioned in your draft? The other alternative is to fix the LDAP definition of the NameAndOptionalUID syntax, so that it's actually usable in LDAP. Given the bass-ackward RDN ordering that was chosen for the string representation of DNs in LDAP, the only unambiguous thing to do with these is to put the x500uniqueIdentifier *first* in the string. So revise RFC4517's definition 3.3.21 NameAndOptionalUID = [BitString] distinguishedName The SHARP character in the current definition is extraneous since the BitString definition is already fully delimited. If we fix this syntax then I would drop all objections relating to its use. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Sat Aug 15 02:37:02 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDA428C1E9 for ; Sat, 15 Aug 2009 02:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 833rK9OjAUwt for ; Sat, 15 Aug 2009 02:37:01 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 6CB3F3A6A4F for ; Sat, 15 Aug 2009 02:37:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id CAF8610F96; Sat, 15 Aug 2009 05:37:05 -0400 (EDT) Message-ID: <4A8681C1.70904@highlandsun.com> Date: Sat, 15 Aug 2009 02:37:05 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090809 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: "Keutel, Jochen" References: <20070924194342.GA9926@tile.skills-1st.co.uk> <47625E32.7010504@keutel.de> <4A867F6A.9060407@highlandsun.com> In-Reply-To: <4A867F6A.9060407@highlandsun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Findlay , ldapext Subject: Re: [ldapext] Summary of group discussion X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 09:37:02 -0000 Howard Chu wrote: > Keutel, Jochen wrote: >> Hello Andrew, >> I'm definitely late in commenting this ... I just missed the >> discussion in September, sorry. >> >> One thing I'd like to add: X.501 defines the X.500 access control >> schema. Esp. it defines: >> >> ACIItem ::= SEQUENCE { >> identificationTag DirectoryString { ub-tag }, >> precedence Precedence, >> authenticationLevel AuthenticationLevel, >> itemOrUserFirst CHOICE { >> itemFirst [0] SEQUENCE { >> protectedItems ProtectedItems, >> itemPermissions SET OF ItemPermission }, >> userFirst [1] SEQUENCE { >> userClasses UserClasses, >> userPermissions SET OF UserPermission } } } >> >> UserClasses ::= SEQUENCE { >> allUsers [0] NULL OPTIONAL, >> thisEntry [1] NULL OPTIONAL, >> name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, >> userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, >> -- dn component shall be the name of an >> -- entry of GroupOfUniqueNames >> subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL } >> >> The referenced NameAndOptionalUID is defined in X.520: >> >> NameAndOptionalUID ::= SEQUENCE { >> dn DistinguishedName, >> uid UniqueIdentifier OPTIONAL } >> >> So here we have a unique identifier twice: Inside the groupOfUniqueNames >> and in the NameAndOptionalUID structure. Both are not used in the real >> world ... (at least I've never seen it). >> >> The problem I see: Products using this ACI schema (esp. X.500 based >> products as e.g. Siemens DirX or CriticalPath) do only work if the >> userGroup component of UserClasses is really a groupOfuniqueNames. Of >> course you can put the DN of a groupOfNames or groupOfEntries or ... >> into this field - but ACI checking won't work. >> >> So I see 2 points: >> >> 1. Shall X.501 be changed as well? > > In X.501(1993), which is the spec that LDAP conforms to, section 16.4.2.5 > "Determining group membership" clause (b) says > > The entry named by the userGroup specification must be an instance of the > object class groupOfNames or groupOfUniqueNames. > > So from that perspective, we're not completely cutting things off. > >> 2. Shall this ACI issue be mentioned in your draft? > > The other alternative is to fix the LDAP definition of the NameAndOptionalUID > syntax, so that it's actually usable in LDAP. > > Given the bass-ackward RDN ordering that was chosen for the string > representation of DNs in LDAP, the only unambiguous thing to do with these is > to put the x500uniqueIdentifier *first* in the string. OK, it's not the *only* unambiguous thing. We could also just use another RDN delimiter (COMMA) instead of the SHARP in the current definition. > So revise RFC4517's > definition 3.3.21 > > NameAndOptionalUID = [BitString] distinguishedName > > The SHARP character in the current definition is extraneous since the > BitString definition is already fully delimited. > > If we fix this syntax then I would drop all objections relating to its use. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From michael@stroeder.com Sat Aug 15 03:59:48 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99A793A6A11 for ; Sat, 15 Aug 2009 03:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLrIYKeRlHfT for ; Sat, 15 Aug 2009 03:59:47 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id A7B3D3A69CC for ; Sat, 15 Aug 2009 03:59:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id DF70A4E076; Sat, 15 Aug 2009 12:59:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEtKq+xm48tj; Sat, 15 Aug 2009 12:59:38 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 6AEE94E06D; Sat, 15 Aug 2009 12:59:37 +0200 (CEST) Message-ID: <4A86951A.50006@stroeder.com> Date: Sat, 15 Aug 2009 12:59:38 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090606 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Howard Chu References: <20070924194342.GA9926@tile.skills-1st.co.uk> <47625E32.7010504@keutel.de> <4A867F6A.9060407@highlandsun.com> In-Reply-To: <4A867F6A.9060407@highlandsun.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Findlay , ldapext , "Keutel, Jochen" Subject: Re: [ldapext] Summary of group discussion X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 10:59:48 -0000 Howard Chu wrote: > The other alternative is to fix the LDAP definition of the > NameAndOptionalUID syntax, so that it's actually usable in LDAP. > > Given the bass-ackward RDN ordering that was chosen for the string > representation of DNs in LDAP, the only unambiguous thing to do with > these is to put the x500uniqueIdentifier *first* in the string. So > revise RFC4517's definition 3.3.21 > > NameAndOptionalUID = [BitString] distinguishedName > > The SHARP character in the current definition is extraneous since the > BitString definition is already fully delimited. > > If we fix this syntax then I would drop all objections relating to its use. 1. I don't any deployment which uses the optional BitString part. The deployments I know just use the distinguishedName. 2. The implementations I know which might make use of the optional UID part did not use a BitString there. They messed it up with attribute 'uid' (which is of DirectoryString). 3. Changing declaration in RFC 4517 would potentially break things. => My suggestion would be to add an applicability note to section 3.3.21 which states that either distinguishedName MUST NOT contain SHARP. Or maybe it would be possible to mandate that SHARP MUST be escaped like described in RFC 4514. Ciao, Michael. From hyc@highlandsun.com Sat Aug 15 04:32:53 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63A4A3A6E1D for ; Sat, 15 Aug 2009 04:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S80DL-4WOOLB for ; Sat, 15 Aug 2009 04:32:52 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 853413A6A43 for ; Sat, 15 Aug 2009 04:32:52 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 5973B83EFA for ; Sat, 15 Aug 2009 07:32:56 -0400 (EDT) Message-ID: <4A869CE7.2070506@highlandsun.com> Date: Sat, 15 Aug 2009 04:32:55 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090809 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: ldapext@ietf.org References: <4A4EC639.3070706@highlandsun.com> <4A52986B.80001@highlandsun.com> <4A7969DD.4090903@highlandsun.com> <4A85976A.6050807@stroeder.com> <4A85D706.1050601@highlandsun.com> In-Reply-To: <4A85D706.1050601@highlandsun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 11:32:53 -0000 One other point that I almost forgot - the whole issue of intruder detection is still rather fragile. E.g., if an attacker is running a stream of guesses against a user while the real user logs in, then the successful login will erase the current pwdFailureTime state and so allow the attacker a few more chances unimpeded. I suppose this is only a small problem in general. My first response to this is that password failures should only be tracked ephemerally, within a particular DSA. I would also say they should be tracked by client IP address, but these days attacks by botnets makes the value of that approach less clear. It's also less effective in an environment using a cluster of load balanced DSAs. But I think it still makes more sense to track failures within a single DSA than to deal with replication of that state. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Sat Aug 15 04:48:44 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB27E3A6DF3 for ; Sat, 15 Aug 2009 04:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwWd-2KPlSWJ for ; Sat, 15 Aug 2009 04:48:43 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id C37B23A67F5 for ; Sat, 15 Aug 2009 04:48:43 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 20CB783EFA; Sat, 15 Aug 2009 07:48:47 -0400 (EDT) Message-ID: <4A86A09F.8060803@highlandsun.com> Date: Sat, 15 Aug 2009 04:48:47 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090809 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: =?windows-1252?Q?Michael_Str=F6der?= References: <20070924194342.GA9926@tile.skills-1st.co.uk> <47625E32.7010504@keutel.de> <4A867F6A.9060407@highlandsun.com> <4A86951A.50006@stroeder.com> In-Reply-To: <4A86951A.50006@stroeder.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Andrew Findlay , ldapext , "Keutel, Jochen" Subject: Re: [ldapext] Summary of group discussion X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 11:48:44 -0000 Michael Ströder wrote: > Howard Chu wrote: >> The other alternative is to fix the LDAP definition of the >> NameAndOptionalUID syntax, so that it's actually usable in LDAP. >> >> Given the bass-ackward RDN ordering that was chosen for the string >> representation of DNs in LDAP, the only unambiguous thing to do with >> these is to put the x500uniqueIdentifier *first* in the string. So >> revise RFC4517's definition 3.3.21 >> >> NameAndOptionalUID = [BitString] distinguishedName >> >> The SHARP character in the current definition is extraneous since the >> BitString definition is already fully delimited. >> >> If we fix this syntax then I would drop all objections relating to its use. > > 1. I don't any deployment which uses the optional BitString part. The > deployments I know just use the distinguishedName. Right. I doubt that anyone will ever notice a change here. > 2. The implementations I know which might make use of the optional UID part > did not use a BitString there. They messed it up with attribute 'uid' (which > is of DirectoryString). Then they're broken regardless of what we decide. > 3. Changing declaration in RFC 4517 would potentially break things. For a very very small number of deployments. I suspect the number is zero. > => My suggestion would be to add an applicability note to section 3.3.21 which > states that either distinguishedName MUST NOT contain SHARP. Or maybe it would > be possible to mandate that SHARP MUST be escaped like described in RFC 4514. No, changing the escaping rules for DNs would definitely break things. Also, on the topic of X.500 compatibility, as Jochen pointed out: >> UserClasses ::= SEQUENCE { >> allUsers [0] NULL OPTIONAL, >> thisEntry [1] NULL OPTIONAL, >> name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, >> userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, >> -- dn component shall be the name of an >> -- entry of GroupOfUniqueNames >> subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL } ACIs specifying users are also not just simple DNs. The obvious implication is that when a user with an associated x500UniqueIdentifier authenticates to a DSA, this UID must also be included in the authzID that the DSA associates to the session. RFC4511 doesn't mention anything about this. Additionally, X.501 16.4.2.4 (g) Note 3 NOTE 3 – When authentication is based on supplied SecurityParameters, the unique identifier associated with the user may be taken from the subjectUniqueIdentifier field of the sender’s Certificate in the optional CertificationPath I would take this to mean that if an LDAP session was authenticated with SASL/EXTERNAL using an X.509 client cert, the LDAP DSA SHOULD look for the cert's subjectUniqueIdentifier. But I guess that's a digression for another thread... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From Kurt.Zeilenga@Isode.com Sat Aug 15 11:10:17 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8C03A6C69 for ; Sat, 15 Aug 2009 11:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKHYrO61D-NU for ; Sat, 15 Aug 2009 11:10:17 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:219:21ff:fe2f:68d5]) by core3.amsl.com (Postfix) with ESMTP id 038E33A6B5B for ; Sat, 15 Aug 2009 11:10:16 -0700 (PDT) Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n7FIACkF012010; Sat, 15 Aug 2009 18:10:13 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: From: Kurt Zeilenga To: Howard Chu In-Reply-To: <4A86A09F.8060803@highlandsun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 15 Aug 2009 11:10:12 -0700 References: <20070924194342.GA9926@tile.skills-1st.co.uk> <47625E32.7010504@keutel.de> <4A867F6A.9060407@highlandsun.com> <4A86951A.50006@stroeder.com> <4A86A09F.8060803@highlandsun.com> X-Mailer: Apple Mail (2.936) Cc: ldapext , Andrew Findlay , =?WINDOWS-1252?Q?Michael_Str=F6der?= , "Keutel, Jochen" Subject: Re: [ldapext] Summary of group discussion X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2009 18:10:17 -0000 On Aug 15, 2009, at 4:48 AM, Howard Chu wrote: > Also, on the topic of X.500 compatibility, as Jochen pointed out: > > >> UserClasses ::= SEQUENCE { > >> allUsers [0] NULL OPTIONAL, > >> thisEntry [1] NULL OPTIONAL, > >> name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL, > >> userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID > OPTIONAL, > >> -- dn component shall be the name of an > >> -- entry of GroupOfUniqueNames > >> subtree [4] SET SIZE (1..MAX) OF SubtreeSpecification > OPTIONAL } > > ACIs specifying users are also not just simple DNs. In theory, yes. I have never seen the optional UID used in practice, and I seriously doubt directory agents consistently and properly implement UID support. And even if the implementations one was using did well provide UID support, I would not recommend use of the feature. Instead, deployers should instead utilize a naming scheme which produces single use, stable DNs. > The obvious implication is that when a user with an associated > x500UniqueIdentifier authenticates to a DSA, this UID must also be > included in the authzID that the DSA associates to the session. > RFC4511 doesn't mention anything about this. The LDAP TS likely should include a security consideration (and likely in multiple documents) that deployers should utilize an appropriate naming scheme to avoid the need for UIDs. -- Kurt From michael@stroeder.com Tue Aug 18 04:14:24 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A1E3A6966 for ; Tue, 18 Aug 2009 04:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuyDyaLT8fZj for ; Tue, 18 Aug 2009 04:14:23 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id 10B863A68F3 for ; Tue, 18 Aug 2009 04:14:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 2CFBA4E07F; Tue, 18 Aug 2009 13:11:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNOcHyBEsD5R; Tue, 18 Aug 2009 13:11:47 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 4434A4E073; Tue, 18 Aug 2009 13:11:47 +0200 (CEST) Message-ID: <4A8A8C72.20503@stroeder.com> Date: Tue, 18 Aug 2009 13:11:46 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.22) Gecko/20090606 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Howard Chu References: <4A7F4296.2070807@highlandsun.com> In-Reply-To: <4A7F4296.2070807@highlandsun.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Ldapext Subject: [ldapext] timezone date (was: Fwd: Manual Post Requested for draft-howard-rfc2307bis) X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2009 11:14:24 -0000 Howard, do you think setting something like the timezone used for a user would be feasible? Or other Unix locale data? I raised this on ldap@umich.edu a couple of days ago and it could be related to your current work on that draft. Ciao, Michael. -------- Original Message -------- Subject: [ldap] Re: LDAP attribute type for timezone, retrieve locale for shell sessions Date: Thu, 13 Aug 2009 20:25:42 +0200 From: Michael Ströder To: adam@morrison-ind.com CC: ldap@umich.edu References: <4A841C2C.8000701@stroeder.com> <1250172072.6473.14.camel@linux-m3mt> Adam Tauno Williams wrote: > On Thu, 2009-08-13 at 15:59 +0200, Michael Ströder wrote: >> Anybody aware of an attribute type dedicated to store the time zone of a user? > > Nope (but timezone codes are just strings). I think this would be the > 'default' timezone of a user; Hmm, frankly I'm not really familiar with this stuff. Looking at the timezone package on my Linux my spontaneous idea would be to add directory entries containing the compiled timezone blobs and a time zone attribute would just contain a DN as reference on this timezone blob entry. > but a user can easily move between time > zones. Yes, I'm aware of that. So the timezone setting in the directory entry should be kind of a self-service attribute. > It is actually pretty difficult [for scheduling applications] to > determine what is the correct thing to do with TZ sometimes. Well, calendaring software is not my primary goal. Rather simple things like displaying timestamps in local time in my web2ldap or correctly set the timezone-related env vars in a shell. The latter could be easily overridden by local shell profiles. >> It would also make sense if pam_ldap/nss_ldap could query the locale of the >> user from the user's directory entry and set the locale accordingly. Anybody >> doing something like this? > > Wow, that would be awesome. But I'm not holding my breath. ;-) Let's first discuss a data model... Ciao, Michael.