draft-ietf-nntpext-base-03.txt some comments
Chris.Newman at INNOSOFT.COM
Thu Jan 15 11:15:59 PST 1998
On Thu, 15 Jan 1998, Paul Overell wrote:
> > The server will attempt to engage the server end
> > authenticator; similarly, the client should engage the client
> > end authenticator. The server end authenticator will then
> > initiate authentication using the NNTP sockets (if appropriate
> > for that authentication protocol), using the protocol
> > specified by the authenticator name. These authentication
> > protocols are not included in this document, but are similar
> > in structure to those referenced in RFC 1731 for the IMAP-4
> > protocol.
> Saying "similar in structure" rather unsatifactory. Can we not reference the
> actual protocols? Are they SASL protocols (RFC2222) ?
I concur and STRONGLY OBJECT to the current AUTHINFO GENERIC text. I
believe AUTHINFO GENERIC should only permit SASL mechanisms and has to be
updated to be a correct SASL profile. I sent context diffs to the list a
while ago with suggested text (I'll resend them if you want). SASL is not
hard -- the complete rules are only 7 pages.
Why is this important?
Becuase developing good authentication mechanisms takes a long time and is
very hard work. SASL allows all application protocols to share that
development effort. If you use some custom ad-hoc authentication
framework, like the one telnet, FTP or HTTP uses, then there will be
little or no development of authentication mechanisms. History has
In addition, if you fail to REQUIRE implementation of a non-plaintext
authentication mechanism, you will get an LDAPv3-style disclaimer (see
IESG Note in RFC 2251). Personally, I don't want a news standard which
includes an IESG warning that POST and IHAVE won't interoperate! If you
use SASL you can require implementation of CRAM-MD5 which was sufficient
for ACAP (RFC 2244) to escape this fate. Anything else is likely to delay
More information about the ietf-nntp