On Thu, 28 Mar 2002, Marek Kowal wrote:
> 2) Can somebody point me to any resources on SPNEGO/DIGEST? I know, 45 secs. > on MSDN would do, but I believe experts on this list will know much better > what is really worth reading. > 3) Is anybody implementing (has already implemented) any of those in Unix > world. Can it be done outside Windows platform, or the RFC will not be > published and this is again some proprietary thing? Folks have posted the pointers to the SPNEGO and DIGEST-MD5 RFCs. SPNEGO is *not* an authentication mechanism itself, it is only a means for GSSAPI-using clients and servers to securely negotiate the use of a real GSSAPI-supporting authentication mechanism. I'm not aware of any freely-available source code implementing SPNEGO, unfortunately. There's a task for some bright grad student to make the world a better place ... Part of the reason for the lack of interest in SPNEGO outside of Microsoft is that, as far as I know, the only use of SPNEGO in practice is to negotiate the use of NTLM vs Kerberos on Windows platforms. As draft-ietf-cat-sasl-gssapi-05.txt explains, negotiation of mechanisms at the GSSAPI level is much less interesting and useful if only a subset of all security mechanisms available to the application are accessible via GSSAPI. That is, since the top-level security-mechanism-multiplexing framework for the application protocols of interest here (IMAP, POP, SMTP) is SASL, it doesn't make much sense to have both SASL-level negotiation and GSSAPI-level negotiation. So in practice SASL-savvy applications don't need or want to refer to the SPNEGO GSSAPI pseudo-mechanism, they just refer directly to the real underlying mechanism, such as Kerberos. So only Microsoft produces clients and servers that actively use SPNEGO, and the rest of the world can pretty much get by with ignoring it. There is some interest in having non-Microsoft platforms interoperate with Microsoft's approach to using GSSAPI for web authentication (draft-brezak-spnego-http-03.txt), since of course there's no SASL for HTTP, so for that practical purpose it would be attractive for there to be a freely-available SPNEGO implementation. RFC 2617 defines DIGEST as an HTTP-specific authentication mechanism. There was a desire to define a compatible approach as a SASL mechanism so it could be used by any SASL-profiling application protocol. The specific motivation was LDAP, which was looking for an acceptable mandatory-to-implement non-TLS authentication mechanism. DIGEST is better than CRAM-MD5 in preventing various malicious-server attacks; RFC 2831 describes its improvements in detail. There are, I believe, numerous UNIX-compatible freely-available implementations of DIGEST-MD5; the Cyrus SASL library has one. DIGEST is *not* defined as a GSSAPI mechanism. So it's curious to me that Larry says: > It does on my WinXP Pro machine - the SSPI provider name is "Digest" This makes me wonder whether the DIGEST SSPI mechanism Larry is talking about is a Microsoft-defined GSSAPI mechanism, which wouldn't interoperate with any other current implementation of DIGEST to my knowledge, or whether SSPI is providing an interface both for selection of GSSAPI mechanisms and SASL mechanisms, which would be fine by me, as long as it's clear what it's doing. Anyone know? - RL "Bob"
