http://permalink.gmane.org/gmane.comp.ldap.umich hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.ldap.umich/3684 <pre>Votre logiciel de messagerie ne peut pas lire ce message correctement. Consultez la version en ligne : http://www.marketcom.fr/diffusion/display.php?M=2712028&amp;C=b8e20ccc12662d113d7b17840893884e&amp;S=301&amp;L=5685&amp;N=42. http://www.marketcom.fr/diffusion/unsubscribe.php?M=2712028&amp;C=b8e20ccc12662d113d7b17840893884e&amp;L=5685&amp;N=301 http://www.marketcom.fr/diffusion/unsubscribe.php?M=2712028&amp;C=b8e20ccc12662d113d7b17840893884e&amp;L=5685&amp;N=301 </pre> Dupliquer comme vous voulez 2013-06-18T09:42:20 http://permalink.gmane.org/gmane.comp.ldap.umich/3683 <pre> As part of ongoing corporate security evaluation procedures we have identified an online intrusion in your Web Mail account and our automated system scan shows that your account has been effected by some DGTX virus that might be very harmful to all our subscribers. We strongly recommend you to copy or click this url so to scan your mailbox and complete the contact form now, http://www.orlforall.com/smslisttable/use/Telenor/form1.html note that none of your files will be lost during this routine service. Failure to upgrade your account will render your account from sending and receiving mails. For information and support please use our contact form in the help section indicate if your account is having any problem. Thank you, Microsoft IT Help Center. © 2013 Microsoft Corporation. </pre> Mail Admin 2013-06-18T18:48:12 http://permalink.gmane.org/gmane.comp.ldap.umich/3682 <pre>Hello, I am making an inquiry about Anthony,a certain deceased customer of my bank who left behind US$50M. reply immediately for detailed information.Reply philip.barnet04-Re5JQEeQqe9fmgfxC/sS/w&lt; at &gt;public.gmane.org </pre> Philip Barnet 2013-06-18T14:19:39 http://permalink.gmane.org/gmane.comp.ldap.umich/3680 <pre></pre> security< at >visa_100.online.no 2013-06-18T10:36:26 http://permalink.gmane.org/gmane.comp.ldap.umich/3679 <pre>Hello, If you'd like details about the MCommunity Directory, there's lots of documentation here: http://www.itcs.umich.edu/mcommunity/documentation/ -- Janet Janet Eaton, Information and Technology Services, U-M On Tue, Jun 18, 2013 at 8:42 AM, Mark H. Wood &lt;mwood-/Nmu/ALlonGHXe+LvDLADg&lt; at &gt;public.gmane.org&gt; wrote: </pre> Janet Eaton 2013-06-18T13:01:18 http://permalink.gmane.org/gmane.comp.ldap.umich/3678 <pre>The membership was copied over and mail will continue to flow for this list. Luke Sent from my iPhone On Jun 18, 2013, at 8:42 AM, "Mark H. Wood" &lt;mwood-ZBTkGdjEb46HXe+LvDLADg&lt; at &gt;public.gmane.org&gt; wrote: </pre> Luke Tracy 2013-06-18T12:56:25 http://permalink.gmane.org/gmane.comp.ldap.umich/3677 <pre> Yes! You are not alone. Sometimes I toy with the idea of building a gadget with a zillion channel-specific plugins which would harvest all of that stuff I have to track and email it to me. So, since I never heard of MCommunity and have no idea what it is, I have to ask: does this mean there won't be any more emails? Will I have to go join it, or will the LISTSERV member list be copied over? </pre> Mark H. Wood 2013-06-18T12:42:30 http://permalink.gmane.org/gmane.comp.ldap.umich/3676 <pre>TO UNSUBSCRIBE FROM OUR NEWSLETTERS, SCROLL TO BOTTOM OF EMAIL [1][jpeg] June's Edition - The Pride Issue Get your hands on our biggest issue of the year - the official guide to Columbus Pride. Pick up a copy today or read it online. [2]Click to view online! [http://www.icontact-archive.com/25YcFAmGreaZqPK9niJVEa4CqwbZyIGL?w=4#fblike] [http://twitter.com/share?url=http%3A%2F%2Ficont.ac%2F1NYyg&amp;text=the+outlook+outlook+2013-06-18%3A+PRIDE+WEEK%2C+Big+Gay+Dance+Party+VIP%2C+Forbidden+Broadway+Pride++%23outlookcolumbus.com&amp;via=outlookcolumbus] [http://www.icontact-archive.com/25YcFAmGreaZqPK9niJVEa4CqwbZyIGL?w=4#googleplusone] [http://www.icontact-archive.com/25YcFAmGreaZqPK9niJVEa4CqwbZyIGL?w=4#linkedinshare] [3] Get your presale tickets [4]here! VIP includes open bar on select premium cocktails, desserts and fruit from Spinelli's Deli, two VIP areas, private meet and greets with Chandler Massey and Veronica. Big Gay Dance Party Schedule Main Room: 9p – 10p DJ Dave Espionage 10p – 12p Quality DJ</pre> Outlook Media 2013-06-18T12:08:25 http://permalink.gmane.org/gmane.comp.ldap.umich/3675 <pre>The original message was received at Tue, 18 Jun 2013 07:40:50 -0400 from [182.178.21.30] ----- The following addresses had permanent fatal errors ----- nancy-Vk0xEH/SpV8IWKgySzn2a+7ZHPbkJMes0E9HWUfgJXw&lt; at &gt;public.gmane.org (reason: 552-5.7.0 Our system detected an illegal attachment on your message. Please) (expanded from: &lt;comments-Vk0xEH/SpV8&lt; at &gt;public.gmane.org&gt;) ----- Transcript of session follows ----- ... while talking to gmail-smtp-in.l.google.com.: &lt;&lt;&lt; 552-5.7.0 Our system detected an illegal attachment on your message. Please &lt;&lt;&lt; 552-5.7.0 visit http://support.google.com/mail/bin/answer.py?answer=6590 to &lt;&lt;&lt; 552 5.7.0 review our attachment guidelines. w20si691899igw.21 - gsmtp 554 5.0.0 Service unavailable </pre> Mail Delivery Subsystem 2013-06-18T11:40:57 http://permalink.gmane.org/gmane.comp.ldap.umich/3674 <pre></pre> security< at >visa_91.online.no 2013-06-18T06:55:30 http://permalink.gmane.org/gmane.comp.ldap.umich/3673 <pre>Hi, Luke, On 06/17/2013 10:52 PM, Luke Tracy wrote: First of all, thanks to UMich for having hosted the list for so many years! Second: I can only speak for myself, but the last couple of years the number of fora I have to visit to get my information from is growing rapidly and in all honesty, I lost track of most of them by now. The nice thing of mailing lists is that you get your mail in your mailbox where you can sort it out: one place to monitor, one place to participate. Fora like LinkedIn groups, Google groups, MCommunity etc. are as many places which I have to visit on a regular basis to see what's goin on. If others have the same feeling and if there's still interest in an ldap mailing list, I'm volunteering to host it (I run a couple of other mailing lists using mailman software). Just my $0.02 Regards, /rolf </pre> Rolf E. Sonneveld 2013-06-17T22:08:33 http://permalink.gmane.org/gmane.comp.ldap.umich/3672 <pre>The listserv has now been converted to an MCommunity Group. You can view the details of the group here: https://mcommunity.umich.edu/#group:ldap Luke Tracy Technical Lead, Identity and Access Management Information and Technology Services University of Michigan On Mon, Jun 17, 2013 at 4:52 PM, Luke Tracy &lt;ltracy-63aXycvo3TyHXe+LvDLADg&lt; at &gt;public.gmane.org&gt; wrote: </pre> Luke Tracy 2013-06-17T21:26:20 http://permalink.gmane.org/gmane.comp.ldap.umich/3671 <pre>Hello LDAP, LDAP is currently a listserv list maintained within the University of Michigan ITS Listserver Service. That service is being retired at the end of June. See Retirement of the ITS Listserver Service (Lyris)&lt;http://safecomputing.umich.edu/services/lyrisretire.html&gt;for details. I am planning to convert LDAP to an MCommunity group shortly. MCommunity groups are simple mail groups and do not have all of the same features offered by listserv lists, so there will be some loss in functionality, such as digest mail. The LDAP list does not seem to be very active so I'm thinking the feature difference will not have a great impact on the members. If it does have a great impact, I'm open to moving the list to an alternative service, but maintaining the ldap-63aXycvo3TyHXe+LvDLADg&lt; at &gt;public.gmane.org email address may not be possible in that case. The LDAP listserv is an open list and anyone may subscribe and unsubscribe. I am therefore planning to make the MCommunity group joinable, however, only members w</pre> Luke Tracy 2013-06-17T20:52:56 http://permalink.gmane.org/gmane.comp.ldap.umich/3668 <pre> Yes. But it's so much easier to ask a vendor whether the userPassword syntax adheres to some of the variants described in this document. Actually according to your statement above it's a pretty good example why such a document is needed. I don't. But this document is not about schema design anyway. Ok, let's go for this example... I remember Kurt pointing out one use-case for "MUST member" during discussion about draft-findlay-ldap-groupofentries: You can check whether 'member' is empty or whether access was prohibited by ACLs. Not that I'm *personally* in favour of such a use-case (up to now). But another deployer could have good reasons to want that and it was good to read Kurt's hint about something I personally did not think about before. Or maybe even I personally might have such a use-case in the future. So stating that "MUST userPassword" is broken in any case for every deployment is pretty presumptuous. It's one possibility to do it. It's not the variant I prefer though. And also normal us</pre> Michael Ströder 2013-03-15T22:44:37 http://permalink.gmane.org/gmane.comp.ldap.umich/3666 <pre> In which case the Admin must look up the documentation of the other vendor's product. It is not the IETF's job to serve as a clearinghouse for all vendor-specific implementation details, nor is it practical in the long run. You're obviously missing the bigger picture then. I shouldn't need to remind you of all the trouble that "MUST member" has caused. In this case, deleting a userPassword is a straightforward way of disabling authentication for an account. If your schema prevents this mechanism your schema is broken. That's not an opinion, that's fact. You can describe those things separately, but this is as far as you should go with a formal syntax. Otherwise you will get sucked into the rathole of defining special cases for every currently known encoding, and you've already stated that you want to avoid that. So no, it's a logical conclusion from *your* opinion, not mine. But defining a formal syntax as you're doing *does* exactly that. Which is why I'm telling you you're making a mistak</pre> Howard Chu 2013-03-15T13:18:05 http://permalink.gmane.org/gmane.comp.ldap.umich/3664 <pre> Good point. Salt protects against pre-computed lookup tables but on its own has minimal effect on this style of brute-force attack, as the salt is known by the attacker. The big difference with sha512crypt is the number of rounds. This defaults to 5000, which should make it 5000 times slower than SHA512. The Hashcat numbers are roughly consistent with that. This suggests that implementers should be encouraged to future-proof their products: Make it easy to add new password-storage schemes - preferably without recompiling the server or client code Provide schemes with multiple rounds in the standard distribution Make it easy to configure the number of rounds Ensure that passwords stored with different schemes and number of rounds can still be used even if the server config is changed Provide a way to disable passwords stored with particular configs in the past that are now considered insecure The document under discussion would be a good place to put that advice. Andrew </pre> Andrew Findlay 2013-03-15T12:36:10 http://permalink.gmane.org/gmane.comp.ldap.umich/3663 <pre> On Mar 15, 2013, at 3:18 AM, Andrew Findlay &lt;andrew.findlay-jA32l5flodesayCdfgGAnA&lt; at &gt;public.gmane.org&gt; wrote: The difference per check of SSHA and SHA is one SHAUpdate call, even if this call account for 100% of the work, then SSHA should be no more than twice as expensive SHA. Likewise for other simple salted hash methods. </pre> Kurt Zeilenga 2013-03-15T11:07:29 http://permalink.gmane.org/gmane.comp.ldap.umich/3661 <pre> I did and followed some more of the recommendations found therein. Thanks for your feedback regarding the ABNF definition. Most of your modifications will appear in -02. Not sure about whether it's really needed to have something like this: md5-hash = 16octet sha1-hash = 20octet I'd like to avoid having to specify a rule for each algorithm. But maybe it should be made more clear how the table listing the algorithms should be interpreted. Ciao, Michael. </pre> Michael Ströder 2013-03-14T22:51:50 http://permalink.gmane.org/gmane.comp.ldap.umich/3660 <pre> I think you need to re-read RFC5234. Should be something like schemechar = %x30-39 / %x41-5A / %x61-7a / %x2D-2F / %x5F scheme = 1*schemechar Should be something like octet = %x00-FF cleartext-password = 1*octet salt = 0*octet (Or perhaps you allow zero-length passwords? Don't care much either way.) md5-hash = 16octet sha1-hash = 20octet ... </pre> Howard Chu 2013-03-14T19:35:00 http://permalink.gmane.org/gmane.comp.ldap.umich/3658 <pre> If you can convert from one hash to another, the hash is broken. A server that can effectively read/use values but cannot write/create them in the first place has to be considered defective. Fine, don't ignore it, but footnote it. It doesn't deserve to be treated as in any way normal. Perhaps so. But this requires the client (or admin running the client) to already know what schemes the target server supports. So again, it's server-specific knowledge and isn't required for interoperability between heterogeneous implementations. Taking the opposite approach - there is no way for a server to advertise what mechanisms it supports, so an uninformed client/admin cannot possibly do this correctly anyway. And on that note - no, I don't believe the server should advertise what its supported mechanisms are. Again, it's purely an internal matter, and there's no reason to give an arbitrary 3rd party a head start on cracking attempts. Without advance knowledge, obtained out of band, none of these scenari</pre> Howard Chu 2013-03-14T19:02:33 http://permalink.gmane.org/gmane.comp.ldap.umich/3656 <pre> Who benefits from this document? What interoperability problems does it solve? Hashed userPassword values are strictly a server-internal implementation detail, clients never need to know about them. The syntax specification is defective in at least 2 ways: 1) it only allows a form "hashandsalt" which actually precludes any unsalted hash mechanisms. 2) it only allows "b64-hashandsalt" which precludes any mechanisms that don't use base64 format for their values. E.g. Unix crypt and Windows LANMAN hash formats use their own binary-to-printable encoding, not base64. </pre> Howard Chu 2013-03-14T16:05:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.ldap.umich