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

[Chris Lewis]

Chris Newman wrote:
> 
> 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?

I'm probably missing something, but I'm not sure that requiring SASL mechanisms
makes any difference here, unless SASL lists all authentication mechanisms.

I remember having this thought when I looked at SASL in this connection long
ago.  Could you provide me a URL to the full spec?  Diffs for the NNTP draft
won't indicate why this is necessary.
 
> 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!

I'm not sure what you're getting here.  Won't interoperate with what?  The
intent
behind AUTHINFO GENERIC is that the person inventing a custom authentication
mechanism has to supply the hook for the client.

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

I'd much rather see something that specifies how to encrypt the whole NNTP
session, which protects the authentication as well, rather than an ad-hoc
glue-in that only applies to authentication.  In which case, we'd probably
want to standardize on snews:// (which is NNTP over SSL, no?)