On Jan 23, 2007, at 2:22 PM, Morten Sylvest Olsen wrote:
Henry B. Hotz wrote:
Per my earlier thread it appears that there isn't any worthwhile
SASL support on the Windows platform. However there is support
for SSPI, which can be made to behave like GSSAPI. There are
published, tested examples of how to do this.
Wouldn't it be worthwhile for someone to write an alternate
version of the GSSAPI mechanism plug-in that works on Windows
without the need to install a Kerberos distribution?
Does the Windows SSPI actually support Kerberos?
Yes, it supports Microsoft's implementation of Kerberos. That means
it has some non-standard features, but it will interoperate with
modern open-source implementations.
I know in cyrus-sasl and the Linux-world GSSAPI == Kerberos, but
actually the G is supposed to mean Generic! I think Solaris has
another mechanism besides Kerberos for GSSAPI. I've always thought
the layering of GSSAPI below SASL weird, like tcp over http :)
How about SASL/GSSAPI/SPNEGO/Krb5 for a layering? ;-) That ought to
work with the latest code. SASL, GSSAPI, and SPNEGO are all
mechanism negotiation layers. You could construct arguments for
layering them in any order, but the above is the order they're
implemented.
Seems to me that if someone cares about wide adoption of the SASL
standard then we need a robust implementation on Windows that's
easy to build/install.
I think a larger problem is that the Windows world is entrenched on
SPNEGO, especially since IE supports it. To be fair, it is also
somewhat better because it, unlike SASL, is immune to downgrading
attacks.
/Morten
AFAIK SPNEGO is just a GSSAPI mechanism, but I don't do much with
Windows. GSSAPI could be downgraded to GSSAPI/SPNEGO/NTLMv1 if your
implementation was configured to support it. That would be
*terrible*. GSSAPI/Kerberos is the only mechanism implemented in
Java (and many other places), but even there you could be downgraded
to single-DES encryption.
SASL needs to be explicitly configured to the security level you
want, and then it should be fine. It's acknowledged that a MITM can
force use of a non-default mechanism, so you need to configure it to
disallow all insecure mechanisms.
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@xxxxxxxxxxxx, or hbhotz@xxxxxxx
