From mailman-admin@ietf.org Sun Dec 1 10:02:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06980 for ; Sun, 1 Dec 2002 10:02:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB1F4Rv31601 for ; Sun, 1 Dec 2002 10:04:27 -0500 Date: Sun, 01 Dec 2002 10:04:27 -0500 Message-ID: <20021201150427.8899.97797.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ldapext-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ldapext-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ldapext-archive@lists.ietf.org: List Password // URL ---- -------- ldapext@ietf.org LxAC https://www1.ietf.org/mailman/options/ldapext/ldapext-archive%40lists.ietf.org From ldapext-admin@ietf.org Mon Dec 2 21:37:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23024 for ; Mon, 2 Dec 2002 21:37:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB32Wdv22064; Mon, 2 Dec 2002 21:32:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB32Uxv22007 for ; Mon, 2 Dec 2002 21:30:59 -0500 Received: from clmboh1-smtp5.columbus.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22490 for ; Mon, 2 Dec 2002 21:28:00 -0500 (EST) Received: from willeke.com (dhcp024-166-083-155.neo.rr.com [24.166.83.155]) by clmboh1-smtp5.columbus.rr.com (8.11.2/8.11.2) with ESMTP id gB32UiH17161; Mon, 2 Dec 2002 21:30:44 -0500 (EST) Message-ID: <3DEC1722.6090308@willeke.com> Date: Mon, 02 Dec 2002 21:29:54 -0500 From: Jim Willeke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark C Smith CC: Jim Sermersheim , ldapext@ietf.org, andrews@adacel.com.au, bcheckley@epresence.com, Alan Clark , Hal Henderson Subject: Re: [ldapext] Re: Password policy state attributes References: <3DE24DF2.8010302@netscape.com> In-Reply-To: <3DE24DF2.8010302@netscape.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit As a "Real" worl example, we are using multiple password as one is "sync'd" to an iPlanet server and is stored in sha-1 format another is" sync'd" to a "home-grown" application and is in MD-5 and then the third is the "normal" LDAP password. A reason we store them all in the directory ? The user goes to one WEB site to chang e thier password and all passwords are updated from the WEB sit eto the directory. Then a background process copies the password to the places they need to be copied. -jim Mark C Smith wrote: > How common is the "multiple passwords" scenario in real world > deployments? My impression is that it is very rare. If so, I am > opposed to doing extensive engineering and adding complexity for > implementors and users in order to support it. I think most people > will be happy with a password policy specification that only supports > one password attribute. But if we really need support for more than > one, I vote for the: > > pwdExpirationWarned;pwd-userPassword > pwdExpirationWarned;pwd-webPassword > > approach. If we require that all attribute types used in conjunction > with password policy be registered with IANA, I don't think there will > be any serious interoperability problems with this approach. > > -Mark Smith > Netscape > > > Jim Sermersheim wrote: > >> A group of people interested in progressing the password policy draft >> has been growing and exchanging emails off list. We're moving >> discussion here so we have a list and a wider audience. >> >> The current topic has to do with storing password policy state >> information for objects. What is needed is a way to store values that >> represent state information on an object. There is the need to >> associate the state information with a password. This is because it's >> desirable to allow multiple passwords per object, and it to be >> allowed that policy can be described and executed separately for each >> password. Thus, we need a way of associating each bit of password >> policy state information with the password it applies to. >> >> For example. There is an attribute called pwdExpirationWarned. This >> holds the timestamp of when the client was first warned that the >> password would expire soon, thus it is single-valued. Now, let's say >> the object that is subject to password policy makes use of three >> password attributes due to there being three different hard access >> interfaces: atmPassword, telePassword, and webPassword (think bank >> account access). When the pwdExpirationWarned attribute is updated >> (due to an impending password expiration), there needs to be some >> way of associating the warning with the password that will expire >> (let's say it's webPassword). >> >> Our first attempt was to use attribute descriptions with a new >> tagging option called "pwd-". In the example above, >> pwdExpirationWarned;pwd-webPassword would be used to store/retrieve >> the warning time for the webPassword. The problem that was brought up >> with this approach (as I remember it) was that since the descr form >> of attribute types is not canonical, we cannot use it in the >> attribute option. It would lead to interoperability problems. >> >> Quickly, it was suggested to just use the oid form of the attribute >> type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve >> the problem above, it is an illegal encoding. Attribute options are >> defined as consisting of ALPHA, DIGIT, and DASH characters. >> >> Then the suggestion of moving the attribute association inside the >> value was put forth say something like "webPassword#200210240212Z". >> This requires new syntaxes which some implementors don't like, but >> worse: 1) It doesn't allow the attributes to be defined as >> single-value. 2) It doesn't allow the server to enforce uniqueness >> among the values. 3) It doesn't allow the replace operation (where >> replace would work with single-valued attributes). None of these >> limitations are desirable. >> >> I would now like to suggest returning to the first or second >> suggestion. The first has limitations in a distributed environment, >> and maybe something can be done about it, but I'm not sure what. The >> second would be modified to fit the required syntax by replacing dots >> with dashes. Thus the example would change to: >> pwdExpirationWarned;pwd-1-2-3-4 >> >> Jim >> >> p.s. I can provide a set of recent previous discussions on this and >> other issues to anyone that wants them. >> >> _______________________________________________ >> 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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Dec 2 22:11:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23658 for ; Mon, 2 Dec 2002 22:11:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3394v24392; Mon, 2 Dec 2002 22:09:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB338Hv24352 for ; Mon, 2 Dec 2002 22:08:17 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23536 for ; Mon, 2 Dec 2002 22:05:17 -0500 (EST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gB337wF3085835; Tue, 3 Dec 2002 03:07:58 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20021202185315.02748ea8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 19:07:51 -0800 To: Jim Willeke From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Re: Password policy state attributes Cc: Mark C Smith , Jim Sermersheim , ldapext@ietf.org, andrews@adacel.com.au, bcheckley@epresence.com, Alan Clark , Hal Henderson In-Reply-To: <3DEC1722.6090308@willeke.com> References: <3DE24DF2.8010302@netscape.com> <3DE24DF2.8010302@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , The example you give is for multiple encodings of the same password, not multiple passwords. I am sure there are real world examples of multiple passwords. I've seen them to manage password transitions. That is one might have both the new and old passwords stored in userPassword during a transitional period. Then there is an issue of multiple password attributes (e.g. userPassword v. authPassword). Personally, I think the password policy should minimally support multiple values of userPassword... Kurt At 06:29 PM 2002-12-02, Jim Willeke wrote: >As a "Real" worl example, we are using multiple password as one is "sync'd" to an iPlanet server and is stored in sha-1 format another is" sync'd" to a "home-grown" application and is in MD-5 and then the third is the "normal" LDAP password. > >A reason we store them all in the directory ? The user goes to one WEB site to chang e thier password and all passwords are updated from the WEB sit eto the directory. Then a background process copies the password to the places they need to be copied. >-jim > >Mark C Smith wrote: > >>How common is the "multiple passwords" scenario in real world deployments? My impression is that it is very rare. If so, I am opposed to doing extensive engineering and adding complexity for implementors and users in order to support it. I think most people will be happy with a password policy specification that only supports one password attribute. But if we really need support for more than one, I vote for the: >> >> pwdExpirationWarned;pwd-userPassword >> pwdExpirationWarned;pwd-webPassword >> >>approach. If we require that all attribute types used in conjunction with password policy be registered with IANA, I don't think there will be any serious interoperability problems with this approach. >> >>-Mark Smith >> Netscape >> >> >>Jim Sermersheim wrote: >> >>>A group of people interested in progressing the password policy draft has been growing and exchanging emails off list. We're moving discussion here so we have a list and a wider audience. >>> >>>The current topic has to do with storing password policy state information for objects. What is needed is a way to store values that represent state information on an object. There is the need to associate the state information with a password. This is because it's desirable to allow multiple passwords per object, and it to be allowed that policy can be described and executed separately for each password. Thus, we need a way of associating each bit of password policy state information with the password it applies to. >>> >>>For example. There is an attribute called pwdExpirationWarned. This holds the timestamp of when the client was first warned that the password would expire soon, thus it is single-valued. Now, let's say the object that is subject to password policy makes use of three password attributes due to there being three different hard access interfaces: atmPassword, telePassword, and webPassword (think bank account access). When the pwdExpirationWarned attribute is updated (due to an impending password expiration), there needs to be some way of associating the warning with the password that will expire (let's say it's webPassword). >>> >>>Our first attempt was to use attribute descriptions with a new tagging option called "pwd-". In the example above, pwdExpirationWarned;pwd-webPassword would be used to store/retrieve the warning time for the webPassword. The problem that was brought up with this approach (as I remember it) was that since the descr form of attribute types is not canonical, we cannot use it in the attribute option. It would lead to interoperability problems. >>> >>>Quickly, it was suggested to just use the oid form of the attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem above, it is an illegal encoding. Attribute options are defined as consisting of ALPHA, DIGIT, and DASH characters. >>> >>>Then the suggestion of moving the attribute association inside the value was put forth say something like "webPassword#200210240212Z". This requires new syntaxes which some implementors don't like, but worse: 1) It doesn't allow the attributes to be defined as single-value. 2) It doesn't allow the server to enforce uniqueness among the values. 3) It doesn't allow the replace operation (where replace would work with single-valued attributes). None of these limitations are desirable. >>> >>>I would now like to suggest returning to the first or second suggestion. The first has limitations in a distributed environment, and maybe something can be done about it, but I'm not sure what. The second would be modified to fit the required syntax by replacing dots with dashes. Thus the example would change to: pwdExpirationWarned;pwd-1-2-3-4 >>> >>>Jim >>> >>>p.s. I can provide a set of recent previous discussions on this and other issues to anyone that wants them. >>> >>>_______________________________________________ >>>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 > > >_______________________________________________ >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 From ldapext-admin@ietf.org Mon Dec 2 23:04:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25261 for ; Mon, 2 Dec 2002 23:04:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB342Av26822; Mon, 2 Dec 2002 23:02:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3416v26780 for ; Mon, 2 Dec 2002 23:01:06 -0500 Received: from nexus.adacel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25145 for ; Mon, 2 Dec 2002 22:58:07 -0500 (EST) Received: (qmail 25619 invoked from network); 3 Dec 2002 03:51:07 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 3 Dec 2002 03:51:07 -0000 Reply-To: From: "Andrew Sciberras" To: "'Kurt D. Zeilenga'" Cc: "'Jim Willeke'" , "'Mark C Smith'" , "'Jim Sermersheim'" , , , "'Alan Clark'" , "'Hal Henderson'" Subject: RE: [ldapext] Re: Password policy state attributes Date: Tue, 3 Dec 2002 14:59:41 +1100 Message-ID: <008a01c29a80$691a5520$a618200a@mtwav.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 In-Reply-To: <5.2.0.9.0.20021202185315.02748ea8@127.0.0.1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi I think that it is important to consider whether the Password Policy should be able to support password values that are stored using options ( Egg. userPassword;x-exampleOption ). If it should, then the password policy state attributes must use more than just the object identifier of the password attribute to make an association between the state information and the password value which it applies to. Andrew. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Tuesday, 3 December 2002 14:08 > To: Jim Willeke > Cc: Mark C Smith; Jim Sermersheim; ldapext@ietf.org; > andrews@adacel.com.au; bcheckley@epresence.com; Alan Clark; Hal > Henderson > Subject: Re: [ldapext] Re: Password policy state attributes > > > The example you give is for multiple encodings of the same password, > not multiple passwords. I am sure there are real world examples > of multiple passwords. I've seen them to manage password transitions. > That is one might have both the new and old passwords stored in > userPassword during a transitional period. > > Then there is an issue of multiple password attributes (e.g. > userPassword v. authPassword). > > Personally, I think the password policy should minimally support > multiple values of userPassword... > > Kurt > > At 06:29 PM 2002-12-02, Jim Willeke wrote: > >As a "Real" worl example, we are using multiple password as > one is "sync'd" to an iPlanet server and is stored in sha-1 > format another is" sync'd" to a "home-grown" application and > is in MD-5 and then the third is the "normal" LDAP password. > > > >A reason we store them all in the directory ? The user goes > to one WEB site to chang e thier password and all passwords > are updated from the WEB sit eto the directory. Then a > background process copies the password to the places they > need to be copied. > >-jim > > > >Mark C Smith wrote: > > > >>How common is the "multiple passwords" scenario in real > world deployments? My impression is that it is very rare. If > so, I am opposed to doing extensive engineering and adding > complexity for implementors and users in order to support it. > I think most people will be happy with a password policy > specification that only supports one password attribute. But > if we really need support for more than one, I vote for the: > >> > >> pwdExpirationWarned;pwd-userPassword > >> pwdExpirationWarned;pwd-webPassword > >> > >>approach. If we require that all attribute types used in > conjunction with password policy be registered with IANA, I > don't think there will be any serious interoperability > problems with this approach. > >> > >>-Mark Smith > >> Netscape > >> > >> > >>Jim Sermersheim wrote: > >> > >>>A group of people interested in progressing the password > policy draft has been growing and exchanging emails off list. > We're moving discussion here so we have a list and a wider audience. > >>> > >>>The current topic has to do with storing password policy > state information for objects. What is needed is a way to > store values that represent state information on an object. > There is the need to associate the state information with a > password. This is because it's desirable to allow multiple > passwords per object, and it to be allowed that policy can be > described and executed separately for each password. Thus, we > need a way of associating each bit of password policy state > information with the password it applies to. > >>> > >>>For example. There is an attribute called > pwdExpirationWarned. This holds the timestamp of when the > client was first warned that the password would expire soon, > thus it is single-valued. Now, let's say the object that is > subject to password policy makes use of three password > attributes due to there being three different hard access > interfaces: atmPassword, telePassword, and webPassword (think > bank account access). When the pwdExpirationWarned attribute > is updated (due to an impending password expiration), there > needs to be some way of associating the warning with the > password that will expire (let's say it's webPassword). > >>> > >>>Our first attempt was to use attribute descriptions with a > new tagging option called "pwd-". In the example above, > pwdExpirationWarned;pwd-webPassword would be used to > store/retrieve the warning time for the webPassword. The > problem that was brought up with this approach (as I remember > it) was that since the descr form of attribute types is not > canonical, we cannot use it in the attribute option. It would > lead to interoperability problems. > >>> > >>>Quickly, it was suggested to just use the oid form of the > attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While > this would solve the problem above, it is an illegal > encoding. Attribute options are defined as consisting of > ALPHA, DIGIT, and DASH characters. > >>> > >>>Then the suggestion of moving the attribute association > inside the value was put forth say something like > "webPassword#200210240212Z". This requires new syntaxes which > some implementors don't like, but worse: 1) It doesn't allow > the attributes to be defined as single-value. 2) It doesn't > allow the server to enforce uniqueness among the values. 3) > It doesn't allow the replace operation (where replace would > work with single-valued attributes). None of these > limitations are desirable. > >>> > >>>I would now like to suggest returning to the first or > second suggestion. The first has limitations in a distributed > environment, and maybe something can be done about it, but > I'm not sure what. The second would be modified to fit the > required syntax by replacing dots with dashes. Thus the > example would change to: pwdExpirationWarned;pwd-1-2-3-4 > >>> > >>>Jim > >>> > >>>p.s. I can provide a set of recent previous discussions on > this and other issues to anyone that wants them. > >>> > >>>_______________________________________________ > >>>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 > > > > > >_______________________________________________ > >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 From ldapext-admin@ietf.org Tue Dec 3 09:40:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22563 for ; Tue, 3 Dec 2002 09:40:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3EfLv11102; Tue, 3 Dec 2002 09:41:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB3EeGv31349 for ; Tue, 3 Dec 2002 09:40:16 -0500 Received: from e3.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22311 for ; Tue, 3 Dec 2002 09:37:23 -0500 (EST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gB3EeDfw172490 for ; Tue, 3 Dec 2002 09:40:13 -0500 Received: from d27ml001.rchland.ibm.com (d27ml001.rchland.ibm.com [9.10.226.142]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gB3EeBsI029094 for ; Tue, 3 Dec 2002 09:40:11 -0500 Subject: Re: [ldapext] Re: Password policy state attributes To: ldapext@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: John McMeeking Date: Tue, 3 Dec 2002 08:40:10 -0600 X-MIMETrack: Serialize by Router on d27ml001/27/M/IBM(Release 6.0|September 26, 2002) at 12/03/2002 08:40:12 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Several scenarios have been described which I think need to be clearly distinguished: 1. Multiple userPassword (or attribute) values. For example, an entry has userPassword values "secret" and "anothersecret". I would prefer that password policy attributes apply to the entire set of userPassword values. I have a hard time with the notion that "secret" is valid and "anothersecret" has been reset, or the notion of a single password being locked. Trying to express that state would require tying the policy attributes to individual values and likely that the user know passwords to get the values or that the values be returned in clear text to make use of the results. Try searching for all entries with expired passwords or figuring out from the results which of the user's passwords were expired. 2. Multiple password attributes used by the server for authentication of a single entry, as opposed to 3, below. I think this would require something like simple bind using userPassword, DIGEST-MD5 using authPassword, ... This seems like a bit of a stretch, but that may be just my limited perspective. If this is a valid scenario, then I would prefer the approach Mark Smith favored: pwdExpirationWarned;pwd-userPassword If (2) is considered valid, should the passwordPolicyResponse control be changed to indicate which password attribute the warning or error applied to? 3. Multiple password attributes, where applications perform authentication. For example, web app retrieves the webPassword attribute and compares it to the user entered string. I don't see password policy applying here. The server is not performing the authentication function (no bind request), making the data no different than telephone numbers from a directory server perspective. To summarize: - The policy attributes like pwdExpirationWarned should apply to all password values (possibly multiple values of a single attribute) for an entry. I do not favor trying to support policy attributes for each individual value of a single attribute. - I don't think multiple password attributes are likely to be used within a single entry and used to support bind requests. I could be persuaded otherwise, in which case I would like to see something like: pwdExpirationWarned;pwd-userPassword John McMeeking "Kurt D. Zeilenga" To: Jim Willeke , Jim Sermersheim g> , ldapext@ietf.org, andrews@adacel.com.au, Sent by: bcheckley@epresence.com, Alan Clark , ldapext-admin@iet Hal Henderson f.org Subject: Re: [ldapext] Re: Password policy state attributes 12/02/2002 09:07 PM The example you give is for multiple encodings of the same password, not multiple passwords. I am sure there are real world examples of multiple passwords. I've seen them to manage password transitions. That is one might have both the new and old passwords stored in userPassword during a transitional period. Then there is an issue of multiple password attributes (e.g. userPassword v. authPassword). Personally, I think the password policy should minimally support multiple values of userPassword... Kurt At 06:29 PM 2002-12-02, Jim Willeke wrote: >As a "Real" worl example, we are using multiple password as one is "sync'd" to an iPlanet server and is stored in sha-1 format another is" sync'd" to a "home-grown" application and is in MD-5 and then the third is the "normal" LDAP password. > >A reason we store them all in the directory ? The user goes to one WEB site to chang e thier password and all passwords are updated from the WEB sit eto the directory. Then a background process copies the password to the places they need to be copied. >-jim > >Mark C Smith wrote: > >>How common is the "multiple passwords" scenario in real world deployments? My impression is that it is very rare. If so, I am opposed to doing extensive engineering and adding complexity for implementors and users in order to support it. I think most people will be happy with a password policy specification that only supports one password attribute. But if we really need support for more than one, I vote for the: >> >> pwdExpirationWarned;pwd-userPassword >> pwdExpirationWarned;pwd-webPassword >> >>approach. If we require that all attribute types used in conjunction with password policy be registered with IANA, I don't think there will be any serious interoperability problems with this approach. >> >>-Mark Smith >> Netscape >> >> >>Jim Sermersheim wrote: >> >>>A group of people interested in progressing the password policy draft has been growing and exchanging emails off list. We're moving discussion here so we have a list and a wider audience. >>> >>>The current topic has to do with storing password policy state information for objects. What is needed is a way to store values that represent state information on an object. There is the need to associate the state information with a password. This is because it's desirable to allow multiple passwords per object, and it to be allowed that policy can be described and executed separately for each password. Thus, we need a way of associating each bit of password policy state information with the password it applies to. >>> >>>For example. There is an attribute called pwdExpirationWarned. This holds the timestamp of when the client was first warned that the password would expire soon, thus it is single-valued. Now, let's say the object that is subject to password policy makes use of three password attributes due to there being three different hard access interfaces: atmPassword, telePassword, and webPassword (think bank account access). When the pwdExpirationWarned attribute is updated (due to an impending password expiration), there needs to be some way of associating the warning with the password that will expire (let's say it's webPassword). >>> >>>Our first attempt was to use attribute descriptions with a new tagging option called "pwd-". In the example above, pwdExpirationWarned;pwd-webPassword would be used to store/retrieve the warning time for the webPassword. The problem that was brought up with this approach (as I remember it) was that since the descr form of attribute types is not canonical, we cannot use it in the attribute option. It would lead to interoperability problems. >>> >>>Quickly, it was suggested to just use the oid form of the attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem above, it is an illegal encoding. Attribute options are defined as consisting of ALPHA, DIGIT, and DASH characters. >>> >>>Then the suggestion of moving the attribute association inside the value was put forth say something like "webPassword#200210240212Z". This requires new syntaxes which some implementors don't like, but worse: 1) It doesn't allow the attributes to be defined as single-value. 2) It doesn't allow the server to enforce uniqueness among the values. 3) It doesn't allow the replace operation (where replace would work with single-valued attributes). None of these limitations are desirable. >>> >>>I would now like to suggest returning to the first or second suggestion. The first has limitations in a distributed environment, and maybe something can be done about it, but I'm not sure what. The second would be modified to fit the required syntax by replacing dots with dashes. Thus the example would change to: pwdExpirationWarned;pwd-1-2-3-4 >>> >>>Jim >>> >>>p.s. I can provide a set of recent previous discussions on this and other issues to anyone that wants them. >>> >>>_______________________________________________ >>>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 > > >_______________________________________________ >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 _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Dec 3 19:25:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26766 for ; Tue, 3 Dec 2002 19:25:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB40LLv29002; Tue, 3 Dec 2002 19:21:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB40Kav28942 for ; Tue, 3 Dec 2002 19:20:36 -0500 Received: from nexus.adacel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26534 for ; Tue, 3 Dec 2002 19:17:37 -0500 (EST) Received: (qmail 26963 invoked from network); 4 Dec 2002 00:10:33 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 4 Dec 2002 00:10:33 -0000 Reply-To: From: "Andrew Sciberras" To: "'John McMeeking'" Cc: Subject: RE: [ldapext] Re: Password policy state attributes Date: Wed, 4 Dec 2002 11:19:13 +1100 Message-ID: <00bc01c29b2a$c6cbec60$a618200a@mtwav.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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi John, > 1. Multiple userPassword (or attribute) values. For > example, an entry has > userPassword values "secret" and "anothersecret". I would prefer that > password policy attributes apply to the entire set of > userPassword values. > I have a hard time with the notion that "secret" is valid and > "anothersecret" has been reset, or the notion of a single > password being > locked. Trying to express that state would require tying the policy > attributes to individual values and likely that the user know > passwords to > get the values or that the values be returned in clear text > to make use of > the results. Try searching for all entries with expired passwords or > figuring out from the results which of the user's passwords > were expired. I think that the original intention of the Password Policy (as specified in section 3.3) should still apply, in that the password attributes to which the policy applies should only have one value. Attempting to tie the password policy to particular values would definitely be a bit of a nightmare for all the reasons that you've mentioned plus the fact that not all state attributes can apply to values. For example, the pwdHistory state attribute must be associated with an attribute. > 3. Multiple password attributes, where applications perform > authentication. For example, web app retrieves the > webPassword attribute > and compares it to the user entered string. > I don't see password policy applying here. > The server is not performing the > authentication function > (no bind request), making the data no different than > telephone numbers from > a directory server perspective. I disagree. The current state of the Password Policy allows the web application to 'offload' user authentication to the server in the form of a compare operation. Section 6.4 of the draft discusses how a compare operation should be handled. A web application only needs to send the 'user entered string' to the directory in a compare operation to validate whether the provided password is correct. I believe that the Password Policy should be applied in this instance as the compare operation being made by the web application is equivalent to a bind. Perhaps the Policy should also be extended to treat some search operations as being equivalent to a bind as well. >From a security point of view it is also much safer to send the user entered text to the server rather than send the actual password to the web app, this is beside the point though. in summary I support the fact that: * the Password Policy should only support attributes with a single password value, * the Password Policy may apply to multiple attributes within a single entry, * the Password Policy should apply to password attributes and not values, * the state attributes should have a complex syntax which includes (as part of the value the value) the AttributeDescription of the password attribute to which the value applies. The AttributeDescription would contain the AttributeType plus any options. In this case the AttributeType should contain the dotted-decimal OBJECT IDENTIFIER of the attribute and not its textual name. Cheers, Andrew Sciberras. > > > To summarize: > - The policy attributes like pwdExpirationWarned should apply to all > password values (possibly multiple values of a single > attribute) for an > entry. I do not favor trying to support policy attributes for each > individual value of a single attribute. > - I don't think multiple password attributes are likely to > be used within > a single entry and used to support bind requests. I could be > persuaded > otherwise, in which case I would like to see something like: > pwdExpirationWarned;pwd-userPassword > > > John McMeeking > > > > > > "Kurt D. > > Zeilenga" To: Jim > Willeke > C Smith , Jim Sermersheim > g> > , ldapext@ietf.org, andrews@adacel.com.au, > > Sent by: > bcheckley@epresence.com, Alan Clark > , > ldapext-admin@iet Hal Henderson > > f.org Subject: Re: > [ldapext] Re: Password policy state attributes > > > > > 12/02/2002 09:07 > > PM > > > > > > > > > The example you give is for multiple encodings of the same password, > not multiple passwords. I am sure there are real world examples > of multiple passwords. I've seen them to manage password transitions. > That is one might have both the new and old passwords stored in > userPassword during a transitional period. > > Then there is an issue of multiple password attributes (e.g. > userPassword v. authPassword). > > Personally, I think the password policy should minimally support > multiple values of userPassword... > > Kurt > > At 06:29 PM 2002-12-02, Jim Willeke wrote: > >As a "Real" worl example, we are using multiple password as one is > "sync'd" to an iPlanet server and is stored in sha-1 format > another is" > sync'd" to a "home-grown" application and is in MD-5 and then > the third is > the "normal" LDAP password. > > > >A reason we store them all in the directory ? The user goes > to one WEB > site to chang e thier password and all passwords are updated > from the WEB > sit eto the directory. Then a background process copies the > password to the > places they need to be copied. > >-jim > > > >Mark C Smith wrote: > > > >>How common is the "multiple passwords" scenario in real world > deployments? My impression is that it is very rare. If so, I > am opposed to > doing extensive engineering and adding complexity for implementors and > users in order to support it. I think most people will be happy with a > password policy specification that only supports one password > attribute. > But if we really need support for more than one, I vote for the: > >> > >> pwdExpirationWarned;pwd-userPassword > >> pwdExpirationWarned;pwd-webPassword > >> > >>approach. If we require that all attribute types used in > conjunction with > password policy be registered with IANA, I don't think there > will be any > serious interoperability problems with this approach. > >> > >>-Mark Smith > >> Netscape > >> > >> > >>Jim Sermersheim wrote: > >> > >>>A group of people interested in progressing the password > policy draft > has been growing and exchanging emails off list. We're moving > discussion > here so we have a list and a wider audience. > >>> > >>>The current topic has to do with storing password policy state > information for objects. What is needed is a way to store values that > represent state information on an object. There is the need > to associate > the state information with a password. This is because it's > desirable to > allow multiple passwords per object, and it to be allowed > that policy can > be described and executed separately for each password. Thus, > we need a way > of associating each bit of password policy state information with the > password it applies to. > >>> > >>>For example. There is an attribute called pwdExpirationWarned. This > holds the timestamp of when the client was first warned that > the password > would expire soon, thus it is single-valued. Now, let's say > the object that > is subject to password policy makes use of three password > attributes due to > there being three different hard access interfaces: atmPassword, > telePassword, and webPassword (think bank account access). When the > pwdExpirationWarned attribute is updated (due to an impending > password > expiration), there needs to be some way of associating the > warning with the > password that will expire (let's say it's webPassword). > >>> > >>>Our first attempt was to use attribute descriptions with a > new tagging > option called "pwd-". In the example above, > pwdExpirationWarned;pwd-webPassword would be used to > store/retrieve the > warning time for the webPassword. The problem that was > brought up with this > approach (as I remember it) was that since the descr form of attribute > types is not canonical, we cannot use it in the attribute > option. It would > lead to interoperability problems. > >>> > >>>Quickly, it was suggested to just use the oid form of the attribute > type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the > problem above, it is an illegal encoding. Attribute options > are defined as > consisting of ALPHA, DIGIT, and DASH characters. > >>> > >>>Then the suggestion of moving the attribute association > inside the value > was put forth say something like "webPassword#200210240212Z". > This requires > new syntaxes which some implementors don't like, but worse: > 1) It doesn't > allow the attributes to be defined as single-value. 2) It > doesn't allow the > server to enforce uniqueness among the values. 3) It doesn't allow the > replace operation (where replace would work with > single-valued attributes). > None of these limitations are desirable. > >>> > >>>I would now like to suggest returning to the first or > second suggestion. > The first has limitations in a distributed environment, and > maybe something > can be done about it, but I'm not sure what. The second would > be modified > to fit the required syntax by replacing dots with dashes. > Thus the example > would change to: pwdExpirationWarned;pwd-1-2-3-4 > >>> > >>>Jim > >>> > >>>p.s. I can provide a set of recent previous discussions on this and > other issues to anyone that wants them. > >>> > >>>_______________________________________________ > >>>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 > > > > > >_______________________________________________ > >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 > > > > _______________________________________________ > 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 From ldapext-admin@ietf.org Wed Dec 4 07:39:02 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08058 for ; Wed, 4 Dec 2002 07:39:02 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ce3v14292; Wed, 4 Dec 2002 07:40:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Ccgv14208 for ; Wed, 4 Dec 2002 07:38:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07766; Wed, 4 Dec 2002 07:35:46 -0500 (EST) Message-Id: <200212041235.HAA07766@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 04 Dec 2002 07:35:45 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-rfc2596-03.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Language Tags and Ranges in LDAP Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-rfc2596-03.txt Pages : 15 Date : 2002-12-3 It is often desirable to to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-rfc2596-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-zeilenga-ldap-rfc2596-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-zeilenga-ldap-rfc2596-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: <2002-12-3142320.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-rfc2596-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-rfc2596-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-3142320.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Dec 4 10:47:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17569 for ; Wed, 4 Dec 2002 10:47:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FmNv27122; Wed, 4 Dec 2002 10:48:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Flav27069 for ; Wed, 4 Dec 2002 10:47:36 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17377 for ; Wed, 4 Dec 2002 10:44:41 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Dec 2002 08:47:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta Date: Tue, 03 Dec 2002 19:13:27 -0700 From: "Jim Sermersheim" To: , "Ed Reed" Cc: , , "Alan Clark" , "Hal Henderson" , , Subject: [ldapext] Re: Password policy state attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB4Flev27078 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I guess an unstated goal I've had in the back of my head is to do define the policy state data in such a way that most existing implementations could readilly adopt it. I'm not sure how important that goal is to the rest of the interested parties out there. I would call your ideas radical rather than crackpot--they have the feel of opening up other areas of possiblity. Jim >>> Ed Reed 11/22 12:43 PM >>> At the risk of sounding like a crackpot... You may need to consider something like the X.509 certificate object class discussed in PKIX - an entry with all the policy associated with the particular credential - in this case a password associated with an authentication identity. The X.500 object model used in LDAP simply doesn't make it easy to associate different policy values in one attribute with specific attribute values in another. Better to think of it this way - Each password and its policy is really a user identity with some refinements. That can be "security equivalent" to a particular user, or perhaps more correctly, the user entry can be "security equivalent" to the password used to log in. The logic to support such a thing would not be all that different from a login mechanism that allowed a user to select, from a list of allowed roles, those roles the user wanted to assume for a particular login session. It's messy, and fundamentally changes the way people think about identities and their credentials, but in a world where the same identity may use one of several credentials to authenticate, and if it's beneficial to associate different authorization rights with the individual based on which credential they used, it may be a necessary change to consider. Ed >>> "Jim Sermersheim" 11/22/02 12:16PM >>> A group of people interested in progressing the password policy draft has been growing and exchanging emails off list. We're moving discussion here so we have a list and a wider audience. The current topic has to do with storing password policy state information for objects. What is needed is a way to store values that represent state information on an object. There is the need to associate the state information with a password. This is because it's desirable to allow multiple passwords per object, and it to be allowed that policy can be described and executed separately for each password. Thus, we need a way of associating each bit of password policy state information with the password it applies to. For example. There is an attribute called pwdExpirationWarned. This holds the timestamp of when the client was first warned that the password would expire soon, thus it is single-valued. Now, let's say the object that is subject to password policy makes use of three password attributes due to there being three different hard access interfaces: atmPassword, telePassword, and webPassword (think bank account access). When the pwdExpirationWarned attribute is updated (due to an impending password expiration), there needs to be some way of associating the warning with the password that will expire (let's say it's webPassword). Our first attempt was to use attribute descriptions with a new tagging option called "pwd-". In the example above, pwdExpirationWarned;pwd-webPassword would be used to store/retrieve the warning time for the webPassword. The problem that was brought up with this approach (as I remember it) was that since the descr form of attribute types is not canonical, we cannot use it in the attribute option. It would lead to interoperability problems. Quickly, it was suggested to just use the oid form of the attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While this would solve the problem above, it is an illegal encoding. Attribute options are defined as consisting of ALPHA, DIGIT, and DASH characters. Then the suggestion of moving the attribute association inside the value was put forth say something like "webPassword#200210240212Z". This requires new syntaxes which some implementors don't like, but worse: 1) It doesn't allow the attributes to be defined as single-value. 2) It doesn't allow the server to enforce uniqueness among the values. 3) It doesn't allow the replace operation (where replace would work with single-valued attributes). None of these limitations are desirable. I would now like to suggest returning to the first or second suggestion. The first has limitations in a distributed environment, and maybe something can be done about it, but I'm not sure what. The second would be modified to fit the required syntax by replacing dots with dashes. Thus the example would change to: pwdExpirationWarned;pwd-1-2-3-4 Jim p.s. I can provide a set of recent previous discussions on this and other issues to anyone that wants them. _______________________________________________ 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 From ldapext-admin@ietf.org Wed Dec 4 10:47:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17591 for ; Wed, 4 Dec 2002 10:47:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FmEv27102; Wed, 4 Dec 2002 10:48:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FlZv27064 for ; Wed, 4 Dec 2002 10:47:35 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17375 for ; Wed, 4 Dec 2002 10:44:41 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Dec 2002 08:47:07 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta Date: Tue, 03 Dec 2002 19:00:08 -0700 From: "Jim Sermersheim" To: , Subject: Re: [ldapext] Re: Password policy state attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB4FlZv27065 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit >>> John McMeeking 12/03 7:40 AM >>> > >Several scenarios have been described which I think need to be clearly >distinguished: Yes, thank's John. >1. Multiple userPassword (or attribute) values. For example, an entry has >userPassword values "secret" and "anothersecret". I would prefer that >password policy attributes apply to the entire set of userPassword values. I would prefer that password policy is limited to be applied to only single-value password attributes. >I have a hard time with the notion that "secret" is valid and >"anothersecret" has been reset, or the notion of a single password being >locked. Trying to express that state would require tying the policy >attributes to individual values and likely that the user know passwords to >get the values or that the values be returned in clear text to make use of >the results. Try searching for all entries with expired passwords or >figuring out from the results which of the user's passwords were expired. I agree. >2. Multiple password attributes used by the server for authentication of a >single entry, as opposed to 3, below. I think this would require something >like simple bind using userPassword, DIGEST-MD5 using authPassword, ... >This seems like a bit of a stretch, but that may be just my limited >perspective. If this is a valid scenario, then I would prefer the approach >Mark Smith favored: > pwdExpirationWarned;pwd-userPassword Ok. This still allows #3, which is the actual use case that prompted the recent discussion of multiple passwords >If (2) is considered valid, should the passwordPolicyResponse control be >changed to indicate which password attribute the warning or error applied >to? Yes. >3. Multiple password attributes, where applications perform >authentication. For example, web app retrieves the webPassword attribute >and compares it to the user entered string. I don't see password policy >applying here. The server is not performing the authentication function >(no bind request), making the data no different than telephone numbers from >a directory server perspective. Ah, but the application is using the Compare operation. The request is that when password policy is applied to some attribute (that the server itself may never use for authN), that the password policy be applied to the Compare operation. This allows many applications to be written without all having to duplicate password policy checking/enforcement. >To summarize: >- The policy attributes like pwdExpirationWarned should apply to all >password values (possibly multiple values of a single attribute) for an >entry. I disagree here. Why not allow this to be per password attribute (ignoring the problem of multi-value attrs)? >I do not favor trying to support policy attributes for each >individual value of a single attribute. Right--that's ugly. >- I don't think multiple password attributes are likely to be used within >a single entry and used to support bind requests. I could be persuaded >otherwise, in which case I would like to see something like: > pwdExpirationWarned;pwd-userPassword I wouldn't want to ignore the possibility >John McMeeking Jim _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Dec 4 10:47:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17621 for ; Wed, 4 Dec 2002 10:47:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4FmOv27139; Wed, 4 Dec 2002 10:48:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4Flav27071 for ; Wed, 4 Dec 2002 10:47:36 -0500 Received: from prv-mail20.provo.novell.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17378 for ; Wed, 4 Dec 2002 10:44:41 -0500 (EST) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 04 Dec 2002 08:47:08 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.0 Beta Date: Tue, 03 Dec 2002 19:04:56 -0700 From: "Jim Sermersheim" To: , Cc: , , , "Alan Clark" , "Hal Henderson" , Subject: RE: [ldapext] Re: Password policy state attributes Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB4Flev27080 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit You're right. We need to decide what kinds of attributes to allow. There is also the question of whether or not to allow password policy to support multi-value password attributes. Personally, I'd rather restrict it to single-value attributes. As for values stored with options... I need to think more about it. Jim >>> "Andrew Sciberras" 12/02 8:59 PM >>> Hi I think that it is important to consider whether the Password Policy should be able to support password values that are stored using options ( Egg. userPassword;x-exampleOption ). If it should, then the password policy state attributes must use more than just the object identifier of the password attribute to make an association between the state information and the password value which it applies to. Andrew. > -----Original Message----- > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > Sent: Tuesday, 3 December 2002 14:08 > To: Jim Willeke > Cc: Mark C Smith; Jim Sermersheim; ldapext@ietf.org; > andrews@adacel.com.au; bcheckley@epresence.com; Alan Clark; Hal > Henderson > Subject: Re: [ldapext] Re: Password policy state attributes > > > The example you give is for multiple encodings of the same password, > not multiple passwords. I am sure there are real world examples > of multiple passwords. I've seen them to manage password transitions. > That is one might have both the new and old passwords stored in > userPassword during a transitional period. > > Then there is an issue of multiple password attributes (e.g. > userPassword v. authPassword). > > Personally, I think the password policy should minimally support > multiple values of userPassword... > > Kurt > > At 06:29 PM 2002-12-02, Jim Willeke wrote: > >As a "Real" worl example, we are using multiple password as > one is "sync'd" to an iPlanet server and is stored in sha-1 > format another is" sync'd" to a "home-grown" application and > is in MD-5 and then the third is the "normal" LDAP password. > > > >A reason we store them all in the directory ? The user goes > to one WEB site to chang e thier password and all passwords > are updated from the WEB sit eto the directory. Then a > background process copies the password to the places they > need to be copied. > >-jim > > > >Mark C Smith wrote: > > > >>How common is the "multiple passwords" scenario in real > world deployments? My impression is that it is very rare. If > so, I am opposed to doing extensive engineering and adding > complexity for implementors and users in order to support it. > I think most people will be happy with a password policy > specification that only supports one password attribute. But > if we really need support for more than one, I vote for the: > >> > >> pwdExpirationWarned;pwd-userPassword > >> pwdExpirationWarned;pwd-webPassword > >> > >>approach. If we require that all attribute types used in > conjunction with password policy be registered with IANA, I > don't think there will be any serious interoperability > problems with this approach. > >> > >>-Mark Smith > >> Netscape > >> > >> > >>Jim Sermersheim wrote: > >> > >>>A group of people interested in progressing the password > policy draft has been growing and exchanging emails off list. > We're moving discussion here so we have a list and a wider audience. > >>> > >>>The current topic has to do with storing password policy > state information for objects. What is needed is a way to > store values that represent state information on an object. > There is the need to associate the state information with a > password. This is because it's desirable to allow multiple > passwords per object, and it to be allowed that policy can be > described and executed separately for each password. Thus, we > need a way of associating each bit of password policy state > information with the password it applies to. > >>> > >>>For example. There is an attribute called > pwdExpirationWarned. This holds the timestamp of when the > client was first warned that the password would expire soon, > thus it is single-valued. Now, let's say the object that is > subject to password policy makes use of three password > attributes due to there being three different hard access > interfaces: atmPassword, telePassword, and webPassword (think > bank account access). When the pwdExpirationWarned attribute > is updated (due to an impending password expiration), there > needs to be some way of associating the warning with the > password that will expire (let's say it's webPassword). > >>> > >>>Our first attempt was to use attribute descriptions with a > new tagging option called "pwd-". In the example above, > pwdExpirationWarned;pwd-webPassword would be used to > store/retrieve the warning time for the webPassword. The > problem that was brought up with this approach (as I remember > it) was that since the descr form of attribute types is not > canonical, we cannot use it in the attribute option. It would > lead to interoperability problems. > >>> > >>>Quickly, it was suggested to just use the oid form of the > attribute type, like pwdExpirationWarned;pwd-1.2.3.4. While > this would solve the problem above, it is an illegal > encoding. Attribute options are defined as consisting of > ALPHA, DIGIT, and DASH characters. > >>> > >>>Then the suggestion of moving the attribute association > inside the value was put forth say something like > "webPassword#200210240212Z". This requires new syntaxes which > some implementors don't like, but worse: 1) It doesn't allow > the attributes to be defined as single-value. 2) It doesn't > allow the server to enforce uniqueness among the values. 3) > It doesn't allow the replace operation (where replace would > work with single-valued attributes). None of these > limitations are desirable. > >>> > >>>I would now like to suggest returning to the first or > second suggestion. The first has limitations in a distributed > environment, and maybe something can be done about it, but > I'm not sure what. The second would be modified to fit the > required syntax by replacing dots with dashes. Thus the > example would change to: pwdExpirationWarned;pwd-1-2-3-4 > >>> > >>>Jim > >>> > >>>p.s. I can provide a set of recent previous discussions on > this and other issues to anyone that wants them. > >>> > >>>_______________________________________________ > >>>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 > > > > > >_______________________________________________ > >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 From ldapext-admin@ietf.org Wed Dec 4 13:33:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27278 for ; Wed, 4 Dec 2002 13:33:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4IYjv09781; Wed, 4 Dec 2002 13:34:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB4IXqv09696 for ; Wed, 4 Dec 2002 13:33:52 -0500 Received: from pretender.boolean.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27119 for ; Wed, 4 Dec 2002 13:30:58 -0500 (EST) Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.12.6/8.12.5) with ESMTP id gB4IXl0a008654 for ; Wed, 4 Dec 2002 18:33:47 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <5.2.0.9.0.20021204102639.030647f8@127.0.0.1> X-Sender: kurt@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 04 Dec 2002 10:33:44 -0800 To: ldapext@ietf.org From: "Kurt D. Zeilenga" Subject: Re: [ldapext] Call for comments: Language Tags and Ranges in LDAP (RFC2596bis) In-Reply-To: <5.1.0.14.0.20021112225422.035409f8@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , draft-zeilenga-ldap-rfc2596-03.txt is now available and, I hope, addresses the comments I have received (privately and publicly). If I've missed something, please comment (privately or publicly) in the next few days. Thanks, Kurt At 10:54 PM 2002-11-12, Kurt D. Zeilenga wrote: >I have prepared: > Language Tags and Ranges in LDAP > draft-zeilenga-ldap-rfc2596-02.txt > >To ensure that this Individual submission is ready for IESG >consideration for publication as a Proposed Standard >(obsoleting RFC 2596), please review and comment before the >end of the month. > >Please send technical comments to this list. >Please send editorial comments directly to me. > >Thanks, Kurt > >_______________________________________________ >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 From ldapext-admin@ietf.org Thu Dec 5 09:08:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11899 for ; Thu, 5 Dec 2002 09:08:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5E9Lv25341; Thu, 5 Dec 2002 09:09:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5E8Cv25304 for ; Thu, 5 Dec 2002 09:08:12 -0500 Received: from junker.stroeder.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11800 for ; Thu, 5 Dec 2002 09:05:13 -0500 (EST) Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 39C8C1579D3; Thu, 5 Dec 2002 15:08:03 +0100 (CET) Message-ID: <3DEF5DC2.6040703@stroeder.com> Date: Thu, 05 Dec 2002 15:08:02 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jim Sermersheim Cc: andrews@adacel.com.au, Kurt@openldap.org, bcheckley@epresence.com, ldapext@ietf.org, mcs@netscape.com, Alan Clark , Hal Henderson , jim@willeke.com Subject: Re: [ldapext] Re: Password policy state attributes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jim Sermersheim wrote: > You're right. We need to decide what kinds of attributes to allow. There > is also the question of whether or not to allow password policy to > support multi-value password attributes. Personally, I'd rather restrict > it to single-value attributes. Personally I'd also like to restrict it to single-value attributes. This restriction simply should be made clear in the I-D and 99% of the people asking for password policy will be happy with it. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Dec 5 09:49:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14464 for ; Thu, 5 Dec 2002 09:49:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5Ep4v29123; Thu, 5 Dec 2002 09:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EoXv29092 for ; Thu, 5 Dec 2002 09:50:33 -0500 Received: from junker.stroeder.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14295 for ; Thu, 5 Dec 2002 09:47:39 -0500 (EST) Received: from stroeder.com (junker.stroeder.com [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 00C2F1579D3; Thu, 5 Dec 2002 15:50:26 +0100 (CET) Message-ID: <3DEF67B1.3020106@stroeder.com> Date: Thu, 05 Dec 2002 15:50:25 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Ludovic Poitou Cc: Jim Sermersheim , andrews@adacel.com.au, Kurt@openldap.org, bcheckley@epresence.com, ldapext@ietf.org, mcs@netscape.com, Alan Clark , Hal Henderson , jim@willeke.com Subject: Re: [ldapext] Re: Password policy state attributes References: <3DEF5DC2.6040703@stroeder.com> <3DEF610F.9030200@Sun.com> In-Reply-To: <3DEF610F.9030200@Sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5EoXv29093 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Ludovic Poitou wrote: > Michael Ströder wrote: > >> Jim Sermersheim wrote: >> >>> You're right. We need to decide what kinds of attributes to allow. There >>> is also the question of whether or not to allow password policy to >>> support multi-value password attributes. Personally, I'd rather restrict >>> it to single-value attributes. >> >> Personally I'd also like to restrict it to single-value attributes. >> >> This restriction simply should be made clear in the I-D and 99% of the >> people asking for password policy will be happy with it. > > The restriction is already in the I-D (it's a MUST) And I appreciate that! > but I agree that it could be made even more clear. Especially we have to decide now whether to debate this topic to dead still staying without standardized password policy for a long time or whether to accept the current draft and its current implementations. Personally I clearly vote for the second option. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Dec 5 10:48:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17063 for ; Thu, 5 Dec 2002 10:48:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5FnCv00841; Thu, 5 Dec 2002 10:49:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5EMcv26298 for ; Thu, 5 Dec 2002 09:22:38 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12549 for ; Thu, 5 Dec 2002 09:19:44 -0500 (EST) Received: from odin.France.Sun.COM ([129.157.174.8]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00396; Thu, 5 Dec 2002 07:22:09 -0700 (MST) Received: from Sun.com (bondi [129.157.192.47]) by odin.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id gB5EM8v07382; Thu, 5 Dec 2002 15:22:08 +0100 (MET) Message-ID: <3DEF610F.9030200@Sun.com> Date: Thu, 05 Dec 2002 15:22:07 +0100 From: Ludovic Poitou Organization: Sun Microsystems Inc. User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= CC: Jim Sermersheim , andrews@adacel.com.au, Kurt@openldap.org, bcheckley@epresence.com, ldapext@ietf.org, mcs@netscape.com, Alan Clark , Hal Henderson , jim@willeke.com Subject: Re: [ldapext] Re: Password policy state attributes References: <3DEF5DC2.6040703@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gB5EMcv26299 Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit The restriction is already in the I-D (it's a MUST) but I agree that it could be made even more clear. Ludovic. Michael Ströder wrote: > Jim Sermersheim wrote: > >> You're right. We need to decide what kinds of attributes to allow. There >> is also the question of whether or not to allow password policy to >> support multi-value password attributes. Personally, I'd rather restrict >> it to single-value attributes. > > > Personally I'd also like to restrict it to single-value attributes. > > This restriction simply should be made clear in the I-D and 99% of the > people asking for password policy will be happy with it. > > Ciao, Michael. > > _______________________________________________ > Ldapext mailing list > Ldapext@ietf.org > https://www1.ietf.org/mailman/listinfo/ldapext -- Ludovic Poitou Sun Microsystems Inc. Sun ONE products - Directory Server Group - Grenoble - France _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Dec 5 16:47:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01511 for ; Thu, 5 Dec 2002 16:47:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5LmDv25138; Thu, 5 Dec 2002 16:48:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gB5LkPv25088 for ; Thu, 5 Dec 2002 16:46:25 -0500 Received: from nexus.adacel.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01431 for ; Thu, 5 Dec 2002 16:43:27 -0500 (EST) Received: (qmail 17364 invoked from network); 5 Dec 2002 21:46:37 -0000 Received: from unknown (HELO shylock) (10.32.24.166) by nexus.adacel.com with SMTP; 5 Dec 2002 21:46:37 -0000 Reply-To: From: "Andrew Sciberras" To: "'Ludovic Poitou'" , "=?iso-8859-1?Q?'Michael_Str=F6der'?=" , "'Jim Sermersheim'" Cc: , , , , "'Alan Clark'" , "'Hal Henderson'" , , Date: Fri, 6 Dec 2002 08:45:05 +1100 Message-ID: <001601c29ca7$92bee250$a618200a@mtwav.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 In-Reply-To: <3DEF610F.9030200@Sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [ldapext] single-value vs. one value Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Guys, Jim, you have stated this in a past email: > Personally, I'd rather restrict it to single-value attributes. Michael, you have also stated something similar: > Personally I'd also like to restrict it to single-value attributes. And Ludovic, in your last email you have stated that the I-D already imposes the above restriction. I think that these posts use the term 'single-value' a little too loosely. Surely you don't really mean that the password policy can only be applied to SINGLE VALUE attributes, as this would rule out the userPassword attribute. In my opinion I think that Section 3.3 of the I-D clearly specifies how the password policy should be applied to attributes and their values. >3.3 Restriction of the Password Policy > >The password policy defined in this document can apply to any >attribute containing a password. Password policy state information >is held in the user's entry, and applies to a password attribute, >not a particular password attribute value. Thus the server SHOULD >enforce that the password attribute subject to password policy, >contains one and only one password value. Andrew. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Dec 12 08:06:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21762 for ; Thu, 12 Dec 2002 08:06:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCD6Zv17049; Thu, 12 Dec 2002 08:06:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gBCD4Jv16958 for ; Thu, 12 Dec 2002 08:04:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21467; Thu, 12 Dec 2002 08:01:20 -0500 (EST) Message-Id: <200212121301.IAA21467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ldapext@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 12 Dec 2002 08:01:19 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-rfc2596-04.txt Sender: ldapext-admin@ietf.org Errors-To: ldapext-admin@ietf.org X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: LDAP Extension Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Language Tags and Ranges in LDAP Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-rfc2596-04.txt Pages : 15 Date : 2002-12-11 It is often desirable to to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-rfc2596-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-zeilenga-ldap-rfc2596-04.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-zeilenga-ldap-rfc2596-04.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: <2002-12-11132651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-rfc2596-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-rfc2596-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-12-11132651.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext