From mailman-admin@ietf.org Sat Feb 1 10:12:16 2003 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 KAA07739 for ; Sat, 1 Feb 2003 10:12: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 h11FGIJ03483 for ; Sat, 1 Feb 2003 10:16:18 -0500 Date: Sat, 01 Feb 2003 10:16:18 -0500 Message-ID: <20030201151618.8821.62677.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 Fri Feb 14 12:23:55 2003 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 MAA27836 for ; Fri, 14 Feb 2003 12:23:55 -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 h1EHQfp09102; Fri, 14 Feb 2003 12:26:41 -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 h1EHNXp08954 for ; Fri, 14 Feb 2003 12:23:33 -0500 Received: from Tempo.Update.UU.SE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27761 for ; Fri, 14 Feb 2003 12:19:02 -0500 (EST) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante) with ESMTP id h1EHMmeC030877 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Feb 2003 18:22:48 +0100 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante-submit) id h1EHMmto030873; Fri, 14 Feb 2003 18:22:48 +0100 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15949.9703.800184.642767@Tempo.Update.UU.SE> Date: Fri, 14 Feb 2003 18:22:47 +0100 To: ldapext@ietf.org X-Mailer: VM 7.07 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1EHNXp08955 Subject: [ldapext] CLDAPv3 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 Greetings, I've noticed that the web page for ldapext working group mentions that the group will define connectionless LDAPv3; this is however not mentioned among the Goals and Milestones on the page, nor can I find anything about it anywhere, so I'm getting curious; is someone working on this, and in that case, how is it going; and if the project has been abandoned, why? It may be that CLDAP hasn't ever been much used, but to me, stressing the "Lightweight" in "LDAP", it seems quite useful for applications that just need to do very simple lookups now and then. So, what's happened to CLDAP? Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 14 12:30:16 2003 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 MAA28130 for ; Fri, 14 Feb 2003 12:30:15 -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 h1EHW4p09471; Fri, 14 Feb 2003 12:32: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 h1EHThp09320 for ; Fri, 14 Feb 2003 12:29:43 -0500 Received: from toad.mtbrook.boreham.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27887 for ; Fri, 14 Feb 2003 12:25:12 -0500 (EST) Received: from racoon (unknown [192.168.10.254]) by toad.mtbrook.boreham.org (Postfix) with ESMTP id BF6083F8B for ; Fri, 14 Feb 2003 09:30:46 -0800 (PST) Message-ID: <079201c2d44e$f0f57170$fe0aa8c0@mtbrook.boreham.org> From: "David Boreham" To: References: <15949.9703.800184.642767@Tempo.Update.UU.SE> Subject: Re: [ldapext] CLDAPv3 Date: Fri, 14 Feb 2003 09:31:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 > that just need to do very simple lookups now and then. So, what's > happened to CLDAP? To a first approximation: nobody needed it. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 14 14:28:40 2003 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 OAA01991 for ; Fri, 14 Feb 2003 14:28:40 -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 h1EJUWp17966; Fri, 14 Feb 2003 14:30:32 -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 h1EJR7p17855 for ; Fri, 14 Feb 2003 14:27:07 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01840 for ; Fri, 14 Feb 2003 14:22:50 -0500 (EST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h1EJO9u11130; Fri, 14 Feb 2003 20:24:09 +0100 Message-ID: <3E4D4259.3010500@it.su.se> Date: Fri, 14 Feb 2003 20:24:09 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Boreham CC: ldapext@ietf.org, thorild@update.uu.se Subject: Re: [ldapext] CLDAPv3 References: <15949.9703.800184.642767@Tempo.Update.UU.SE> <079201c2d44e$f0f57170$fe0aa8c0@mtbrook.boreham.org> In-Reply-To: <079201c2d44e$f0f57170$fe0aa8c0@mtbrook.boreham.org> 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 David Boreham wrote: >>that just need to do very simple lookups now and then. So, what's >>happened to CLDAP? >> >> > >To a first approximation: nobody needed it. > > >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext > > Yeah, basically. Me and Roland Hedberg were dumb enough to volounteer to "just fix" CLDAPv2 and get it done in time for ldapext closedown. By the time we had something written down nobody was interested enough to keep working on it. There is a reason for this though: The question is if you really need connectionless ldap. For doing lookups now and then you certainly don't need udp! You _might_ need udp if you are doing _lots_ of lookups all the time to lots of directory servers and can't do connection pooling. For instance a proxy/index server (lots of connections) or account management (e.g nss_ldap) for a workstation might benefit but you can certainly live without it. Doing ldap over sctp is another story, that might actually be useful if sctp ever takes off... Cheers Leif _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 14 18:05:08 2003 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 SAA08685 for ; Fri, 14 Feb 2003 18:05: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 h1EN7Dp01629; Fri, 14 Feb 2003 18:07:13 -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 h1EN4bp01174 for ; Fri, 14 Feb 2003 18:04:37 -0500 Received: from au.padl.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08538 for ; Fri, 14 Feb 2003 18:00:13 -0500 (EST) Received: (from lukeh@localhost) by au.padl.com (8.9.3/8.9.3) id KAA27315; Sat, 15 Feb 2003 10:03:50 +1100 (EST) From: Luke Howard Message-Id: <200302142303.KAA27315@au.padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Organization: PADL Software Pty Ltd To: thorild@Update.UU.SE Subject: Re: [ldapext] CLDAPv3 Cc: ldapext@ietf.org Reply-To: lukeh@PADL.COM Date: Sat, 15 Feb 2003 10:03:48 +1100 Versions: dmail (bsd44) 2.4c/makemail 2.9d 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: , Active Directory does use CLDAPv3, so I think it is worth documenting; it is on my todo list. Like RFC 1798, multiple LDAP messages are returned in a single PDU; however, AD does not wrap these in an ASN.1 sequence, but instead return them back-to-back. -- Luke >From: Thorild Selen >Subject: [ldapext] CLDAPv3 >To: ldapext@ietf.org >Date: Fri, 14 Feb 2003 18:22:47 +0100 > >Greetings, > >I've noticed that the web page for ldapext working group mentions that >the group will define connectionless LDAPv3; this is however not >mentioned among the Goals and Milestones on the page, nor can I find >anything about it anywhere, so I'm getting curious; is someone working >on this, and in that case, how is it going; and if the project has >been abandoned, why? > >It may be that CLDAP hasn't ever been much used, but to me, stressing >the "Lightweight" in "LDAP", it seems quite useful for applications >that just need to do very simple lookups now and then. So, what's >happened to CLDAP? > >Thorild Selén >Datorföreningen Update / Update Computer Club, Uppsala, SE >_______________________________________________ >Ldapext mailing list >Ldapext@ietf.org >https://www1.ietf.org/mailman/listinfo/ldapext -- Luke Howard | PADL Software Pty Ltd | www.padl.com _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 14 19:21:53 2003 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 TAA10353 for ; Fri, 14 Feb 2003 19:21:53 -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 h1F0OAp06804; Fri, 14 Feb 2003 19:24:10 -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 h1F0LIp06714 for ; Fri, 14 Feb 2003 19:21:18 -0500 Received: from Tempo.Update.UU.SE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10274 for ; Fri, 14 Feb 2003 19:16:55 -0500 (EST) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante) with ESMTP id h1F0KceC032122 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 15 Feb 2003 01:20:38 +0100 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante-submit) id h1F0KbOE032118; Sat, 15 Feb 2003 01:20:37 +0100 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15949.34773.8411.306762@Tempo.Update.UU.SE> Date: Sat, 15 Feb 2003 01:20:37 +0100 To: ldapext@ietf.org Subject: Re: [ldapext] CLDAPv3 In-Reply-To: <200302142303.KAA27315@au.padl.com> References: <200302142303.KAA27315@au.padl.com> X-Mailer: VM 7.07 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1F0LIp06715 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 Luke Howard writes: > Active Directory does use CLDAPv3, so I think it is worth documenting; > it is on my todo list. Right, so CLDAPv3 actually exists in practice, whether we choose to believe in it or not. (Of course, one could argue that it's not CLDAP, but just some ugly hack that happens to resemble CLDAP.) > Like RFC 1798, multiple LDAP messages are returned in a single PDU; > however, AD does not wrap these in an ASN.1 sequence, but instead > return them back-to-back. Is this how CLDAPv3 was meant to work? In any case, it should be easy for the server to look at the BER encoding of the request and see whether the client has wrapped the request in an ASN.1 sequence or not, and assume that it expects a reply on the same form; perhaps not pretty, but it should work. So, does anyone of you have anything vaguely resembling a draft spec on CLDAPv3? If so, does it address this issue of (possibly optional) sequence wrapping? Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Feb 17 14:46:32 2003 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 OAA29644 for ; Mon, 17 Feb 2003 14:46:32 -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 h1HJolp17972; Mon, 17 Feb 2003 14:50:47 -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 h1HJlhp17891 for ; Mon, 17 Feb 2003 14:47:43 -0500 Received: from Tempo.Update.UU.SE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29569 for ; Mon, 17 Feb 2003 14:41:57 -0500 (EST) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante) with ESMTP id h1HJjjeC001073 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 17 Feb 2003 20:45:45 +0100 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante-submit) id h1HJjjaL001070; Mon, 17 Feb 2003 20:45:45 +0100 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15953.15336.830720.986840@Tempo.Update.UU.SE> Date: Mon, 17 Feb 2003 20:45:44 +0100 To: ldapext@ietf.org Subject: Re: [ldapext] CLDAPv3 In-Reply-To: <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> X-Mailer: VM 7.07 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1HJlhp17892 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 Here are some thoughts about adapting CLDAP as in RFC1798 to LDAPv3. It is not to be taken as a draft of any kind, rather as a quick sketch. --- CLDAP as specified in RFC1798 allows only one request per datagram, only one response per datagram. We change this as follows: A datagram is allowed to contain: (optionally) one BindRequest or BindResponse. This must be the first element of the sequence when present. then zero or more of SearchResultEntry and SearchResultReference, followed by one SearchResultDone OR any single response of another kind (CompareResponse, extendedResponse) OR any single request other than BindRequest. (This is a minimalistic approach. Perhaps one would want to allow one or more extended operations in a datagram, possibly in combination with another operation.) Structure of the datagram: CLDAPMessage ::= SEQUENCE { messageID MessageID user LDAPDN, -- on request only -- protocolOP CHOICE { bindRequest BindRequest, bindResponse BindResponse, searchRequest SearchRequest, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, compareRequest CompareRequest, compareResponse CompareResponse, abandonRequest AbandonRequest, extendedReq ExtendedRequest, extendedResp ExtendedResponse }, controls [0] Controls OPTIONAL } All these are as defined in RFC2251 (LDAPv3) except: user: as in RFC1798 (CLDAP); for logging purposes or whatever. You're probably not going to trust this anyway. One possible use would be for abuse tracking, since a proxy could use it to tell you about the origin of the request. (But do you trust the proxy?) What's different? The following parts of LDAPv3 have a restricted usage or are left out for simplicity, or simply because they are not very useful for a connectionless transport: In the message: bindRequest, bindResponse, unbindRequest: One purpose of the bindRequest is for the client to tell the server which version of the LDAP protocol to use. A client should therefore be allowed to prefix a request with an anonymous bind request, in which case the reply should contain the corresponding bind response. SASL authentication is not available for connectionless transports. Unbinding or rebinding is not supported for CLDAP. modifyRequest, modifyResponse, addRequest, addResponse, delRequest, ddelREsponse, modDNRequest, modDNResponse: Updating operations are probably better left out, because of the security problems with UDP and similar connectionless protocols, and also because of the problems that duplicate or lost messages would introduce. These requests and their corresponding responses are therefore not available for CLDAP. extendedReq, extendedResp: Some extended operations will not be available for CLDAP; updating operations (for the reasons listed above) as well as other operations that are not meaningful in a connectionless context. ---- Comments are certainly welcome. Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Feb 17 16:55:06 2003 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 QAA02411 for ; Mon, 17 Feb 2003 16:55:06 -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 h1HLxIp26049; Mon, 17 Feb 2003 16:59: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 h1HLuwp25960 for ; Mon, 17 Feb 2003 16:56:58 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02282 for ; Mon, 17 Feb 2003 16:51:08 -0500 (EST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h1HLqSu01048; Mon, 17 Feb 2003 22:52:28 +0100 Message-ID: <3E51599C.6000708@it.su.se> Date: Mon, 17 Feb 2003 22:52:28 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thorild Selen CC: ldapext@ietf.org, roland@catalogix.se Subject: Re: [ldapext] CLDAPv3 References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> In-Reply-To: <15953.15336.830720.986840@Tempo.Update.UU.SE> Content-Type: multipart/mixed; boundary="------------020606000503010207090901" 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: , This is a multi-part message in MIME format. --------------020606000503010207090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thorild Selen wrote: >Here are some thoughts about adapting CLDAP as in RFC1798 to >LDAPv3. It is not to be taken as a draft of any kind, rather as a >quick sketch. > > > In the enclosed draft Roland and I tried to bring ldap/udp more in line with the rest of ldapv3. The problem (imho) with RFC1798 is that it is a completely separate protocol with totally different semantics from ldapv2 and certainly from ldapv3. Our idea was to create something which could be used in the same way as ldapv3. The idea is to keep ldap/udp very simple and require the use of extensions which provide a _limited_ form of safe delivery and/or authentication. Remember that if you wind up creating tcp you are probably doing something wrong. We never got around to specifying the extensions but a shared-secret HMAC across the PDU might be one of them. MVH leifj --------------020606000503010207090901 Content-Type: text/plain; name="draft-ietf-ldapext-ldapudp-00.txt" Content-Disposition: inline; filename="draft-ietf-ldapext-ldapudp-00.txt" Content-Transfer-Encoding: 7bit Network Working Group Johansson Internet-Draft Stockholm University Expires: November 8, 2001 Hedberg Catalogix May 10, 2001 Lightweight Directory Access Protocol over UDP/IP draft-ietf-ldapext-ldapudp-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 8, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes modifications to LDAP version 3[1] to allow transport of a subset of the LDAP protocol over UDP/IP. Johansson & Hedberg Expires November 8, 2001 [Page 1] Internet-Draft LDAPv3/UDP May 2001 Table of Contents 1. Overview and Rationale . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Elements and Result Codes . . . . . . . . . . . . . . . 4 3. Description of the protocol . . . . . . . . . . . . . . . . . . 5 4. Dealing with lost result PDUs: reuse of messageIDs . . . . . . . 6 5. Security considerations . . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9 Johansson & Hedberg Expires November 8, 2001 [Page 2] Internet-Draft LDAPv3/UDP May 2001 1. Overview and Rationale Using LDAP version 3[1] involves normal TCP/IP connection setup which for some applications may constitute undesirable overhead, especially in situations where only unauthenticated requests are performed. The typical use would be for fast light-weight read-only clients where the number of round-trips must be kept to a minimum or for clients which makes large numbers of requests to multiple LDAP servers. An example of the latter would be an LDAP server which maintains a CIP[6] index and provides chaining of requests to servers indexed by the mesh. Such a server will often have to maintain large numbers of tcp connections. Experience from the TISDAG[5] project has shown that even with relatively small indices and few concurrent clients to the index server the number of outgoing tcp connections may be very large. Johansson & Hedberg Expires November 8, 2001 [Page 3] Internet-Draft LDAPv3/UDP May 2001 2. Protocol Elements and Result Codes The protocol messages of LDAPv3/UDP are identical with those of LDAPv3 and each LDAPMessage is encoded and transmitted in a single UDP datagram. In addition a new result code is defined: connectionRequired (70??) The semantics of this result code is as follows: * Whenever a server implementing the protocol described in this draft or any protocol derived from this protocol receives a request it for some reason is unwilling or unable to perform over connection-less transport the server must return this result code. Typical examples for this are when the resultset is to large to fit into the biggest packet the network in use can support or when a client tries to do a bind but does not provide enough information for it to succeed * Whenever a client implementing the protocol described in this draft or any protocol derived from this protocol receives this result code the client must not retry the request using connection-less transport. Johansson & Hedberg Expires November 8, 2001 [Page 4] Internet-Draft LDAPv3/UDP May 2001 3. Description of the protocol Use of the LDAPv3 protocol over UDP means that protocol elements can become dropped, delayed or even duplicated by the transport layer. In order to deal with these situations clients and servers implementing this protocol must employ some means for detecting and/or retrying failed requests. Note that the search operation is slightly different in this respect. A SearchResultEntry or a SearchResultReference can become lost or duplicated withouth affecting the flow of requests and responses between the client and the server as long as the SearchResultDone packet is not lost. The loss of this packet would be indistinguishable from the situation where the search is still underway. Thus the delivery of the resultcode packets (including the ExtendedResponse) is different from the delivery of search result packets. Since the application may or may not care about actually receiving SearchResultEntry and SearchResultReference packets some method for ensuring the delivery of these may or may not be needed. The reason why the safe delivery of the result-code pdu is important can be illustrated with a simple example. Assume that a client issues an add operation for a new entry. This request is received by the server and the add operation is performed but the resultcode (SUCCESS) gets lost on its way to the client. If the client were to retry the operation by issuing the same add request under a new message id the result code would indicate a failure since the object already exists in the server. There are several possible mechanisms for solving the problems described above and a particular choice must be agreed upon by the client and server before using ldap over connection-less transports. The method by which a mechanism is selected is not covered by this document but may involve the client connecting to the server over tcp to read the root-DSE entry before using connection-less transport. This standard may be extended by specifying other mechanisms for safe delivery of protocol messages. Servers implementing this protocol SHOULD provide a protocol listener on port 389. How the existence of other protocol listeners are communicated to clients (server location) is not covered in this document. To be used over LDAPv3/UDP other extensions defined for LDAPv3 must be amended by text which explains how the controls and/or exops defined in the extension interact with LDAPv3/UDP. In particular, for each control that is marked critical by the extension the standard must explain how safe delivery of the pdu containing the control is ensured. Johansson & Hedberg Expires November 8, 2001 [Page 5] Internet-Draft LDAPv3/UDP May 2001 4. Dealing with lost result PDUs: reuse of messageIDs A simple method for sending and receiving protocol messages over lossy connection-less transport is reuse of messageIDs. Whenever a client times out before receiving a result PDU it is waiting for it may, using this mechanism, retry the same request using the same messageID as before. A server implementing reuse of messageIDs is required to maintain a cache (the size of which should be annonced in the rootDSE-object; see below) of recent result-codes for each source port and address. Consequently a client using this mechanism must bind to the local port before issuing requests so that a particular client process can be identified by the server. The client must not issue more operations at a time than the cachesize. A server implementing this mechanism must announce it by providing a value for the size of the result code cache in the root-DSE attribute LDAPResultCacheSize: ( NAME 'LDAPResultCacheSize' DESC 'The size of the per-client cache of resultcodes SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 EQUALITY 'integerMatch' NO-USER-MODIFICATION USAGE dSAOperation ) Note that this mechanism does not protect agains a third party inserting protocol messages. See the section on security considerations. Johansson & Hedberg Expires November 8, 2001 [Page 6] Internet-Draft LDAPv3/UDP May 2001 5. Security considerations Since SASL[3] is only defined for connection-oriented operation it is not possible to use SASL authentication with LDAPv3/UDP and a server must respond with an result code of connectionRequired (??) if a bind requesting SASL authentication is received. Mechanisms for safe delivery of protocol messages which do not protect against third-party attacks (inserting messages into the protocol stream) should not be used for update operations unless the underlying transport provides protection against such attacks. Johansson & Hedberg Expires November 8, 2001 [Page 7] Internet-Draft LDAPv3/UDP May 2001 References [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [2] Kent, S and R Atkinson, "Security Architecture for the Internet Protocol", November 1998. [3] Myers, J, "Simple Authentication and Security Layer (SASL)", October 1997. [4] Armijo, M. P., Esibov, L. and P. Leach, "Discovering LDAP Services with DNS", Internet-Draft draft-ietf-ldapext-locate-02, April 2000. [5] Hedberg, R and L Daigle, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)", January 2000. [6] Hedberg, R, "LDAPv2 client vs. the Index Mesh", RFC 2657, August 1999. Authors' Addresses Leif Johasson Stockholm University Stockholm SE-10691 Sweden Phone: +46 8 164541 EMail: leifj@it.su.se Roland Hedberg Catalogix Jegerveien 25 Oslo 0777 Norway Phone: +47 23082996 EMail: roland@catalogix.se Johansson & Hedberg Expires November 8, 2001 [Page 8] Internet-Draft LDAPv3/UDP May 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Johansson & Hedberg Expires November 8, 2001 [Page 9] --------------020606000503010207090901-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Feb 17 17:37:55 2003 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 RAA03012 for ; Mon, 17 Feb 2003 17:37:55 -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 h1HMgHp29595; Mon, 17 Feb 2003 17:42:17 -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 h1HMdjp29486 for ; Mon, 17 Feb 2003 17:39:45 -0500 Received: from Tempo.Update.UU.SE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02977 for ; Mon, 17 Feb 2003 17:33:56 -0500 (EST) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante) with ESMTP id h1HMbXeC028123 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 17 Feb 2003 23:37:33 +0100 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante-submit) id h1HMbXat028120; Mon, 17 Feb 2003 23:37:33 +0100 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15953.25644.56942.704051@Tempo.Update.UU.SE> Date: Mon, 17 Feb 2003 23:37:32 +0100 To: ldapext@ietf.org CC: roland@catalogix.se Subject: Re: [ldapext] CLDAPv3 In-Reply-To: <3E51599C.6000708@it.su.se> References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> X-Mailer: VM 7.07 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1HMdjp29487 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 [quoting draft-ietf-ldapext-ldapudp-00:] > [...] A server implementing reuse of messageIDs is required to > maintain a cache (the size of which should be annonced in the > rootDSE-object; see below) of recent result-codes for each > source port and address. Consequently a client using this > mechanism must bind to the local port before issuing requests so > that a particular client process can be identified by the > server. The client must not issue more operations at a time than > the cachesize. This approach has a few drawbacks: * The server is not stateless; it has to keep track of some data for each client. This means that it won't be as lightweight as CLDAP, from the server's point of view. * The client is required to keep track of the cache size of the server. This makes it less lightweight in another way; you have to start your communications with asking about the cache size. Avoiding this would be more useful, in my opinion. The big win with connectionless LDAP ought to be that it is even more lightweight than LDAP over TCP; no unneeded packages going back and forth, no extra state to maintain for the server. If that isn't so important, then you could just as well use LDAP over some connection-oriented protocol, such as TCP, instead. Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Feb 17 18:52:52 2003 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 SAA04269 for ; Mon, 17 Feb 2003 18:52:52 -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 h1HNvHp01067; Mon, 17 Feb 2003 18:57:17 -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 h1HNsjp01014 for ; Mon, 17 Feb 2003 18:54:45 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04185 for ; Mon, 17 Feb 2003 18:48:53 -0500 (EST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h1HNoEu01873; Tue, 18 Feb 2003 00:50:14 +0100 Message-ID: <3E517536.20902@it.su.se> Date: Tue, 18 Feb 2003 00:50:14 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thorild Selen CC: ldapext@ietf.org, roland@catalogix.se Subject: Re: [ldapext] CLDAPv3 References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> In-Reply-To: <15953.25644.56942.704051@Tempo.Update.UU.SE> 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 Thorild Selen wrote: >[quoting draft-ietf-ldapext-ldapudp-00:] > > > [...] A server implementing reuse of messageIDs is required to > > maintain a cache (the size of which should be annonced in the > > rootDSE-object; see below) of recent result-codes for each > > source port and address. Consequently a client using this > > mechanism must bind to the local port before issuing requests so > > that a particular client process can be identified by the > > server. The client must not issue more operations at a time than > > the cachesize. > >This approach has a few drawbacks: > > * The server is not stateless; it has to keep track of some data for > each client. This means that it won't be as lightweight as CLDAP, > from the server's point of view. > > Granted but that is hardly an issue with modern servers. > * The client is required to keep track of the cache size of the > server. This makes it less lightweight in another way; you have to > start your communications with asking about the cache size. > > I am not sure about that but even if it is true most clients start life by asking about various capabilities anyway... The usefullness of disconnected operation is (imho) all about managing large amounts of tcp connections or not. >Avoiding this would be more useful, in my opinion. The big win with >connectionless LDAP ought to be that it is even more lightweight than >LDAP over TCP; no unneeded packages going back and forth, no extra >state to maintain for the server. If that isn't so important, then you >could just as well use LDAP over some connection-oriented protocol, >such as TCP, instead. > > Again I don't agree that this is the point (if indeed there is a point) to this exercise. Cheers Leif _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Feb 18 20:01:45 2003 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 UAA13486 for ; Tue, 18 Feb 2003 20:01:45 -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 h1J11Dp09262; Tue, 18 Feb 2003 20:01: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 h1J0uKp09066 for ; Tue, 18 Feb 2003 19:56:20 -0500 Received: from Tempo.Update.UU.SE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13065 for ; Tue, 18 Feb 2003 19:49:56 -0500 (EST) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante) with ESMTP id h1J0rYeC024779 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 19 Feb 2003 01:53:34 +0100 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante-submit) id h1J0rXGC024773; Wed, 19 Feb 2003 01:53:33 +0100 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15954.54666.323549.882235@Tempo.Update.UU.SE> Date: Wed, 19 Feb 2003 01:53:30 +0100 To: ldapext@ietf.org CC: roland@catalogix.se Subject: Re: [ldapext] CLDAPv3 In-Reply-To: <3E517536.20902@it.su.se> References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> <3E517536.20902@it.su.se> X-Mailer: VM 7.07 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1J0uKp09067 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 Leif Johansson writes: > Thorild Selen wrote: > > * The server is not stateless; it has to keep track of some data for > > each client. This means that it won't be as lightweight as CLDAP, > > from the server's point of view. > > > Granted but that is hardly an issue with modern servers. That depends on how much you want it to scale, of course. For normal loads you are probably correct, whatever a "normal load" is. > I am not sure about that but even if it is true most clients start life > by asking > about various capabilities anyway... The usefullness of disconnected > operation > is (imho) all about managing large amounts of tcp connections or not. So with your proposal it will have to manage a large number of UDP "connections" instead. What you have described is not connectionless LDAP, but LDAPv3 over a connectionless transport. There are still connections in some sense, you just move the job of managing the connections from one layer to another, probably with some gains depending on how lousy your TCP/IP implementation is. (If it is so troublesome to manage many simultaneous TCP connections, then maybe one should ask why; the state for managing a TCP connection might well be smaller than the data you have to keep track of for each client using your LDAP/UDP. If LDAP/UDP is still that much better -- perhaps your implementation of TCP is the culprit, rather than LDAP.) > >Avoiding this would be more useful, in my opinion. The big win with > >connectionless LDAP ought to be that it is even more lightweight than > >LDAP over TCP; no unneeded packages going back and forth, no extra > >state to maintain for the server. If that isn't so important, then you > >could just as well use LDAP over some connection-oriented protocol, > >such as TCP, instead. > > > Again I don't agree that this is the point (if indeed there is a point) > to this > exercise. Perhaps we're talking past each other, since we seem to have different goals in the first place; you want to run LDAPv3 (as true to the original as possible) over UDP, while I'm looking for an extremely lightweight protocol for directory lookups. (That's the point, and that was the point for CLDAP as described by RFC1798.) These goals are close to each other but different; the most appropriate solutions may therefore be different. Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Tue Feb 18 21:30:07 2003 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 VAA15434 for ; Tue, 18 Feb 2003 21:30:07 -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 h1J2Vip14856; Tue, 18 Feb 2003 21:31:44 -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 h1J2S0p14637 for ; Tue, 18 Feb 2003 21:28:00 -0500 Received: from web40808.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15197 for ; Tue, 18 Feb 2003 21:21:37 -0500 (EST) Message-ID: <20030219022525.98222.qmail@web40808.mail.yahoo.com> Received: from [66.117.214.65] by web40808.mail.yahoo.com via HTTP; Tue, 18 Feb 2003 18:25:25 PST Date: Tue, 18 Feb 2003 18:25:25 -0800 (PST) From: "sreekantan, vijay" To: ldapext@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-174707324-1045621525=:98050" Subject: [ldapext] Password policies in LDAP 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: , --0-174707324-1045621525=:98050 Content-Type: text/plain; charset=us-ascii I was trying to understand more about standards related to Password Policies in LDAP servers. I found that there was an internet draft written by a group of people from Sun MicroSystems. draft-behera-ldap-password-policy-06.txt was the draft file name. I also found that this draft has been expired and was not made an RFC. My question is if there is any standard on the password policies that LDAP vendors should support. Is there any information regarding this. What happens to expired drafts. If anybody could provide some information on this topic, it will be greatly helpful. Regards Vijay --------------------------------- Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day --0-174707324-1045621525=:98050 Content-Type: text/html; charset=us-ascii I was trying to understand more about standards related to Password Policies in LDAP servers. I found that there was an internet draft written by a group of people from Sun MicroSystems.
draft-behera-ldap-password-policy-06.txt was the draft file name.
I also found that this draft has been expired and was not made an RFC. My question is if there is any standard on the password policies that LDAP vendors should support. Is there any information regarding this. What happens to expired drafts. If anybody could provide some information on this topic, it will be greatly helpful.
Regards
Vijay


Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day --0-174707324-1045621525=:98050-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Feb 19 04:58:25 2003 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 EAA17457 for ; Wed, 19 Feb 2003 04:58:25 -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 h1JA0Ip24770; Wed, 19 Feb 2003 05:00: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 h1J9vip24644 for ; Wed, 19 Feb 2003 04:57:44 -0500 Received: from ohsmtp03.ogw.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17187 for ; Wed, 19 Feb 2003 04:51:11 -0500 (EST) Received: from willeke.com (dhcp024-166-083-155.neo.rr.com [24.166.83.155]) by ohsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h1J9t0Ht016697; Wed, 19 Feb 2003 04:55:01 -0500 (EST) Message-ID: <3E5353B7.7080309@willeke.com> Date: Wed, 19 Feb 2003 04:51:51 -0500 From: Jim Willeke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20021224 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sreekantan, vijay" CC: ldapext@ietf.org Subject: Re: [ldapext] Password policies in LDAP References: <20030219022525.98222.qmail@web40808.mail.yahoo.com> In-Reply-To: <20030219022525.98222.qmail@web40808.mail.yahoo.com> 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 Have you seen Kurt's stuff ? http://www.faqs.org/rfcs/rfc3062.html http://www.faqs.org/rfcs/rfc3112.html -jim sreekantan, vijay wrote: > I was trying to understand more about standards related to Password > Policies in LDAP servers. I found that there was an internet draft > written by a group of people from Sun MicroSystems. > draft-behera-ldap-password-policy-06.txt was the draft file name. > I also found that this draft has been expired and was not made an RFC. > My question is if there is any standard on the password policies that > LDAP vendors should support. Is there any information regarding this. > What happens to expired drafts. If anybody could provide some > information on this topic, it will be greatly helpful. > Regards > Vijay > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Shopping > > - Send Flowers for Valentine's Day _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Feb 19 06:42:45 2003 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 GAA19390 for ; Wed, 19 Feb 2003 06:42:45 -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 h1JBiNp00746; Wed, 19 Feb 2003 06:44: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 h1JAnmp28896 for ; Wed, 19 Feb 2003 05:49:48 -0500 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18232 for ; Wed, 19 Feb 2003 05:43:13 -0500 (EST) Received: from odin.France.Sun.COM ([129.157.174.8]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02301; Wed, 19 Feb 2003 03:47:02 -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 h1JAl1112343; Wed, 19 Feb 2003 11:47:01 +0100 (MET) Message-ID: <3E5360A5.5060900@Sun.com> Date: Wed, 19 Feb 2003 11:47:01 +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: "sreekantan, vijay" CC: ldapext@ietf.org Subject: Re: [ldapext] Password policies in LDAP References: <20030219022525.98222.qmail@web40808.mail.yahoo.com> 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 We should publish a new version of the draft... There is interest to have this effort progressed. Some of the issues have not been solved yet. Regards, Ludovic Poitou. sreekantan, vijay wrote: > I was trying to understand more about standards related to Password > Policies in LDAP servers. I found that there was an internet draft > written by a group of people from Sun MicroSystems. > draft-behera-ldap-password-policy-06.txt was the draft file name. > I also found that this draft has been expired and was not made an RFC. > My question is if there is any standard on the password policies that > LDAP vendors should support. Is there any information regarding this. > What happens to expired drafts. If anybody could provide some > information on this topic, it will be greatly helpful. > Regards > Vijay > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Shopping > > - Send Flowers for Valentine's Day -- 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 Feb 20 11:49:41 2003 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 LAA20989 for ; Thu, 20 Feb 2003 11:49:40 -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 h1KGpcp27701; Thu, 20 Feb 2003 11:51:38 -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 h1KGlop27394 for ; Thu, 20 Feb 2003 11:47:50 -0500 Received: from matrixmail.matrixone.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20560 for ; Thu, 20 Feb 2003 11:40:39 -0500 (EST) Received: from msx2am.matrixone.net by matrixmail.matrixone.net (8.10.1/8.10.1) with ESMTP id h1KGiOh16078; Thu, 20 Feb 2003 11:44:25 -0500 (EST) Received: by msx2am.matrixone.net with Internet Mail Service (5.5.2653.19) id <1V5NDNSW>; Thu, 20 Feb 2003 11:44:24 -0500 Message-ID: <9150DCE0CCB4D411A7DB00508BB0DBF205208470@msx1am.matrixone.net> From: "Dyer, Kevin" To: "'Jim Willeke'" , "sreekantan, vijay" Cc: ldapext@ietf.org Subject: RE: [ldapext] Password policies in LDAP Date: Thu, 20 Feb 2003 11:43:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D8FF.3951AFB0" 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D8FF.3951AFB0 Content-Type: text/plain; charset="iso-8859-1" Jim, These two RFC's do not address a number of issues that are discussed in the draft; for instance the number of invalid login attempts, account lockout, password checking, and password reuse. A large number of companies are moving toward LDAP as their primary authentication mechanism for desktop and network based applications. The Directory server must be able to address issues related to password management and user control. Leaving it up to the client is not an option anymore. I know that at least one company is changing their Directory server to implement most of this draft as they recognize the direction industry is taking. Kevin ____________________________________________ Kevin J. Dyer Sr. Technologist, Product Management kevin.dyer@matrixone.com TEL: 978-322-2011 FAX: 978-441-0078 MOBILE: 978-549-0971 MatrixOne, Inc. 210 Littleton Rd Westford, MA 01886 USA www.matrixone.com "Changing the way the world brings products to market" (tm) ____________________________________________ >-----Original Message----- >From: Jim Willeke [mailto:jim@willeke.com] >Sent: Wednesday, February 19, 2003 4:52 AM >To: sreekantan, vijay >Cc: ldapext@ietf.org >Subject: Re: [ldapext] Password policies in LDAP > > >Have you seen Kurt's stuff ? >http://www.faqs.org/rfcs/rfc3062.html > >http://www.faqs.org/rfcs/rfc3112.html >-jim > >sreekantan, vijay wrote: > >> I was trying to understand more about standards related to >Password >> Policies in LDAP servers. I found that there was an internet draft >> written by a group of people from Sun MicroSystems. >> draft-behera-ldap-password-policy-06.txt was the draft file name. >> I also found that this draft has been expired and was not >made an RFC. >> My question is if there is any standard on the password >policies that >> LDAP vendors should support. Is there any information >regarding this. >> What happens to expired drafts. If anybody could provide some >> information on this topic, it will be greatly helpful. >> Regards >> Vijay >> >> >> >------------------------------------------------------------- >----------- >> Do you Yahoo!? >> Yahoo! Shopping >> > > - Send Flowers for Valentine's Day _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext ------_=_NextPart_001_01C2D8FF.3951AFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [ldapext] Password policies in LDAP

Jim,

These two RFC's do not address a number of issues = that are discussed in the draft; for instance the number of invalid = login attempts, account lockout, password checking, and password reuse. = A large number of companies are moving toward LDAP as their primary = authentication mechanism for desktop and network based applications. = The Directory server must be able to address issues related to password = management and user control. Leaving it up to the client is not an = option anymore. I know that at least one company is changing their = Directory server to implement most of this draft as they recognize the = direction industry is taking.

        =         Kevin

____________________________________________
Kevin J. Dyer
Sr. Technologist, Product Management
kevin.dyer@matrixone.com

TEL:     978-322-2011
FAX:     978-441-0078
MOBILE:  978-549-0971

MatrixOne, Inc.
210 Littleton Rd
Westford, MA  01886  USA
www.matrixone.com

"Changing the way the world brings products to = market" (tm)
____________________________________________
 

  >-----Original Message-----
  >From: Jim Willeke [mailto:jim@willeke.com]
  >Sent: Wednesday, February 19, 2003 4:52 = AM
  >To: sreekantan, vijay
  >Cc: ldapext@ietf.org
  >Subject: Re: [ldapext] Password policies = in LDAP
  >
  >
  >Have you seen Kurt's stuff ?
  >http://www.faqs.org/rfcs/rfc3062.html
  >
  >http://www.faqs.org/rfcs/rfc3112.html
  >-jim
  >
  >sreekantan, vijay wrote:
  >
  >> I was trying to understand more = about standards related to
  >Password
  >> Policies in LDAP servers. I found = that there was an internet draft
  >> written by a group of people from = Sun MicroSystems.
  >> = draft-behera-ldap-password-policy-06.txt was the draft file = name.
  >> I also found that this draft has = been expired and was not
  >made an RFC.
  >> My question is if there is any = standard on the password
  >policies that
  >> LDAP vendors should support. Is = there any information
  >regarding this.
  >> What happens to expired drafts. If = anybody could provide some
  >> information on this topic, it will = be greatly helpful.
  >> Regards
  >> Vijay
  >>
  >>
  >>
  = >-------------------------------------------------------------=
  >-----------
  >> Do you Yahoo!?
  >> Yahoo! Shopping
  >>
  ><http://rd.yahoo.com/O=3D1/I=3Dbrandr/vday03/text/flow/= *http://sh
opping.yahoo.com%0A/shop?d=3Dbrowse&id=3D20146735> =
> - Send Flowers for Valentine's Day


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext

------_=_NextPart_001_01C2D8FF.3951AFB0-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Thu Feb 20 18:15:35 2003 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 SAA03023 for ; Thu, 20 Feb 2003 18:15:35 -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 h1KNICp24931; Thu, 20 Feb 2003 18:18: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 h1KNFKp24845 for ; Thu, 20 Feb 2003 18:15:20 -0500 Received: from web40810.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02925 for ; Thu, 20 Feb 2003 18:08:01 -0500 (EST) Message-ID: <20030220231151.44372.qmail@web40810.mail.yahoo.com> Received: from [216.68.234.32] by web40810.mail.yahoo.com via HTTP; Thu, 20 Feb 2003 15:11:51 PST Date: Thu, 20 Feb 2003 15:11:51 -0800 (PST) From: "sreekantan, vijay" Subject: RE: [ldapext] Password policies in LDAP To: kevin.dyer@matrixone.com, jim@willeke.com Cc: ldapext@ietf.org In-Reply-To: <9150DCE0CCB4D411A7DB00508BB0DBF205208470@msx1am.matrixone.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-484307133-1045782711=:44234" 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: , --0-484307133-1045782711=:44234 Content-Type: text/plain; charset=us-ascii Leaving it to the client (client of the LDAP server) requires us to implement policies in multiple platforms/clients which is a very bad and infeasible decision. I agree with Kevin that there should be some standards. I am just searching for the standards to prove some concepts in a security architecture project I am working on. Vijay "Dyer, Kevin" wrote: Jim, These two RFC's do not address a number of issues that are discussed in the draft; for instance the number of invalid login attempts, account lockout, password checking, and password reuse. A large number of companies are moving toward LDAP as their primary authentication mechanism for desktop and network based applications. The Directory server must be able to address issues related to password management and user control. Leaving it up to the client is not an option anymore. I know that at least one company is changing their Directory server to implement most of this draft as they recognize the direction industry is taking. Kevin ____________________________________________ Kevin J. Dyer Sr. Technologist, Product Management kevin.dyer@matrixone.com TEL: 978-322-2011 FAX: 978-441-0078 MOBILE: 978-549-0971 MatrixOne, Inc. 210 Littleton Rd Westford, MA 01886 USA www.matrixone.com "Changing the way the world brings products to market" (tm) ____________________________________________ >-----Original Message----- >From: Jim Willeke [mailto:jim@willeke.com] >Sent: Wednesday, February 19, 2003 4:52 AM >To: sreekantan, vijay >Cc: ldapext@ietf.org >Subject: Re: [ldapext] Password policies in LDAP > > >Have you seen Kurt's stuff ? >http://www.faqs.org/rfcs/rfc3062.html > >http://www.faqs.org/rfcs/rfc3112.html >-jim > >sreekantan, vijay wrote: > >> I was trying to understand more about standards related to >Password >> Policies in LDAP servers. I found that there was an internet draft >> written by a group of people from Sun MicroSystems. >> draft-behera-ldap-password-policy-06.txt was the draft file name. >> I also found that this draft has been expired and was not >made an RFC. >> My question is if there is any standard on the password >policies that >> LDAP vendors should support. Is there any information >regarding this. >> What happens to expired drafts. If anybody could provide some >> information on this topic, it will be greatly helpful. >> Regards >> Vijay >> >> >> >------------------------------------------------------------- >----------- >> Do you Yahoo!? >> Yahoo! Shopping >> > > - Send Flowers for Valentine's Day _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --0-484307133-1045782711=:44234 Content-Type: text/html; charset=us-ascii

Leaving it to the client (client of the LDAP server) requires us to implement policies in multiple platforms/clients which is a very bad and infeasible decision. I agree with Kevin that there should be some standards. I am just searching for the standards to prove some concepts in a security architecture project I am working on.
Vijay

 "Dyer, Kevin" <kevin.dyer@matrixone.com> wrote:

Jim,

These two RFC's do not address a number of issues that are discussed in the draft; for instance the number of invalid login attempts, account lockout, password checking, and password reuse. A large number of companies are moving toward LDAP as their primary authentication mechanism for desktop and network based applications. The Directory server must be able to address issues related to password management and user control. Leaving it up to the client is not an option anymore. I know that at least one company is changing their Directory server to implement most of this draft as they recognize the direction industry is taking.

                Kevin

____________________________________________
Kevin J. Dyer
Sr. Technologist, Product Management
kevin.dyer@matrixone.com

TEL:     978-322-2011
FAX:     978-441-0078
MOBILE:  978-549-0971

MatrixOne, Inc.
210 Littleton Rd
Westford, MA  01886  USA
www.matrixone.com

"Changing the way the world brings products to market" (tm)
____________________________________________
 

  >-----Original Message-----
  >From: Jim Willeke [mailto:jim@willeke.com]
  >Sent: Wednesday, February 19, 2003 4:52 AM
  >To: sreekantan, vijay
  >Cc: ldapext@ietf.org
  >Subject: Re: [ldapext] Password policies in LDAP
  >
  >
  >Have you seen Kurt's stuff ?
  >http://www.faqs.org/rfcs/rfc3062.html
  >
  >http://www.faqs.org/rfcs/rfc3112.html
  >-jim
  >
  >sreekantan, vijay wrote:
  >
  >> I was trying to understand more about standards related to
  >Password
  >> Policies in LDAP servers. I found that there was an internet draft
  >> written by a group of people from Sun MicroSystems.
  >> draft-behera-ldap-password-policy-06.txt was the draft file name.
  >> I also found that this draft has been expired and was not
  >made an RFC.
  >> My question is if there is any standard on the password
  >policies that
  >> LDAP vendors should support. Is there any information
  >regarding this.
&nb! sp; >> What happens to expired drafts. If anybody could provide some
  >> information on this topic, it will be greatly helpful.
  >> Regards
  >> Vijay
  >>
  >>
  >>
  >-------------------------------------------------------------
  >-----------
  >> Do you Yahoo!?
  >> Yahoo! Shopping
  >>
  ><http://rd.yahoo.com/O=1/I=brandr/vday03/text/flow/*http://sh
opping.yahoo.com%0A/shop?d=browse&id=20146735>
> - Send Flowers for Valentine's Day


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext


Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --0-484307133-1045782711=:44234-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 21 02:04:45 2003 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 CAA17486 for ; Fri, 21 Feb 2003 02:04: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 h1L7AHp24776; Fri, 21 Feb 2003 02:10:17 -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 h1L4sDp12073 for ; Thu, 20 Feb 2003 23:54:13 -0500 Received: from palrel13.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09413 for ; Thu, 20 Feb 2003 23:46:46 -0500 (EST) Received: from raptor.cup.hp.com (raptor.cup.hp.com [15.13.130.223]) by palrel13.hp.com (Postfix) with ESMTP id B35A71C0101F; Thu, 20 Feb 2003 20:50:37 -0800 (PST) Received: from narn (pal2nai168175.nsr.hp.com [15.244.168.175]) by raptor.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with SMTP id UAA01815; Thu, 20 Feb 2003 20:50:33 -0800 (PST) Reply-To: From: "Bob Joslin" To: "sreekantan, vijay" , , Cc: Subject: RE: [ldapext] Password policies in LDAP Date: Thu, 20 Feb 2003 20:50:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C2D921.B2A60C90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030220231151.44372.qmail@web40810.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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: , This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2D921.B2A60C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I completely agree. And I too would like to see the password policy draft progress in some form or other. Bob -----Original Message----- From: ldapext-admin@ietf.org [mailto:ldapext-admin@ietf.org]On Behalf Of sreekantan, vijay Sent: Thursday, February 20, 2003 3:12 PM To: kevin.dyer@matrixone.com; jim@willeke.com Cc: ldapext@ietf.org Subject: RE: [ldapext] Password policies in LDAP Leaving it to the client (client of the LDAP server) requires us to implement policies in multiple platforms/clients which is a very bad and infeasible decision. I agree with Kevin that there should be some standards. I am just searching for the standards to prove some concepts in a security architecture project I am working on. Vijay "Dyer, Kevin" wrote: Jim, These two RFC's do not address a number of issues that are discussed in the draft; for instance the number of invalid login attempts, account lockout, password checking, and password reuse. A large number of companies are moving toward LDAP as their primary authentication mechanism for desktop and network based applications. The Directory server must be able to address issues related to password management and user control. Leaving it up to the client is not an option anymore. I know that at least one company is changing their Directory server to implement most of this draft as they recognize the direction industry is taking. Kevin ____________________________________________ Kevin J. Dyer Sr. Technologist, Product Management kevin.dyer@matrixone.com TEL: 978-322-2011 FAX: 978-441-0078 MOBILE: 978-549-0971 MatrixOne, Inc. 210 Littleton Rd Westford, MA 01886 USA www.matrixone.com "Changing the way the world brings products to market" (tm) ____________________________________________ >-----Original Message----- >From: Jim Willeke [mailto:jim@willeke.com] >Sent: Wednesday, February 19, 2003 4:52 AM >To: sreekantan, vijay >Cc: ldapext@ietf.org >Subject: Re: [ldapext] Password policies in LDAP > > >Have you seen Kurt's stuff ? >http://www.faqs.org/rfcs/rfc3062.html > >http://www.faqs.org/rfcs/rfc3112.html >-jim > >sreekantan, vijay wrote: > >> I was trying to understand more about standards related to >Password >> Policies in LDAP servers. I found that there was an internet draft >> written by a group of people from Sun MicroSystems. >> draft-behera-ldap-password-policy-06.txt was the draft file name. >> I also found that this draft has been expired and was not >made an RFC. >> My question is if there is any standard on the password >policies that >> LDAP vendors should support. Is there any information >regarding this. &nb! sp; >> What happens to expired drafts. If anybody could provide some >> information on this topic, it will be greatly helpful. >> Regards >> Vijay >> >> >> >------------------------------------------------------------- >----------- >> Do you Yahoo!? >> Yahoo! Shopping >> > > - Send Flowers for Valentine's Day _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext ---------------------------------------------------------------------------- -- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more ------=_NextPart_000_0000_01C2D921.B2A60C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I completely agree.  And I too would like to see the = password policy=20 draft progress in some form or other.
 
Bob
-----Original Message-----
From: = ldapext-admin@ietf.org=20 [mailto:ldapext-admin@ietf.org]On Behalf Of sreekantan,=20 vijay
Sent: Thursday, February 20, 2003 3:12 = PM
To:=20 kevin.dyer@matrixone.com; jim@willeke.com
Cc:=20 ldapext@ietf.org
Subject: RE: [ldapext] Password policies in = LDAP

Leaving it to the client (client of the LDAP = server) requires us=20 to implement policies in multiple platforms/clients which is a very = bad and=20 infeasible decision. I agree with Kevin that there should be some = standards. I=20 am just searching for the standards to prove some concepts in a = security=20 architecture project I am working on.
Vijay=20

 "Dyer, Kevin" <kevin.dyer@matrixone.com> = wrote:=20

Jim,

These two RFC's do not address a number of issues = that are=20 discussed in the draft; for instance the number of invalid login = attempts,=20 account lockout, password checking, and password reuse. A large = number of=20 companies are moving toward LDAP as their primary authentication = mechanism=20 for desktop and network based applications. The Directory server = must be=20 able to address issues related to password management and user = control.=20 Leaving it up to the client is not an option anymore. I know that at = least=20 one company is changing their Directory server to implement most of = this=20 draft as they recognize the direction industry is taking.

       =20         Kevin

____________________________________________=20
Kevin J. Dyer
Sr.=20 Technologist, Product Management
kevin.dyer@matrixone.com

TEL:     978-322-2011 =
FAX:     978-441-0078
MOBILE:  978-549-0971

MatrixOne, Inc.
210 = Littleton=20 Rd
Westford, MA  01886  = USA=20
www.matrixone.com

"Changing the way the world brings products to = market"=20 (tm)
____________________________________________ =
 

  >-----Original Message----- =
  >From: Jim Willeke [mailto:jim@willeke.com] =
  >Sent: Wednesday, February 19, 2003 4:52 = AM=20
  >To: sreekantan, vijay
  >Cc: ldapext@ietf.org
 =20 >Subject: Re: [ldapext] Password policies in LDAP =
  >
  > =
  >Have you seen Kurt's stuff ?
  >http://www.faqs.org/rfcs/rfc3062.html =
  >
  >http://www.faqs.org/rfcs/rfc3112.html =
  >-jim
  = >
  >sreekantan, vijay wrote:
  >
  >> I was = trying to=20 understand more about standards related to
 =20 >Password
  >> Policies in = LDAP=20 servers. I found that there was an internet draft
  >> written by a group of people from Sun=20 MicroSystems.
  >>=20 draft-behera-ldap-password-policy-06.txt was the draft file = name.=20
  >> I also found that this draft has = been=20 expired and was not
  >made an = RFC.=20
  >> My question is if there is = any=20 standard on the password
  = >policies that=20
  >> LDAP vendors should = support. Is=20 there any information
  >regarding = this.=20
&nb! sp; >> What happens to = expired=20 drafts. If anybody could provide some
 =20 >> information on this topic, it will be greatly = helpful.=20
  >> Regards
 =20 >> Vijay
  >> =
  >>
  >>=20
 =20 = >------------------------------------------------------------- =
  >-----------
 =20 >> Do you Yahoo!?
  >> = Yahoo!=20 Shopping
  >>
  ><http://rd.yahoo.com/O=3D1/I=3Dbrandr/vday03/text/flow/*ht= tp://sh=20
opping.yahoo.com%0A/shop?d=3Dbrowse&id=3D20146735>=20
> - Send Flowers for Valentine's Day=20


_______________________________________________=20
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext= =20


Do you Yahoo!?
Yahoo!=20 Tax Center - forms, calculators, tips, and = more ------=_NextPart_000_0000_01C2D921.B2A60C90-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 21 04:54:45 2003 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 EAA24562 for ; Fri, 21 Feb 2003 04:54:45 -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 h1LA0ap08475; Fri, 21 Feb 2003 05:00:36 -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 h1L9vWp08334 for ; Fri, 21 Feb 2003 04:57:32 -0500 Received: from web13302.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24467 for ; Fri, 21 Feb 2003 04:50:02 -0500 (EST) Message-ID: <20030221095352.28838.qmail@web13302.mail.yahoo.com> Received: from [193.41.96.45] by web13302.mail.yahoo.com via HTTP; Fri, 21 Feb 2003 01:53:52 PST Date: Fri, 21 Feb 2003 01:53:52 -0800 (PST) From: Allan Clarke To: ldapext@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1440027224-1045821232=:28769" Subject: [ldapext] LDAP - password in history 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: , --0-1440027224-1045821232=:28769 Content-Type: text/plain; charset=us-ascii Hi everybody, My application is written in ColdFusion. We are using LDAP to authenticate users and have a strict password policy. The password expire in 30 days, a warning message is sent to the user 7 days before the password expires. LDAP also remembers 3 passwords in history and ooh I forgot the password encryption is Salted Secure Hashing Algorithm (SSHA). Right, now I want to know a way to check if the user entered password is already in history. I get a error "Invalid Credentials" when I try to use a password that is in history. I know there is a LDAP attribute "PasswordHistory" and "PasswordInHistory" but I don't know which objectclass they belong to. I see the "PasswordHistory" attribute in the user advanced properties window but it does not have any value. One other question, if this is the only way to check if the password exists in history, how do I add this attribute to my schema? Your help would be greatly apprecited. Regards Allan --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --0-1440027224-1045821232=:28769 Content-Type: text/html; charset=us-ascii

Hi everybody,

My application is written in ColdFusion. We are using LDAP to authenticate users and have a strict
password policy. The password expire in 30 days, a warning message is sent to the user 7 days
before the password expires. LDAP also remembers 3 passwords in history and ooh I forgot the
password encryption is Salted Secure Hashing Algorithm (SSHA).

Right, now I want to know a way to check if the user entered password is already in history. I
get a error "Invalid Credentials" when I try to use a password that is in history. I know there
is a LDAP attribute "PasswordHistory" and "PasswordInHistory" but I don't know which objectclass
they belong to. I see the "PasswordHistory" attribute in the user advanced properties window but it
does not have any value. One other question, if this is the only way to check if the password
exists in history, how do I add this attribute to my schema?

Your help would be greatly apprecited.

Regards
Allan


Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --0-1440027224-1045821232=:28769-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 21 07:08:46 2003 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 HAA27450 for ; Fri, 21 Feb 2003 07:08:46 -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 h1LCD0p18216; Fri, 21 Feb 2003 07:13:00 -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 h1LCAup18173 for ; Fri, 21 Feb 2003 07:10:56 -0500 Received: from web13306.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27380 for ; Fri, 21 Feb 2003 07:03:22 -0500 (EST) Message-ID: <20030221120713.3692.qmail@web13306.mail.yahoo.com> Received: from [193.41.96.45] by web13306.mail.yahoo.com via HTTP; Fri, 21 Feb 2003 04:07:13 PST Date: Fri, 21 Feb 2003 04:07:13 -0800 (PST) From: Allan Clarke Subject: Re: [ldapext] LDAP - password in history To: Ludovic Poitou Cc: ldapext@ietf.org In-Reply-To: <3E560E1F.7090303@Sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-388270453-1045829233=:3634" 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: , --0-388270453-1045829233=:3634 Content-Type: text/plain; charset=us-ascii yes, my application connects to a iPlanet ldap server with all the password policies I mentioned earlier. I want to a know a way how my application can can check if the user entered password already exists in history. To do so there should be some attribute in some objectclass which contains the list of passwords. And at the moment I don't know how to get there. There is so little help out there that it is virtually impossible to find anything without any help. Cheers Allan Ludovic Poitou wrote:Hi Allan, Your question looks like to be related to a specific Directory Server implementation and it may be better to ask directly to the vendor... PasswordHistory and PasswordinHistory attributes are Netscape / iPlanet / Sun ONE specific as far as I know. Regards, Ludovic. PS: With Sun ONE Directory Server 5.x, if the password is in the history (when attempting to CHANGE it), the error returned is Constraint Violation and the additional message will tell you that the password is in the history. Allan Clarke wrote: > Hi everybody, > > My application is written in ColdFusion. We are using LDAP to > authenticate users and have a strict > password policy. The password expire in 30 days, a warning message is > sent to the user 7 days > before the password expires. LDAP also remembers 3 passwords in > history and ooh I forgot the > password encryption is Salted Secure Hashing Algorithm (SSHA). > > Right, now I want to know a way to check if the user entered password > is already in history. I > get a error "Invalid Credentials" when I try to use a password that is > in history. I know there > is a LDAP attribute "PasswordHistory" and "PasswordInHistory" but I > don't know which objectclass > they belong to. I see the "PasswordHistory" attribute in the user > advanced properties window but it > does not have any value. One other question, if this is the only way > to check if the password > exists in history, how do I add this attribute to my schema? > > Your help would be greatly apprecited. > > Regards > Allan > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Tax Center > - > forms, calculators, tips, and more -- Ludovic Poitou Sun Microsystems Inc. Sun ONE products - Directory Server Group - Grenoble - France --------------------------------- Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more --0-388270453-1045829233=:3634 Content-Type: text/html; charset=us-ascii

yes, my application connects to a iPlanet ldap server with all the password policies I mentioned earlier. I want to a know a way how my application can can check if the user entered password already exists in history. To do so there should be some attribute in some objectclass which contains the list of passwords. And at the moment I don't know how to get there. There is so little help out there that it is virtually impossible to find anything without any help.

Cheers

Allan

 Ludovic Poitou <ludovic.poitou@Sun.com> wrote:

Hi Allan,

Your question looks like to be related to a specific Directory Server
implementation and it may be better to ask directly to the vendor...
PasswordHistory and PasswordinHistory attributes are Netscape / iPlanet
/ Sun ONE specific as far as I know.

Regards,

Ludovic.

PS: With Sun ONE Directory Server 5.x, if the password is in the history
(when attempting to CHANGE it), the error returned is Constraint
Violation and the additional message will tell you that the password is
in the history.

Allan Clarke wrote:

> Hi everybody,
>
> My application is written in ColdFusion. We are using LDAP to
> authenticate users and have a strict
> password policy. The password expire in 30 days, a warning message is
> sent to the user 7 days
> before the password expires. LDAP also remembers 3 p! asswords in
> history and ooh I forgot the
> password encryption is Salted Secure Hashing Algorithm (SSHA).
>
> Right, now I want to know a way to check if the user entered password
> is already in history. I
> get a error "Invalid Credentials" when I try to use a password that is
> in history. I know there
> is a LDAP attribute "PasswordHistory" and "PasswordInHistory" but I
> don't know which objectclass
> they belong to. I see the "PasswordHistory" attribute in the user
> advanced properties window but it
> does not have any value. One other question, if this is the only way
> to check if the password
> exists in history, how do I add this attribute to my schema?
>
> Your help would be greatly apprecited.
>
> Regards
> Allan
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Ya! hoo! Tax Center
> -
> forms, calculators, tips, and more


--
Ludovic Poitou
Sun Microsystems Inc.
Sun ONE products - Directory Server Group - Grenoble - France



Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more --0-388270453-1045829233=:3634-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 21 09:14:56 2003 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 JAA00749 for ; Fri, 21 Feb 2003 09:14: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 h1LEL4p25730; Fri, 21 Feb 2003 09:21: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 h1LEITp25627 for ; Fri, 21 Feb 2003 09:18:29 -0500 Received: from ohsmtp03.ogw.rr.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00593 for ; Fri, 21 Feb 2003 09:10:54 -0500 (EST) Received: from willeke.com (dhcp024-166-083-155.neo.rr.com [24.166.83.155]) by ohsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h1LEEhHt014851 for ; Fri, 21 Feb 2003 09:14:43 -0500 (EST) Message-ID: <3E563450.30103@willeke.com> Date: Fri, 21 Feb 2003 09:14:40 -0500 From: Jim Willeke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030203 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ldapext@ietf.org Subject: Re: [ldapext] LDAP - password in history References: <20030221120713.3692.qmail@web13306.mail.yahoo.com> In-Reply-To: <20030221120713.3692.qmail@web13306.mail.yahoo.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 It is my opinion that if this history is avaialble, it is a risk that should be evalulated. If you are trying to tell the user if the password they tried ot use has already been used, I think there is an error code that is returned that will tell you the reason the password change failed. (At least it maybe returned unwilling to perform) But ask the vendor. -jim Allan Clarke wrote: > yes, my application connects to a iPlanet ldap server with all the > password policies I mentioned earlier. I want to a know a way how my > application can can check if the user entered password already exists > in history. To do so there should be some attribute in some > objectclass which contains the list of passwords. And at the moment I > don't know how to get there. There is so little help out there that it > is virtually impossible to find anything without any help. > > Cheers > > Allan > > */Ludovic Poitou /* wrote: > > Hi Allan, > > Your question looks like to be related to a specific Directory Server > implementation and it may be better to ask directly to the vendor... > PasswordHistory and PasswordinHistory attributes are Netscape / > iPlanet > / Sun ONE specific as far as I know. > > Regards, > > Ludovic. > > PS: With Sun ONE Directory Server 5.x, if the password is in the > history > (when attempting to CHANGE it), the error returned is Constraint > Violation and the additional message will tell you that the > password is > in the history. > > Allan Clarke wrote: > > > Hi everybody, > > > > My application is written in ColdFusion. We are using LDAP to > > authenticate users and have a strict > > password policy. The password expire in 30 days, a warning > message is > > sent to the user 7 days > > before the password expires. LDAP also remembers 3 p! asswords in > > history and ooh I forgot the > > password encryption is Salted Secure Hashing Algorithm (SSHA). > > > > Right, now I want to know a way to check if the user entered > password > > is already in history. I > > get a error "Invalid Credentials" when I try to use a password > that is > > in history. I know there > > is a LDAP attribute "PasswordHistory" and "PasswordInHistory" but I > > don't know which objectclass > > they belong to. I see the "PasswordHistory" attribute in the user > > advanced properties window but it > > does not have any value. One other question, if this is the only > way > > to check if the password > > exists in history, how do I add this attribute to my schema? > > > > Your help would be greatly apprecited. > > > > Regards > > Allan > > > > > > > ------------------------------------------------------------------------ > > Do you Yahoo!? > > Ya! hoo! Tax Center > > - > > forms, calculators, tips, and more > > > -- > Ludovic Poitou > Sun Microsystems Inc. > Sun ONE products - Directory Server Group - Grenoble - France > > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Tax Center > - > forms, calculators, tips, and more _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 21 10:01:52 2003 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 KAA02113 for ; Fri, 21 Feb 2003 10:01:52 -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 h1LF7qp29151; Fri, 21 Feb 2003 10:07:53 -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 h1LF5Vp28349 for ; Fri, 21 Feb 2003 10:05:31 -0500 Received: from mail.hello-penguin.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01991 for ; Fri, 21 Feb 2003 09:57:53 -0500 (EST) Received: from dejan by mail.hello-penguin.com with local (Exim 3.33 #3) id 18mEgF-0005ID-00; Fri, 21 Feb 2003 16:01:39 +0100 Date: Fri, 21 Feb 2003 16:01:39 +0100 From: Dejan Muhamedagic To: Allan Clarke Cc: ldapext@ietf.org Subject: Re: [ldapext] LDAP - password in history Message-ID: <20030221160139.A20221@smp.colors.kwc> Reply-To: Dejan Muhamedagic References: <3E560E1F.7090303@Sun.com> <20030221120713.3692.qmail@web13306.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030221120713.3692.qmail@web13306.mail.yahoo.com> User-Agent: Mutt/1.3.23i X-Lotto: Suggested Lotto numbers (Austrian 6 out of 45): 7 10 12 14 21 23 X-Spam-Status: No, hits=-4.1 required=6.0 tests=FORGOTTEN_PASSWORD,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_00_01,SUPERLONG_LINE,USER_AGENT,USER_AGENT_MUTT version=2.44-oesi_rules_0001 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: , Hi, You didn't read the Ludovic's reply carefully enough: he explained everything in the postscript. So, you should check the additional info sent in the server side control. Cheers. Dejan On Fri, Feb 21, 2003 at 04:07:13AM -0800, Allan Clarke wrote: > > yes, my application connects to a iPlanet ldap server with all the password policies I mentioned earlier. I want to a know a way how my application can can check if the user entered password already exists in history. To do so there should be some attribute in some objectclass which contains the list of passwords. And at the moment I don't know how to get there. There is so little help out there that it is virtually impossible to find anything without any help. > Cheers > Allan > Ludovic Poitou wrote:Hi Allan, > > Your question looks like to be related to a specific Directory Server > implementation and it may be better to ask directly to the vendor... > PasswordHistory and PasswordinHistory attributes are Netscape / iPlanet > / Sun ONE specific as far as I know. > > Regards, > > Ludovic. > > PS: With Sun ONE Directory Server 5.x, if the password is in the history > (when attempting to CHANGE it), the error returned is Constraint > Violation and the additional message will tell you that the password is > in the history. > > Allan Clarke wrote: > > > Hi everybody, > > > > My application is written in ColdFusion. We are using LDAP to > > authenticate users and have a strict > > password policy. The password expire in 30 days, a warning message is > > sent to the user 7 days > > before the password expires. LDAP also remembers 3 passwords in > > history and ooh I forgot the > > password encryption is Salted Secure Hashing Algorithm (SSHA). > > > > Right, now I want to know a way to check if the user entered password > > is already in history. I > > get a error "Invalid Credentials" when I try to use a password that is > > in history. I know there > > is a LDAP attribute "PasswordHistory" and "PasswordInHistory" but I > > don't know which objectclass > > they belong to. I see the "PasswordHistory" attribute in the user > > advanced properties window but it > > does not have any value. One other question, if this is the only way > > to check if the password > > exists in history, how do I add this attribute to my schema? > > > > Your help would be greatly apprecited. > > > > Regards > > Allan > > > > > > ------------------------------------------------------------------------ > > Do you Yahoo!? > > Yahoo! Tax Center > > - > > forms, calculators, tips, and more > > > -- > Ludovic Poitou > Sun Microsystems Inc. > Sun ONE products - Directory Server Group - Grenoble - France > > > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and more _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Fri Feb 21 10:49:20 2003 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 KAA04111 for ; Fri, 21 Feb 2003 10:49: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 h1LFtAp32415; Fri, 21 Feb 2003 10:55:10 -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 h1LBZRp14864 for ; Fri, 21 Feb 2003 06:35:27 -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 GAA26453 for ; Fri, 21 Feb 2003 06:27:54 -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 EAA05922; Fri, 21 Feb 2003 04:31:44 -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 h1LBVh109804; Fri, 21 Feb 2003 12:31:43 +0100 (MET) Message-ID: <3E560E1F.7090303@Sun.com> Date: Fri, 21 Feb 2003 12:31:43 +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: Allan Clarke CC: ldapext@ietf.org Subject: Re: [ldapext] LDAP - password in history References: <20030221095352.28838.qmail@web13302.mail.yahoo.com> 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 Hi Allan, Your question looks like to be related to a specific Directory Server implementation and it may be better to ask directly to the vendor... PasswordHistory and PasswordinHistory attributes are Netscape / iPlanet / Sun ONE specific as far as I know. Regards, Ludovic. PS: With Sun ONE Directory Server 5.x, if the password is in the history (when attempting to CHANGE it), the error returned is Constraint Violation and the additional message will tell you that the password is in the history. Allan Clarke wrote: > Hi everybody, > > My application is written in ColdFusion. We are using LDAP to > authenticate users and have a strict > password policy. The password expire in 30 days, a warning message is > sent to the user 7 days > before the password expires. LDAP also remembers 3 passwords in > history and ooh I forgot the > password encryption is Salted Secure Hashing Algorithm (SSHA). > > Right, now I want to know a way to check if the user entered password > is already in history. I > get a error "Invalid Credentials" when I try to use a password that is > in history. I know there > is a LDAP attribute "PasswordHistory" and "PasswordInHistory" but I > don't know which objectclass > they belong to. I see the "PasswordHistory" attribute in the user > advanced properties window but it > does not have any value. One other question, if this is the only way > to check if the password > exists in history, how do I add this attribute to my schema? > > Your help would be greatly apprecited. > > Regards > Allan > > > ------------------------------------------------------------------------ > Do you Yahoo!? > Yahoo! Tax Center > - > forms, calculators, tips, and more -- 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 Fri Feb 21 17:41:01 2003 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 RAA17451 for ; Fri, 21 Feb 2003 17:41:01 -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 h1LMkZp27679; Fri, 21 Feb 2003 17:46: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 h1LMhcp27591 for ; Fri, 21 Feb 2003 17:43:38 -0500 Received: from Tempo.Update.UU.SE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17310 for ; Fri, 21 Feb 2003 17:35:51 -0500 (EST) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante) with ESMTP id h1LMdWeC028175 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 21 Feb 2003 23:39:33 +0100 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante-submit) id h1LMdWpH028172; Fri, 21 Feb 2003 23:39:32 +0100 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15958.43683.575105.455202@Tempo.Update.UU.SE> Date: Fri, 21 Feb 2003 23:39:31 +0100 To: ldapext@ietf.org CC: roland@catalogix.se In-Reply-To: <15954.54666.323549.882235@Tempo.Update.UU.SE> References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> <3E517536.20902@it.su.se> <15954.54666.323549.882235@Tempo.Update.UU.SE> X-Mailer: VM 7.07 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1LMhcp27592 Subject: [ldapext] CLDAPv3: A slightly different approach 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've given some more thought to the CLDAPv3 issue. How about a solution like this? Basically: A request datagram (client to server) consists of one single LDAPMessage containing optionally one BindRequest, then any number of other requests (but see below). A response (server to client) is one single datagram consisting of a LDAPMessage containing the results of each of the requests in the request datagram, or an appropriate error if these won't fit into a single datagram (with possible exceptions as detailed below). Any LDAPv3 request is allowed. However: A datagram sent by the client SHOULD NOT contain any request in addition to (first) the optional initial bind request and (last) any other request, unless these additional requests are Extended Operations that are intended to affect how the server interprets or processes other requests in the datagram. A server MUST NOT perform an operation unless it knows that it eventually will be able to deliver the full result, assuming that both client and server are still running by then and can still communicate. If a server decides not to accept an operation on these grounds, it SHOULD return a "connection required" type of error. A server MAY perform an operation that, for correct operation, would require caching of results (as described by Leif Johansson and Roland Hedberg, or by any other means), but only if both client and server support such a method, and the client explicitly asks the server to use it for the operation (using a Control or Extended Operation request submitted with the request). A server is not required to support any such method. A server MAY split the results of one request into several datagrams only if the client explicitly asks for it (by some Control or Extended Operation possibly to be defined later; and in this case every datagram must still be a complete LDAPMessage). Otherwise, the server MUST return at most one single datagram in response to a single datagram. For any request, a server MAY return a "connection required" type of error. Again, this is just a quick sketch. Please tell me what you think. Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Feb 22 10:00:41 2003 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 KAA11611 for ; Sat, 22 Feb 2003 10:00:41 -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 h1MF6Zp20063; Sat, 22 Feb 2003 10: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 h1MF3Qp19973 for ; Sat, 22 Feb 2003 10:03:26 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11453 for ; Sat, 22 Feb 2003 09:55:20 -0500 (EST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h1MEudC05972; Sat, 22 Feb 2003 15:56:39 +0100 Message-ID: <3E578FA7.2060903@it.su.se> Date: Sat, 22 Feb 2003 15:56:39 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thorild Selen CC: ldapext@ietf.org, roland@catalogix.se Subject: Re: [ldapext] CLDAPv3: A slightly different approach References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> <3E517536.20902@it.su.se> <15954.54666.323549.882235@Tempo.Update.UU.SE> <15958.43683.575105.455202@Tempo.Update.UU.SE> In-Reply-To: <15958.43683.575105.455202@Tempo.Update.UU.SE> 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 Thorild Selen wrote: >I've given some more thought to the CLDAPv3 issue. How about a >solution like this? > > >Basically: A request datagram (client to server) consists of one >single LDAPMessage containing optionally one BindRequest, then any > > I have a couple of problem with this: 1. You can't do bind over UDP in any sensible way. You won't get away with specifying plain password mechs in this day and age and SASL requires a connection. 2. You will limit yourself to applications where all results fit in a single datagram. Try returning a few userCertificates and you will be running out of space really quick. This is just off the top of my head. I will have to read your proposal again... MVH leifj _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Feb 22 14:55:38 2003 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 OAA14886 for ; Sat, 22 Feb 2003 14:55:38 -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 h1MJxPp02028; Sat, 22 Feb 2003 14:59:25 -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 h1MJucp01981 for ; Sat, 22 Feb 2003 14:56:38 -0500 Received: from Tempo.Update.UU.SE (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14813 for ; Sat, 22 Feb 2003 14:48:25 -0500 (EST) Received: from Tempo.Update.UU.SE (ip6-localhost [IPv6:::1]) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante) with ESMTP id h1MJq7eC032725 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 22 Feb 2003 20:52:07 +0100 Received: (from thorild@localhost) by Tempo.Update.UU.SE (8.12.6/8.12.6/Update-Iltempogigante-submit) id h1MJq7IW032722; Sat, 22 Feb 2003 20:52:07 +0100 X-Authentication-Warning: Tempo.Update.UU.SE: thorild set sender to thorild@Update.UU.SE using -f From: Thorild Selen MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <15959.54503.110050.422705@Tempo.Update.UU.SE> Date: Sat, 22 Feb 2003 20:52:07 +0100 To: ldapext@ietf.org CC: roland@catalogix.se Subject: Re: [ldapext] CLDAPv3: A slightly different approach In-Reply-To: <3E578FA7.2060903@it.su.se> References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> <3E517536.20902@it.su.se> <15954.54666.323549.882235@Tempo.Update.UU.SE> <15958.43683.575105.455202@Tempo.Update.UU.SE> <3E578FA7.2060903@it.su.se> X-Mailer: VM 7.07 under Emacs 20.7.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h1MJucp01982 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 Leif Johansson writes: > 1. You can't do bind over UDP in any sensible way. You won't get away > with specifying plain password mechs in this day and age and SASL requires > a connection. True; the main reason for allowing a bind here is to let the client tell the server which version of the protocol it uses. (A suitable authentication scheme for CLDAP could be devised later; I agree that plain passwords are not to recommend.) > 2. You will limit yourself to applications where all results fit in > a single datagram. Try returning a few userCertificates and you will > be running out of space really quick. I would like to allow for an extension for multiple datagram responses, but not mandate it. Thorild Selén Datorföreningen Update / Update Computer Club, Uppsala, SE _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Feb 22 18:19:34 2003 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 SAA17186 for ; Sat, 22 Feb 2003 18:19: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 h1MNPYp12567; Sat, 22 Feb 2003 18:25:34 -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 h1MNFep12381 for ; Sat, 22 Feb 2003 18:15:40 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16980 for ; Sat, 22 Feb 2003 18:07:22 -0500 (EST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h1MN8XC06847; Sun, 23 Feb 2003 00:08:33 +0100 Message-ID: <3E5802F0.2050401@it.su.se> Date: Sun, 23 Feb 2003 00:08:32 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stig Venaas CC: Thorild Selen , ldapext@ietf.org, roland@catalogix.se Subject: Re: [ldapext] CLDAPv3: A slightly different approach References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> <3E517536.20902@it.su.se> <15954.54666.323549.882235@Tempo.Update.UU.SE> <15958.43683.575105.455202@Tempo.Update.UU.SE> <3E578FA7.2060903@it.su.se> <20030222210703.B10068@sverresborg.uninett.no> In-Reply-To: <20030222210703.B10068@sverresborg.uninett.no> 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 Stig Venaas wrote: >On Sat, Feb 22, 2003 at 03:56:39PM +0100, Leif Johansson wrote: > > >>1. You can't do bind over UDP in any sensible way. You won't get away >>with specifying plain password mechs in this day and age and SASL requires >>a connection. >> >> > >I haven't looked enough at these things, but I wonder if one could reuse >mechanisms from SNMP? Something like HMAC-SHA or HMAC-MD5, See sections 6 >and 7 of RFC 3414. > >Stig > > > That was my idea. That way you can also make sure you are not loosing response pdus. _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Sat Feb 22 18:20:58 2003 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 SAA17241 for ; Sat, 22 Feb 2003 18:20:57 -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 h1MNRip12726; Sat, 22 Feb 2003 18:27:44 -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 h1MNJAp12424 for ; Sat, 22 Feb 2003 18:19:10 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16996 for ; Sat, 22 Feb 2003 18:10:52 -0500 (EST) Received: from it.su.se (localhost.localdomain [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id h1MNC5C06856; Sun, 23 Feb 2003 00:12:05 +0100 Message-ID: <3E5803C5.3010503@it.su.se> Date: Sun, 23 Feb 2003 00:12:05 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thorild Selen CC: ldapext@ietf.org, roland@catalogix.se Subject: Re: [ldapext] CLDAPv3: A slightly different approach References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> <3E517536.20902@it.su.se> <15954.54666.323549.882235@Tempo.Update.UU.SE> <15958.43683.575105.455202@Tempo.Update.UU.SE> <3E578FA7.2060903@it.su.se> <15959.54503.110050.422705@Tempo.Update.UU.SE> In-Reply-To: <15959.54503.110050.422705@Tempo.Update.UU.SE> 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 Thorild Selen wrote: >Leif Johansson writes: > > 1. You can't do bind over UDP in any sensible way. You won't get away > > with specifying plain password mechs in this day and age and SASL requires > > a connection. > >True; the main reason for allowing a bind here is to let the client >tell the server which version of the protocol it uses. (A suitable >authentication scheme for CLDAP could be devised later; I agree that >plain passwords are not to recommend.) > > It is generally a good idea to authenticate the entire protocol exchange if possible... The protocol version may seem harmless but... > > 2. You will limit yourself to applications where all results fit in > > a single datagram. Try returning a few userCertificates and you will > > be running out of space really quick. > >I would like to allow for an extension for multiple datagram >responses, but not mandate it. > > > Then I suggest you define the "multipleResponse" extension to LDAPv3 and stick that into a standard LDAPv3 pdu. Such an extension might be useful for TCP applications aswell.... _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Mon Feb 24 09:48:20 2003 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 JAA15566 for ; Mon, 24 Feb 2003 09:48: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 h1OEstp29830; Mon, 24 Feb 2003 09:54:55 -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 h1MKBUp03104 for ; Sat, 22 Feb 2003 15:11:30 -0500 Received: from tyholt.uninett.no (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14953 for ; Sat, 22 Feb 2003 15:03:16 -0500 (EST) Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:1:0:290:27ff:fe50:6bfa]) by tyholt.uninett.no (8.12.6/8.12.6) with ESMTP id h1MK73ah029466; Sat, 22 Feb 2003 21:07:03 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.11.6/8.11.2) id h1MK73f10096; Sat, 22 Feb 2003 21:07:03 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Sat, 22 Feb 2003 21:07:03 +0100 From: Stig Venaas To: Leif Johansson Cc: Thorild Selen , ldapext@ietf.org, roland@catalogix.se Subject: Re: [ldapext] CLDAPv3: A slightly different approach Message-ID: <20030222210703.B10068@sverresborg.uninett.no> References: <200302142303.KAA27315@au.padl.com> <5.2.0.9.0.20030214163041.024ce568@127.0.0.1> <15953.15336.830720.986840@Tempo.Update.UU.SE> <3E51599C.6000708@it.su.se> <15953.25644.56942.704051@Tempo.Update.UU.SE> <3E517536.20902@it.su.se> <15954.54666.323549.882235@Tempo.Update.UU.SE> <15958.43683.575105.455202@Tempo.Update.UU.SE> <3E578FA7.2060903@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E578FA7.2060903@it.su.se>; from leifj@it.su.se on Sat, Feb 22, 2003 at 03:56:39PM +0100 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: , On Sat, Feb 22, 2003 at 03:56:39PM +0100, Leif Johansson wrote: > > 1. You can't do bind over UDP in any sensible way. You won't get away > with specifying plain password mechs in this day and age and SASL requires > a connection. I haven't looked enough at these things, but I wonder if one could reuse mechanisms from SNMP? Something like HMAC-SHA or HMAC-MD5, See sections 6 and 7 of RFC 3414. Stig _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext From ldapext-admin@ietf.org Wed Feb 26 09:07:24 2003 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 JAA05719 for ; Wed, 26 Feb 2003 09:07:24 -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 h1QEFdp11347; Wed, 26 Feb 2003 09:15: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 h1QEBJp10930 for ; Wed, 26 Feb 2003 09:11: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 JAA05231; Wed, 26 Feb 2003 09:01:17 -0500 (EST) Message-Id: <200302261401.JAA05231@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, 26 Feb 2003 09:01:17 -0500 Subject: [ldapext] I-D ACTION:draft-zeilenga-ldap-noop-00.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 : The LDAP No-Op Control Author(s) : K. Zeilenga Filename : draft-zeilenga-ldap-noop-00.txt Pages : 0 Date : 2003-2-25 This document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can be used to disable the normal effect of an operation. The control can be used to discover how a server might react to a particular update request without updating the directory. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-noop-00.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-noop-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-zeilenga-ldap-noop-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart 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: <2003-2-25160257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-zeilenga-ldap-noop-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-zeilenga-ldap-noop-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-25160257.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext