Path: utzoo!utstat!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnews!cblpf!mark
From: mark@cblpf.ATT.COM (Mark Horton)
Newsgroups: news.software.nntp
Subject: Re: Suggested NNTP enhancements for user access control
Message-ID: <11363@cbnews.ATT.COM>
Date: 13 Nov 89 16:09:18 GMT
References: <10095@ucsd.Edu> <11212@cbnews.ATT.COM> <10125@ucsd.Edu>
Sender: news@cbnews.ATT.COM
Reply-To: mark@cblpf.ATT.COM (Mark Horton)
Organization: AT&T Bell Laboratories, Columbus
Lines: 40

In article <10125@ucsd.Edu> brian@ucsd.edu (Brian Kantor) writes:
>Mark, you are reading too much into the spec.  A more precise statement
>of the semantics of the USER command is
>
>	USER <site-dependent-string>
>
>i.e., the spec doesn't call for ANY specific syntax or content of the
>string following the USER command.  That means that login procedures
>for the NNTP server at any particular host are as configurable as is the
>interactive (user terminal) login itself.  If that requires a specific
>n-tuple of parameters, so be it.  N can always be 1 if that's the way
>your host wants to do it.

The whole point of a standard is to standardize things.  If the standard
says "do whatever you want" you haven't accomplished anything.  I should
be able to take two implementations of NNTP (say mine and the one my
feed is running) and expect them to talk to each other, possibly with
some configuration that doesn't require me to have source.  I should
also be able to implement my local user policy without breaking
interoperability with my neighbor.

If we restrict the USER line to only apply to END-USER-to-SERVER
authentication, then we're OK.  But your examples seem to imply
using this for PEER-SERVER-to-PEER-SERVER login, and I think that
should be kept separate, and if it happens, it's critical that
this one be standardized (and, of course, configurable so it can
be turned off.)

>Specification or requirement of encryption and of user identification
>and/or verification does not belong in the NNTP spec.  All we have to
>do is provide a facility for in-band exchange of tokens for the people
>who want to do that.

This sounds reasonable, with one caveat.  There should be a requirement
that any text in the "Please send a password" response be displayed to
the user.  There will be some implementations where the password depends
on the string sent, especially when hand-held authenticators are used.
There might be a different code for this case if you like.

	Mark