http://permalink.gmane.org/gmane.ietf.ldapext hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.ldapext/1618 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:44:26 http://permalink.gmane.org/gmane.ietf.ldapext/1617 <pre>I'm not convinced that this much detail is useful, but anyway: You can document existing practice and recommend what implementations' practice ought to be, but should say that the implementation's doc is authoritative. What implementations have you surveyed for that existing practice? If we generate 'userPassword's which this document says is OK but the implementation does not support, then Bind can break in interesting ways. So users MUST NOT trust this document if the implementation differs, which they must read the implementation doc to discover. E.g. some implementation might have a scheme {SSHA} with a different syntax like &lt;hash "$" salt&gt;. Or: Who wants megabyte-sized salts? It seems reasonable for the implementation to set some arbitrary limit. Both for convenience and because you could do a DoS attack by setting a huge salt and repeatedly Bind, forcing the server to hash a large value often. ================ Unix crypt(3): This is a function, not a library. Drop the 3 since non-Unix peo</pre> Hallvard Breien Furuseth 2013-03-16T03:54:22 http://permalink.gmane.org/gmane.ietf.ldapext/1615 <pre> I know that this sounds kinda problematic but what is the actual risk? The risk depends on how predictable the incorrect value is. It would be good to know how the various server implementors handle this. Also see this in the context with the paragraph following the above citation: Servers MAY provide local configuration items to limit the set of hash schemes to be processed and for completely disabling use of clear-text passwords in attribute 'userPassword'. The "MAY provide" here sounds too weak from a security perspective but using SHOULD would be too strong. Maybe it could be replaced by a lower-cased "should consider to provide". Agreed. The condition "does not have correct syntax" cannot be resolved because the syntax definition starts with: userpasswordvalue = cleartext-password / ( prefix hashed-password ) That's better. But I'm not sure whether administrator is a usual term in this type of documents. Ciao, Michael. _______________________________________________ Ldapext mai</pre> Michael Ströder 2013-03-15T22:08:15 http://permalink.gmane.org/gmane.ietf.ldapext/1613 <pre> In section 3 Implementation Issues, the 4th paragraph talks about checking the syntax of the storage scheme. This certainly has to be done, but I am a bit worried by the last sentence: Any value which do not adhere to this syntax MAY be treated as clear-text password by the DSA when processing a LDAP simple bind request or LDAP compare request. This is probably what most servers actually do, but it does mean that any unrecognised schemes or badly-formatted values effectively become clear-text passwords. Not a good failure mode... This is another case where the use of standard-setting words like MAY and SHOULD sits uneasily with the informational status of the document. From a security perspective I would prefer something like this: Any value which does not have correct syntax SHOULD be treated as a value that can never match any password asserted by a user. On the other hand, as a description of current practice it may be better to say: The treatment of values with incorrect syntax is defined</pre> Andrew Findlay 2013-03-15T12:53:26 http://permalink.gmane.org/gmane.ietf.ldapext/1610 <pre> Why not separate the description of the data from the overall syntax? It will be easier to read that way, and much more obvious that the whole thing is extensible and a bit informal. userPassword has Octet String syntax, so in principle the value is &lt;scheme name in curly brackets&gt; &lt;arbitrary data&gt; A separate section of the doc could then describe (or refer to) the formats of all the commonly-used storage schemes. I was about to call them 'hash schemes' but that is wrong, as some servers support reversible encryption schemes as well as hashes. On a slight tangent, a rough guide to the current strength of various hash schemes can be found on hashcat's front page: http://hashcat.net/oclhashcat-plus/ The table at the bottom gives the brute-force attack rate in crypts/sec using a single PC with a good (mid-range gaming) graphics engine. Numbers range from about 4k c/s for bcrypt up to 7500M c/2 for NTLM. It does not explicitly list figures for SSHA and SMD5 but I suspect the 'sha512crypt $6$' figure is i</pre> Andrew Findlay 2013-03-15T10:18:40 http://permalink.gmane.org/gmane.ietf.ldapext/1607 <pre> Conversion in this context means converting string representations of (salted) hashes. Obviously the algorithm and order of password and salt has to be the same. We all know that clients have to use some a priori knowledge - most times called protocol. ;-) Another use-cases is dealing with data migration to server product of another vendor. =&gt; So I consider this draft to be useful. That's simply your personal opinion not a strong objecting argument. That's a conclusion of your opinion. But I want to describe the *order* of password and salt used by any server I saw using the scheme. The whole I-D has target "informational". Yes. But this would just be another scheme to be defined somewhere else. This draft does not claim to cover everything you could ever stuff into 'userPassword'. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> Michael Ströder 2013-03-14T19:19:12 http://permalink.gmane.org/gmane.ietf.ldapext/1605 <pre> Anybody who has to generate or compare such userPassword values. Not true. 1. E.g. think of bulk sync processes where it's quite usual that you convert password hashes within the LDAP client - in some cases even salted. 2. Furthermore if a server does not support RFC 3062 and/or server-side hashing but supports this hashed values when performing password checking you also have to do client-side generation. This gets rare with recent server releases of various vendors but it's not something to completely ignore. 3. In some cases it's more appropriate that a LDAP client writes several attributes in a *single* LDAP write operation instead of using a add/modify with a subsequent Password Modify ext. op. E.g. when subschema has 'MUST userPassword' for an object class used. Not true. The unsalted variant has simply a zero-length salt. For -02 I've added some text to clarify this. Well, at first I simply wanted to ignore this completely. But after Andrews request I've already changed it for upcoming -02 l</pre> Michael Ströder 2013-03-14T18:29:48 http://permalink.gmane.org/gmane.ietf.ldapext/1604 <pre>SCRAM is "{" scram-mech"}" scram-authInfo "$" scram-authValue where the scram-* productions are defined in RFC 5803. Example: {SCRAM-SHA-1}4096:oX1HwnNpqWsmV5xrv5m1YQ==$PcqaaIoiFSOA9/txc4QaNa1jWxA=:4m6FNpHpuxJK63WRpXTAinev7zM= </pre> Kurt Zeilenga 2013-03-14T17:34:28 http://permalink.gmane.org/gmane.ietf.ldapext/1601 <pre>Hi Michael, I'm glad that you've added text to support {CRYPT}. But I'm not sure it is necessary to make the description complete (i.e. refer to all underlying platform specific algorithm). I think it might be enough to describe the general format of passwords generated by the crypt(3) library, mentions the default unix crypt and one or two other algorithm, but also warn that crypt being extensible and platform specific, it's use might result in interoperability issues. I would suggest that you add to the list of schemes, PBKDF2 and BCrypt that are 2 mechanisms that are providing much stronger security than the SHA 1 or 2. I'be happy to provide a description of PBKDF2 if you want, as we've implemented support for it in OpenDJ. Regards, Ludo </pre> Ludovic Poitou 2013-03-14T10:19:20 http://permalink.gmane.org/gmane.ietf.ldapext/1599 <pre> Still -01 ? You are explicitly excluding details of '{crypt}'. I think this is a mistake, especially in an informational document. {crypt} is extremely useful in transition scenarios, so people need to know about it. What platform-specific variants do you know of? The really important one is the old Unix-crypt 13-char salted hash. Could you perhaps say something like: {crypt} introduces a password-hash string that is generated and checked by the crypt(3) library. This could be the traditional 13-character 'Unix crypt' or some other variant such as the stronger '$1$' and $6$' schemes used by recent versions of Linux. Andrew </pre> Andrew Findlay 2013-03-14T00:19:01 http://permalink.gmane.org/gmane.ietf.ldapext/1598 <pre> I tried to add some wording to avoid that misunderstanding in the next revision of this draft: http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt I'd like to add that if you provide more detailed information about it. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> Michael Ströder 2013-03-13T22:39:28 http://permalink.gmane.org/gmane.ietf.ldapext/1597 <pre> Noted. Thanks. Hmm, this is beyond the scope of draft-stroeder-hashed-userpassword-values. I think such a comparsion should not include the detailed specifications for particular mechanisms. IMHO my document could be simply one of the documents such a comparsion could refer to. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> Michael Ströder 2013-01-29T22:59:39 http://permalink.gmane.org/gmane.ietf.ldapext/1596 <pre>My comments were not intended to discourage to try to produce a RFC in this area, but to provide some insight on issues you will face getting anything in this area published as an RFC. I think an RFC that discussed how standard and various current practices (note, not singuaral) differ, how the range of current practices differ, and all of this impacts these differences upon interoperability and security and other areas of concern, would be useful. A document is simply a technical specification of some additional hash schemes to an experimental extension is likely not to go down well in the IETF or the X.500 standards committee, especially if proposed to be published as anything but experimental independent-submission RFC. Again, this is not intended to discourage you from trying... but more to let you know what you are getting yourself into. </pre> Kurt Zeilenga 2013-01-29T22:23:05 http://permalink.gmane.org/gmane.ietf.ldapext/1595 <pre>Kurt, thanks for your feedback. Kurt Zeilenga wrote: I'm not trying to run a standard around IETF. My aim is just to write down what's current practice. Even if ISO/ITU X.500 committee and IETF see standardization problems this 'userPassword' hash syntax is widely used. I feel it should be documented pointing out the deficiencies and standardization issues - but fully and completely documented. Well, draft-howard-rfc2307bis-02.txt also aims to be published as Informational which seems appropriate to me given the wide use of the schema described therein. I thought that there is already some text pointing out possible interop issues and security issues. Please provide more concrete points which are missing in your opinion. Well, you don't want me to write a bad/incomplete document just to discourage the use of this syntax - do you? That 'document current practice' was exactly my plan but still being precise in what is described. The abstract already contains "Furthermore it points out some of th</pre> Michael Ströder 2013-01-29T21:22:25 http://permalink.gmane.org/gmane.ietf.ldapext/1594 <pre> On Jan 29, 2013, at 12:04 AM, Michael Ströder &lt;michael&lt; at &gt;stroeder.com&gt; wrote: In writing an I-D for publication as an RFC, there a few options: 1) Standard Track 2) Informational 3) Experimental The second two allow for independent submission (directly to the RFC Editor, don't require IETF consensus, but do require IESG no-objection (aimed at detecting trying to run a "standard" around the IETF)). For this particular specification, given past experiences in the IETF LDAP WGs and userPassword, I suspect you'll run into standardization issues. Even if the IETF wanted to extend userPassword (which is questionable), the IETF doesn't own the specification of userPassword in the Directory. That's owned by the ISO/ITU X.500 committee. So changes/extensions to userPassword ought to be taken there, not to the IETF. Experimental is for, well experiments. Though 2307 was an experiment, I think we can say that experiment should be concluded. One could have this I-D conclude the part about userPassword. And</pre> Kurt Zeilenga 2013-01-29T11:18:34 http://permalink.gmane.org/gmane.ietf.ldapext/1592 <pre>Hi Michael Yes, the ViewDS product does support attribute value hashing using attribute options to convey the hash scheme. Andrew On Sun, Jan 27, 2013 at 2:41 AM, Michael Ströder &lt;michael&lt; at &gt;stroeder.com&gt;wrote: </pre> Andrew Sciberras 2013-01-29T00:22:15 http://permalink.gmane.org/gmane.ietf.ldapext/1591 <pre>HI! Please review this draft intended to be published as informational RFC. Ciao, Michael. -------- Original Message -------- Subject: New Version Notification for draft-stroeder-hashed-userpassword-values-00.txt Date: Mon, 28 Jan 2013 12:44:04 -0800 From: internet-drafts&lt; at &gt;ietf.org To: michael&lt; at &gt;stroeder.com A new version of I-D, draft-stroeder-hashed-userpassword-values-00.txt has been successfully submitted by Michael Stroeder and posted to the IETF repository. Filename: draft-stroeder-hashed-userpassword-values Revision: 00 Title: Lightweight Directory Access Protocol (LDAP): Hashed Attribute values for 'userPassword' Creation date: 2013-01-28 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-00.txt Status: http://datatracker.ietf.org/doc/draft-stroeder-hashed-userpassword-values Htmlized: http://tools.ietf.org/html/draft-stroeder-hashed-userpassword-values-00 Abstract: This document describes the widely used s</pre> Michael Ströder 2013-01-28T20:46:37 http://permalink.gmane.org/gmane.ietf.ldapext/1590 <pre>I don't think you're going to find anything that uses this. nss_ldap supported authPassword as a compile-time option but, looking through the revision history, I can't find anything referring to attribute descriptions. </pre> Luke Howard 2013-01-27T03:24:08 http://permalink.gmane.org/gmane.ietf.ldapext/1589 <pre> I am out of the office until 02/02/2013. I will have only limited access to email. For immediate assistance, please contact my manager Bradley Olive or my team lead John Sullivan Note: This is an automated response to your message "[ldapext] Any implementations using userPassword;hash-scheme?" sent on 01/26/2013 8:41:24 . This is the only notification you will receive while this person is away._______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> Mike Gong 2013-01-26T17:04:09 http://permalink.gmane.org/gmane.ietf.ldapext/1588 <pre>HI! Is anyone here aware of any implementation using userPassword;hash-scheme? It was described in RFC 2307 but starting with a rather vague text: "A future standard may specify LDAP v3 attribute descriptions to represent hashed userPasswords" The text was already dropped in draft-howard-rfc2307bis-02 section 5.2.2.1. but without any further explanation. So I guess there are no implementations but I want to make sure. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> Michael Ströder 2013-01-26T15:41:24 http://permalink.gmane.org/gmane.ietf.ldapext/1586 <pre> The original I-D made CN mandatory in the text but optional in the schema definition. Looking around for things that use namedObject, I found: 1SuSE's YaST version of the RFC2307bis schema where they apparently use namedObject for empty groups and then change the object class to groupOfNames when the group gets a member! 2ForgeRock inculude the I-D.howard-namedobject definition in their core schema 3OpenLDAP does not ever seem to have distributed a definition for this class 4Gosa includes exactly the same RFC2307bis schema that SuSE uses. 5Kolab seems to have an incompatible derivative using the original OID and a new name: olcObjectClasses: ( 1.3.6.1.4.1.5322.13.1.1 NAME 'kolabNamedObject' SUP top STRUCTURAL MAY (cn $ ou) ) There is at least one other definition of namedObject floating around though I don't know whether it has ever been used: http://tools.ietf.org/id/draft-furuseth-ldap-untypedobject-02.txt That one permits a wide range of attributes but expects you to use just one of </pre> Andrew Findlay 2013-01-08T13:18:18 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ldapext