At 11:57 AM 12/18/2002, Bennett Todd <[EMAIL PROTECTED]> wrote: >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?
Because TLS does not solve the whole problem. Neither does SASL. (Neither does GSSAPI. Neither does IPSEC.) Bur together they provide fairly complete coverage of the authentication mechanisms and security layers that most designers need to engineer secure protocols (and allow them to offer appropriate flexibility to deployers). >Errh, because the Cyrus team implemented it, and nobody was >offering a better way to stuff authentication into SMTP? IIRC, the Cyrus SASL effort was started AFTER RFC 2222 was published. SASL was, of course, invented at same company which invented SSL (TLS), Netscape. And, of course, SASL was initially targeted for IMAP. You might ask yourself, why would the company which invented SSL find it appropriate to develop SASL? If you cannot find the answer, though it be obvious, I'll give it to you: SASL and TLS (SSL) complement each other. >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. First off, Cyrus SASL is only one of many available SASL "library" implementations. And, second, many SASL mechanisms are so simple that no library is needed. I've personally implemented multiple SASL mechanisms without use of libraries, so it's been my experience that SASL is actually quite simple. (Of course, some mechanisms are easier to implement than others... but the ones designed to be used over transport layer security are trivial to implement). With regards to implementation bugs, sure, I'm sure some have been found in this and other implementations. But, I don't think the quality of available implementations should be an issue here. >> 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. Which is, after all, why you should use SASL and other security frameworks. There is no need to reinvent PKI-based authentication, simple password authentication, digest password authentication, Kerberos authentication, one-time passwords, secure-id, etc.. And use of these frameworks in specifications has led to plugin APIs so that one can adapt the software one acquires to the local environment. The ability to support legacy environments is quite valuable. >> 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. Whilst one can certainly add cipher suites to TLS... that's not necessarily the best approach. >> 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; To add the capabilities that SASL offers to TLS would require reinvention of functionality. And likewise for trying to add all of TLS capabilities to SASL. >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. You just made a good argument for the use of SASL. >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. Hell, why don't you just use IPSEC and not worry about it at all? (I say this in jest.) >-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.
