Mark Crispin wrote: > > I recommend instead that USEFOR confine its efforts to NNTP updates and > RFC2822 extensions specific to news, and get a charter going on a WG > dedicated to UTF-8 extension to messaging. > > I would be very much interested in participating in such a working group, > and feel that this unified approach would deliver much better long-term > results than having netnews take a "go-it-alone" approach. > > Please consider this.
I second this suggestion. Given the recent mile long thread on the ietf-822 list regarding this topic, its obvious that this isn't a simple nut to crack and I think input from experts in all of the messaging protocols (IMAP, POP3, SMTP, NNTP) would be valuable, if not necessary. > > > 3. I see that you have incorporated connections to SASL, TLS, etc. > > This is even further from my areas of expertise, but I have been > > watching recent discussions on the NNTP-Extension working group > > (http://www.academ.com/academ/nntp/ietf.html). The problem they > > encountered was that, whilst PLAIN authentication was probably good > > enough, the IETF expects something more that does not transmit passwords > > in the clear. > > That's why PLAIN is not permitted unless SSL or TLS has been negotiated. > I've been waiting for a STARTTLS and AUTH command in NNTP. Just glom the > specification from POP3. Please. I, along with the folks at CMU, have been pushing for this. In fact, Chris Newman wrote a draft for a NNTP SASL profile about 4 years ago which essentially used the POP3/SMTP profile. There was a lot of push back on the this for a number of reasons, but I believe CMU and I have convinced the current author of the NNTP SASL draft why most of these reasons were either ill-advised or uninformed. We'll know for sure when we finally see the draft. ;) > > Encrypting the NNTP data stream is stupid, because everything in it > > is intended (usually) for the public domain, and the performance hit > > is severe. So they were talking about turning the TLS off after the > > authentication. This all strikes me as a sledgehammer and nut approach. This was simply a suggestion made by Larry Greenfield as one way to solve a problem which appears to be unique to NNTP. > I sympathize; nevertheless we do not allow authenticated access to our > NNTP servers without using SSL NNTP. In fact, we no longer allow any > plaintext authentication for any of our services. The cost of one > security breach is much greater than the cost of encryption. > > Fortunately, computers are faster these days. > > The other choices are CRAM-MD5, DIGEST-MD5, which basically involve > storing plaintext equivalents of the authentication credentials on the > server. The problem with this as I understand it is that some NNTP sites _need_ to have the plaintext password sent by the client, so that the server can pass it on to some external authentication service (eg, Radius). I believe that there are only two solutions to this problem, either use a SSL/TLS protected plaintext mechanism, or design a new SASL mechanism which allows the the plaintext password to be sent to the server in a encrypted form (eg, DSS). Since nobody on the nntpext list volunteered to write such a mechanism, or revive Newman's original DSS draft, Larry suggested using the built-in renegotiation ability of TLS (once authentication is done, have the server ask the client to renegotiate down to the NULL cipher). This might not be the most elegant solution to the problem, but its a zero cost solution because it uses existing documented and implemented standards. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
