AUTHINFO draft (was Re: ietf-nntp IETF 41 summary ...)

[Chris Newman]

On Mon, 4 May 1998, Stan Barber wrote:
> >From the summary I wrote:
> > During the discussion about the "rfc977bis" draft, there was a
> > lengthy discussion about excluding the AUTHINFO command from this
> > document and doing it in a separate extensions document.
> > ...
> > of its own. There was a volunteer to create this new document.
> > Unfortunately, I didn't capture the name of that individual.
> 
> Would that individual identify themselves? I apologize in advance for 
> not getting this down. 

I was that volunteer.

I've already started working, but have a fair amount to do. I aim to have
an I-D before the end of June, so there's time to debate it on the list
and possibly do one more revision before the end of July. 

My basic plan is:

Document AUTHINFO USER/PASS as is, but add the IETF requirement that if
it's implemented, then a stronger mechanism or security layer also has to
be implemented.

Document AUTHINFO GENERIC as a legacy feature which may be used by private
agreement, but is not advertised as an extension.

Document AUTHINFO SASL as the profile for SASL in NNTP.  This allows
IMAP/SMTP/POP3/NNTP/ACAP/LDAP to all share the same mechanisms, rather
than having to create special NNTP-only mechanisms.  I think this is
obviously preferred since most mail/news clients will support more than
one of those protocols.

We always have the choice of moving AUTHINFO back into the base spec as
long as we select a mandatory-to-implement mechanism.  See:
	draft-newman-auth-mandatory-00.txt 
for a description of the mandatory-to-implement authentication mechanism
problem.  I believe that problem led to the decision at the WG meeting to
try subnet border packet filters as the mandatory-to-implement mechanism
to prevent resource abuse, and move AUTHINFO into an extension.

		- Chris