On Wed, 27 Mar 2002, Lyndon Nerenberg wrote: > Interest in NTLM hs been around since the first (Microsoft) > implementations of it came out. I have had interest in implementing > it on the server side (in the server I get paid to maintain) since > early on in NTLM's deployment.
I am in the same position. Why, you may ask, is there such interest from the non-Windows server community in a Microsoft-specific authentication mechanism, one that Microsoft says is "officially dead"? The answer is simple. NTLM is the only secure authentication mechanism that Outlook, as installed on the vast majority of customer systems, supports. Our customers want to abolish "passwords in the clear", and we have standards compliant methods of authentication without transmitting a password in the clear. The problem is that Outlook doesn't implement any of these standards compliant methods of authentication that avoid transmitting passwords in the clear. It does, however, implement this thing called NTLM. So why isn't SSL IMAP the be-all and end-all solution? SSL reduces some of the pressure, but not entirely. Microsoft has come up with yet another way to stymie any non-Windows server vendor from eliminating "passwords in the clear". The Inbox application on Windows CE devices doesn't support SSL IMAP. What's worse, Windows CE devices tend to be used with wireless cards, so securing authentication is of even greater concern. If Microsoft were to offer offer downloadable extensions to Outlook and Windows CE Inbox that would support CRAM-MD5, KERBEROS_V4, and GSSAPI, there would be little reason for non-Windows server implementors to grouse about the lack of documentation for NTLM. As long as NTLM remains the only secure authentication mechanism that Microsoft provides in its client software, non-Windows server implementors will continue to desire a public specification for NTLM. I doubt that Microsoft wants to state that it is Microsoft corporate policy that sites must use Windows-based servers in order to have secure authentication with Outlook and Windows CE Inbox. However, that is the *effect* of Microsoft's actions. I hope that Microsoft would agree that this situation, however innocently it may have arisen, is not good; and that Microsoft will respond either by opening up the NTLM specification or by distributing SSPI providers for the commonly deployed secure SASL authentication mechanisms (which IMHO are CRAM-MD5, KERBEROS_V4, and GSSAPI). I spoke from the point of view of a server implementor. There is also some client implementor interest in NTLM, but not to the same degree. For clients, the issue only comes up with a non-Windows client against an Exchange server on Windows. Non-Microsoft servers on Windows presumably offer the other secure SASL authentication methods, and (as you pointed out) it is not difficult for a Windows client to do NTLM via SSPI. So there is less pressure on client implementors. But on us poor downtrodden server implementors, it's getting ugly. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
