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