draft-ietf-nntpext-base-03.txt some comments

[Nat Ballou (Exchange)]

One of the things discussed in DC was how a client could
get a list of authenticators from the server.  Current 
practice with shipping NNTP servers is to allow an
'AUTHINFO GENERIC' command (no arguments) and have the
server return a CR/LF separated list of authentication
packages, terminated with CRLF.CRLF.

Comments?

Nat

-----Original Message-----
From: Chris Newman [mailto:Chris.Newman at INNOSOFT.COM]
Sent: Thursday, January 15, 1998 11:16 AM
To: Paul Overell
Cc: ietf-nntp at academ.com
Subject: Re: draft-ietf-nntpext-base-03.txt some comments


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[7] 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
demonstrated this. 

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
standardization.

		- Chris