Suggested ToDo
Henry B. Hotz
hotz at jpl.nasa.gov
Tue Jan 23 20:11:10 EST 2007
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 at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the Cyrus-sasl
mailing list