2002-12-17-18:11:43 Marshall Rose:
> here's an interesting thought experiment: if TLS (nee SSL) is
> around, why did the IETF add SASL to all of its application
> protocols?
Errh, because the Cyrus team implemented it, and nobody was
offering a better way to stuff authentication into SMTP? The
hideous overcomplexity of SASL has been the main barrier to getting
authenticated SMTP more widely deployed. Notably, the Cyrus SASL
libraries --- the only SASL implementation available[1] --- have
been found to have security bugs in them.
> to understand the answer to this, is to understand why TLS, while
> very good at what it does, doesn't meet the requirements of many
> environments.
To understand why SMTP auth is so rarely deployed, and why so many
people are using the revolting pop-before-smtp kluge instead, is to
understand why wading off into the bright open and inventing your
own crypto protocols from scratch is best avoided.
> here are two hints: kerberized enterprises?
Haven't ever cared especially; even when I've worked in a totally
kerberized enterprise, certs were just as good for host-to-host
auth (and operationally equivalent). But now that I do a quick RFC
search, it looks like RFC 2712 describes Kerberos authentication for
TLS, so it looks like someone decided to enable the general-purpose
tool to encompass that problem.
> integrity-sans-privacy?
I'm having trouble envisioning a real motivation for that, but it
seems to be supported within TLS as it stands, BulkCipherAlgorithm
null.
> again, it's not that TLS isn't adequate, it's perfectly adequate
> and extensible for its mission. the problem is that its mission
> may not have quite the reach that a lot of folks require...
Before concluding that, it's good to make positively certain TLS
can't do the job as it stands, and that it's impractical to extend
it, before going out and re-inventing the functionality; there's a
lot of engineering benefit to re-using existing analysis and
implementation, and if the existing protocol is inadequate for a new
job, better to extend it, and thereby leave it fitted to a broader
set of tasks, then re-implementing the functionality elsewhere.
I really think the security needs of syslog are best met by just
getting it off UDP and onto TCP, whereupon it's easy to transport it
securely.
-Bennett
[1] I've heard of other SASL library implementation attempts. I
haven't heard of any that got far enough to be a viable
alternative to Cyrus SASL for a real application.
