First off, the CRAM-MD5 package could be done by anyone, not just Microsoft - I know that at least one major ISP was talking about doing it a couple of years ago. From my understanding of how the OE and Outlook security code works, they take the authentication packages presented by the server, and attempt to look up an SSPI provider with the name of the authentication package and use it (don't quote me on this, I don't know if it works or not).
>From what I understand, Microsoft isn't particularly interested in putting resources into it because as far as I know, the powers that be are more focused on SPNEGO and DIGEST since they're more secure than either NTLM or CRAM-MD5, and both of those are supported on WinMe and Win2K+. As far as I know, Paul Leach is still the contact for SSPI issues at Microsoft, I'm not going to publish his email address, but it's not secret, he's written several internet drafts, including the drafts for CIFS, SPNEGO, and DIGEST. Paul's been the contact for this for almost 7 years at this point, that's why I didn't include him in my original reply - I figured that the people who deal with these issues have already dealt with him. You are absolutely right that you have every right to insist that every piece of your product have a standards track RFC backing it. Your customers also have every right to insist that you provide support for features, it's up to you as the vendor to decide whether your customers desires overwhelm your virtue. You're a software vendor, you make these trade-offs every day. And I already wrote far more than I wanted to on the open source vs. GPL issue - see my other email. From where I stand, unfortunately the GPL brush tars all open source. This is unfortunate, and I <DO> recognise the significant differences between the two, it doesn't make any practical difference. LCA (Legal and Corporate Affairs) has made it crystal clear - even <LOOKING> at open source code is grounds for termination of a Microsoft employee or contractor. Whether the code is GPL or not is unfortunately irrelevant, because the tendrils of the GPL run very deep. And before you say "hey, I work for a commercial software vendor, and they don't mind", remember - you don't work for the 800 pound gorilla with the great big target painted on his keister. If you don't believe that Sun, Oracle, Novell or AOL/TW (just to pick 3 competitors with deep pockets) wouldn't sue Microsoft in a heartbeat on <i behalf /i> of the open source community if they discovered an employee of MS working on open source or GPL code, you don't understand the reality of the software business these days. I hate this. I REALLY hate this. There are some open source projects I'd LOVE to work on (decal is a good example), but I cannot because I cannot run the risk to my employer. Here's the relevant portion on open source from the Microsoft employee handbook: The rules below are intended to protect valuable Microsoft intellectual property and MUST be followed: 1. Do not incorporate OSS into MS products. 2. Do not contribute code to an open source project. 3. Do not review, modify or distribute OSS source code. 4. Other than OSS source code, it is okay to review other information about open source projects (e.g., architecture descriptions included in books, project descriptions provided at websites, development discussions conducted on the Internet, etc.), provided that you comply with any accompanying licenses or restrictions. If you have questions about the rules governing access to specific information, check with your LCA contact. 5. You may run an OSS executable that is subject to the GNU General Public License (GPL) or any similar agreement, so long as the license or agreement does not require you to accept additional restrictions and/or obligations as a condition of running the software. If you have questions or concerns regarding the terms of a particular license or agreement, check with your LCA contact. 6. For code that is developed, or otherwise owned by or licensed to MS, do not distribute or otherwise make the code available under an "open source" agreement. And this entire discussion has gone WAY off topic, let's let it die a horrible death. Larry Osterman -----Original Message----- From: Mark Crispin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 1:09 PM To: Larry Osterman Cc: Marek Kowal; [EMAIL PROTECTED] Subject: RE: Outlook express AUTH command Larry - I am "guilty as charged" to "bigotry" as defined as "choosing open standards and not vendor-specific proprietary features." I am "guilty as charged" to choosing standards compliance over expediency. I remain defiant in asserting that these are virtues. You really don't want me to fling back what I consider to be the crimes of Microsoft in the email world. Hours of my time each month are squandered on helping sites work around two known bugs, acknowledged by Microsoft as such *months* ago, which have yet to be fixed in any distributed release, service pack, or hotfix. [FWIW, I didn't appreciate the fact that the MSKB article on one of these bugs claimed thatit was a "Pine issue"; that SSPI bug also breaks Exchange Server!] Worldwide, software support people spend an inordinate amount of time dealing with these, and other problems, caused by Microsoft's choice of expediency over standards compliance. There is legitimate anger, and it's completely unnecessary. These aren't your competitors who are angry; they're your customers, and sometimes even your shareholders. Larry, you are well-known to be one of the good guys at MS. I, and many other people, have benefited greatly from your help. Your comments over the years have been insightful and thoughtful. It is with all this in mind that I am telling you that phrases such as "bigotry" and "nobody has bothered to write a CRAM-MD5 SSPI provider" are not well-received outside of Microsoft. Instead, try something like: . "It is not difficult to write NTLM support on W2K platforms, since the SSPI interface supports it. If all you're doing is a W2K implementation, it should be easy. Unfortunately, we never got the documentation out so it can be done on non-MS platforms." . "It's unfortunate that we never got a CRAM-MD5 SSPI provider written. If you think this is an issue, please contact [EMAIL PROTECTED] so we can get some resources put on this." These say much the same thing, but are much more likely to be received favorably. I'd like to echo Pete Naylor's comment: > I will need documentation of how I can implement the NTLM mechanism > such that this added functionality in my software will be available > for all target platforms. This part about "can implement [for]...all target platforms" really is a requirement for those of us who do multi-platform software development. As excellent as your work on SSPI is, it doesn't help me when I am faced with "make it work on a non-MS platform." I use SSPI, but my first Windows versions of Kerberos and SSL support were based on MIT Kerberos and OpenSSL and a port to Windows of my UNIX code. If I were to implement NTLM, I would probably start with a portable version first, and later fix the Windows version to use SSPI. SSPI is good, but dependence upon SSPI is not. Last, but not least, please don't consider "open source" to be equivalent to "GPL". There are at least as many anti-GPL people in the open source community as at Microsoft. Regards, -- Mark --
