http://blog.gmane.org/gmane.ietf.ldapext hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.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 any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:44:26 http://comments.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://comments.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://comments.gmane.org/gmane.ietf.ldapext/1577 <pre>HI! I wonder why RFC 4527 limits the use of the Read Entry control to update operations (Add, Delete, Modify, ModifyDN). E.g. the pre-read control could be also useful to read the last login time and number of failed authc attempts and display it to the user *after* a successful bind. This is a bit tricky since the appropriate ACLs would have to be applied when reading the attribute values although the user is not already bound. But this could be internally handled by the server similar to proxy authz. Ciao, Michael. _______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> Michael Ströder 2012-04-20T16:47:52 http://comments.gmane.org/gmane.ietf.ldapext/1576 <pre>HI! RFC 2589 says: The requestTtl is a time in seconds (between 1 and 31557600) that the client requests that the entry exists in the directory before being automatically removed. 31557600 seconds is 365 days (one non-leap year). That's not so much. Does anybody here know why this limit was defined in this RFC? Ciao, Michael. </pre> Michael Ströder 2011-11-17T20:43:21 http://comments.gmane.org/gmane.ietf.ldapext/1565 <pre>Maybe some of the subscribers are interested in this. Ciao, Michael. -------- Original Message -------- Subject: [ldap] LDAPCon 2011 Call for Papers Date: Fri, 08 Apr 2011 14:46:47 +0200 From: Peter Gietz &lt;peter.gietz&lt; at &gt;daasi.de&gt; To: ldap&lt; at &gt;umich.edu With the usual apologies. The 3rd Edition of the International Conference on LDAP (LDAPCon 2011[1]) will be held on October, 10-11, 2011 in Heidelberg, Germany. A Call For Papers[2] has been raised and the Program Committee asks you to submit abstracts by July 8th. The International Conference on LDAP is a technical forum for IT professionals interested in LDAP and related topics like directory servers, directory management applications, directory integration, identity and access management, and meta directories. It focuses on implementation and integration of LDAP servers and LDAP-enabled client applications. The event will bring together vendors, developers, active and prospective LDAP practitioners to share their experiences about deployment strategies, service operations, interoperability, discuss LDAP usage in new projects and learn about upcoming trends and developments. The 1st LDAPCon[3] was held in September 2007 in Germany, the 2nd LDAPCon[4] was held in September 2009 in Portland, Oregon, USA (Some pictures from LDAPCon 2007 [5] and a nice summary of LDAPCon 2009 [6]) So if you're involved with LDAP in interesting projects and you want to share your experiences, please check the Call For Papers and submit a proposal. Best, Peter [1]: http://www.ldapcon.org [2]: http://www.daasi.de/ldapcon2011/index.php?site=cfp [3]: http://www.guug.de/veranstaltungen/ldapcon2007/index.html [4]: http://www.symas.com/ldapcon2009 [5]: http://www.flickr.com/photos/ludovic_p/sets/72157601937159198/detail/ [6]: http://blogs.sun.com/Ludo/entry/ldapcon_2009_summary </pre> Michael Ströder 2011-04-09T12:01:50 http://comments.gmane.org/gmane.ietf.ldapext/1562 <pre>Is there a limit defined in the LDAP RFCs anywhere for the length of the OID value for a schema definition, for example inetOrgPerson is 2.16.840.1.113730.3.2.2, whereas organization is 2.5.6.4. Is there a maximum length defined for how long that digit string can be for custom schema? For example, should 1.2.840.112233.1.1234.5678.12345.1234.123456.1234 be considered legal? Thanks, Mark Hinckley _______________________________________________ Ldapext mailing list Ldapext&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ldapext </pre> Mark Hinckley 2011-04-07T22:11:04 http://comments.gmane.org/gmane.ietf.ldapext/1551 <pre>Hello, A new version of the draft (http://tools.ietf.org/html/draft-cal-resource-schema-02), describing the schema for representing resources for calendaring and scheduling based on our discussions in Calconnect, has been submitted. This draft includes a mapping of the schema for both vCard and LDAP. We have tried to reuse existing LDAP attributes as much as possible. I would really appreciate review and feedback by the experts. Thanks, Ciny </pre> Ciny Joy 2010-10-21T16:58:50 http://comments.gmane.org/gmane.ietf.ldapext/1551 <pre>Hello, A new version of the draft (http://tools.ietf.org/html/draft-cal-resource-schema-02), describing the schema for representing resources for calendaring and scheduling based on our discussions in Calconnect, has been submitted. This draft includes a mapping of the schema for both vCard and LDAP. We have tried to reuse existing LDAP attributes as much as possible. I would really appreciate review and feedback by the experts. Thanks, Ciny </pre> Ciny Joy 2010-10-21T16:58:50 http://comments.gmane.org/gmane.ietf.ldapext/1544 <pre>Section 7.1 says: o The current time is greater than or equal to the value of the pwdLastSuccess attribute added to the value of the pwdMaxIdle attribute. but pwdLastSuccess may not exist as the user might never have successfully authenticated. I would suggest, o If pwdLastSuccess attribute exists, the current time is greater than or equal to the value of the pwdLastSuccess attribute added to the value of the pwdMaxIdle attribute. o Otherwise, the current time is greater than or equal to the value of the pwdChangedTime attribute added to the value of the pwdMaxIdle attribute. But, of course, pwdChangedTime might not exist. First, if one has an governing password policy, I think both pwdLastSuccess and pwdChangedTime MUST always be maintained. This allows, for instance, a pwdMaxIdle or pwdMaxAge restriction to be establish subsequently to the initial policy being set. Second, the specification should detail what should happen if a particular state attribute is missing. For instance, even if the above MUST was in place, one still the issue of handling an initial policy with pwdMaxIdle and pwdMaxAge yet neither of these state attributes yet present. If both attribute are absent, I suggest using createTimestamp of the password policy subentry as substitute. That is, in absence of these state attributes, an account would not be idled until the policy was pwdMaxIdle old, and password not be aged until the policy was pwdMaxAge old. (pwdMinAge has a similar problem, but here I recommend axing pwdMinAge as it's a really bad idea to begin with.) </pre> Kurt Zeilenga 2010-08-09T17:18:14 http://comments.gmane.org/gmane.ietf.ldapext/1543 <pre>Dear ldapex[t|perts], thanks to the received feedback our draft related to "ldap server side current time matching" has been recently updated to version 1: http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-01.txt As a result of the previous technical discussions the document is currently focused on LDAP protocol specific implementation details like for example the syntaxes (current time and duration) and the various extensible matching rules. As the feedback in regard to the general idea (ldap server side current time matching) has been quite small we would like to take the opportunity to restart the discussion into a more general direction. We are interested in your (also non-technical) opinions and visions regarding this kind of LDAP protocol feature. Advanced usage scenarios based on current time matching operations are therefore also of interest. Where else and how do these matching rules could have an impact, e.g. on your environment, development or related future concepts? In the following you find a short (and surely incomplete) list of topics that are in our opinion (at least partly) related to current time matching: - ldap password policy's password expiration[Time|Duration], draft-behera-ldap-password-policy - Component Matching (Certificate timestamps?) - DSA-internal KDC data store; draft-chu-ldap-kdc-schema (eg. principalNotUsed[Before|After]?) - DSA-internal CA (mentioned at kerberos 2009 by H. Chu) - ... Your feedback is highly appreciated - thanks a lot! Best regards, Daniel </pre> Daniel Pluta 2010-07-20T11:01:58 http://comments.gmane.org/gmane.ietf.ldapext/1537 <pre>While the 5.2.15 says: This attribute indicates whether users can change their own passwords, although the change operation is still subject to access control. It also says: This attribute is intended to be used in the absence of an access control mechanism. I think the intent that it be conjunction with other access controls. And in 8.2.3, I think the text: If the bound identity is a user changing its own password, this MAY be done by checking the pwdAllowUserChange attribute or using an access control mechanism. The determination of this is implementation specific. should read: In addition to other access controls which the operation would normally be subjected to, the operation is subject to a pwdAllowUserChange check. If the bound identity is a user changing its own password, the server MUST deny the change when pwdAllowUserChange is present and set to FALSE in the governing policy. Also, in the subsequent sentence, change "user is not allowed to" to "user is not authorized to" as "not allowed" can be read to include more than just "not authorized". </pre> Kurt Zeilenga 2010-07-06T17:49:58 http://comments.gmane.org/gmane.ietf.ldapext/1536 <pre>Given that pwdMaxFailures=0 disables lockout, pwdLockout is not only redundant but adds unnecessarily complexity to both servers and management clients. I recommend it be axed. </pre> Kurt Zeilenga 2010-07-06T17:33:56 http://comments.gmane.org/gmane.ietf.ldapext/1535 <pre>I note that the ISO/IEC X.500 folks are currently considering an X.500 extension in this area &lt;http://www.x500standard.com/uploads/extensions/pwp_N14274_PDAM2.pdf&gt;, ballot closing later this month. While the IETF certainly can ignore this specification (if approved), but doing so would seem to lead to fragmentation within the LDAP/X.500 community. </pre> Kurt Zeilenga 2010-07-05T22:48:45 http://comments.gmane.org/gmane.ietf.ldapext/1529 <pre>The spec specifically allows for an user entry to be controlled by multiple policies (each for a different password attribute) but then defines pwdPolicySubentry to be single-valued. It seems to me that the text as a whole doesn't really well consider the implications of multiple applicable password policies. In our current implementation, we do implement 5.3.1, and mandate that only a single password policy be applicable to a given user. We currently looking at userPassword v. authPassword implications with regard to auto-migration, as we're now supporting the latter for SCRAM authentication. I think we'll assume that if both are present in an entry, they represent the same same user password. We'll like need to support both RFC 2307 hashing and in conjunction with SCRAM authPassword hashing so that users can use either TLS+SimpleBind(WithPassword) or SCRAM. I don't see the value of having two disjoint password policies, one for each attribute. What I believe our customers will demand is an unified password policy covering both of these attributes. (I can see a possible desire to support a disjoint password policy covering passwords for directory application specific passwords, such as when one has a different directory password from say an email password stored in the directory. However, our customers which have different passwords for different directory applications tend to rely on multiple entries per user, one per directory application (with service-level authorization restrictions), not multiple passwords attributes in a single entry.) </pre> Kurt Zeilenga 2010-07-05T21:43:25 http://comments.gmane.org/gmane.ietf.ldapext/1527 <pre>Additional Isode-specific features include hash algorithm specification and auto migration of password hash algorithms (standard userPassword to/from RFC 2307 userPassword, and soon to/from authPassword [RFC3112] (for SCRAM)). This might be something worthwhile to consider off-the-standard track (given tracks of RFC 2307 and RFC 3112). In our implementation, we have two attributes which advertise the server's available hash compare and hash generate methods, and then two attributes which specify the compare and generate methods may be used. The latter being single valued and is what gets used by LDAP password modify operation. Then we have a pwdAutoMigrate flag to enable auto-migration. Auto-migration works by checking, at Simple Bind time (post authentication), to see if the current generate method differs from the hash method used for the user. If so, the stored value is updated using the current generate method without resetting various state variables (such as pwdChangedTime). This can be used to update from plain text passwords to particular hash method, update from one hash method to another, and update from a hash algorithm to plain text. We're currently adding support for authPassword, namely for use with SCRAM. As part of this, we plan to update these password policy features. </pre> Kurt Zeilenga 2010-07-05T20:43:30 http://comments.gmane.org/gmane.ietf.ldapext/1522 <pre>It is desirable to have a mechanism to exclude (or exempt) a user from the policy. For instance, it's nasty for various accounts associated with application entities (as opposed to humans) to be locked out. In the Isode implementation, we have an operational single-valued attribute, pwdExclude, which if present in the user's entry and has the boolean value TRUE exempts the user from all password policy enforcement. It would be good to add something like this to the spec. </pre> Kurt Zeilenga 2010-07-05T20:14:55 http://comments.gmane.org/gmane.ietf.ldapext/1515 <pre>Once an account has beed idled, how does the administrator clear the idle condition to allow the user to login? </pre> Kurt Zeilenga 2010-07-02T23:01:03 http://comments.gmane.org/gmane.ietf.ldapext/1513 <pre>Not only does the spec continue to suffer from various issues in face of shadowing/caching, additional issues in this area have been introduced by features such as account idling. Account idling relies on shared knowledge across a set of DSAs of last successful login, and nothing in LDAP/X.500 ensures such shared knowledge can be maintained. I favor a base specification(s) which details policy mechanisms specifically designed to operate in a traditional LDAP/X.500 model (each entry held by one master, possibly multiple shadow and caching DSAs) without any reliance on distributed operations and possibly additional specifications (possibly as appendices to the base) discussing how the base specification could be enhanced through the use of distributed operations and other yet-to-be-specified extensions (to the protocol or models). </pre> Kurt Zeilenga 2010-07-02T21:48:42 http://comments.gmane.org/gmane.ietf.ldapext/1512 <pre>As previously noted, I believe it better to keep expire history based upon time in history not number of history. The latter leads to the need for pwdMinAge, which from a security perspective, is a really bad idea. At Isode, we ignore pwdInHistory and instead utilize an additional attribute, pwdHistoryDuration, to control history expiration. </pre> Kurt Zeilenga 2010-07-02T20:08:13 http://comments.gmane.org/gmane.ietf.ldapext/1503 <pre>The latest I-D contains an account idling feature. This is yet another feature which is useful regardless of the mechanism being used for authentication. At present, I favor separating such features into a separate "account policy" specification. However in absence of an I-D actually detailing an "account policy" this note can be viewed as simply placing my view on the public record. Or maybe just rework this specification to be an "account policy" specification with "password extensions". :-) </pre> Kurt Zeilenga 2010-06-30T20:39:41 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.ldapext