From:	SMTP%"brian@UCSD.EDU" 12-APR-1991 14:24:16.67
To:	JMS@CARAT.ARIZONA.EDU
CC:	
Subj:	Re:  NNTP auth

Date: Fri, 12 Apr 91 14:23:16 -0700
From: brian@UCSD.EDU (Brian Kantor)
Message-Id: <9104122123.AA26853@ucsd.edu>
To: JMS@CARAT.ARIZONA.EDU
Subject: Re:  NNTP auth

The NNTP authorization scheme is supposed to be site dependent.
The version that's in the current code is really only for simple host
authentication, to prevent users from telnetting into nntp ports and
forging articles.

Enclosed below is a first draft of a suggested specification that is
being considered by the IETF NNTP working group.  It may help a bit
in understanding what the issues are, and how you can use them.
	- Brian






Network Working Group                                       Brian Kantor
Request for Comments: P-DRAFT                   Univ. of Calif San Diego
                                                             August 1990


                           NNTP Enhancements


Status of this Memo

   This is a preliminary draft of revisions to the NNTP.  While no major
   revisions are expected, it would perhaps be wise to defer making
   significant investments in time implementing these specs until more
   review has taken place.


Clarifications of points inadequately discussed in RFC977

   It is important to note that while the NNTP is similar to the
   electronic mail transport standard for SMTP, it does not operate in
   the same environment.  NNTP connections imply the existence of some
   degree of prearrangement: newsfeeds are set up by cooperating sites.
   Therefore, many of the negotiations which might be implied by a
   general-access protocol such as SMTP are not required in the NNTP
   since they will be arranged ahead of time by the managers of the
   systems involved.

   RFC977 does not fully specify which header lines are required by the
   POST command when an article is submitted from a client.  This is
   intentional, as the NNTP server does not in fact perform the posting
   operation itself, but merely provides transport of the article to be
   posted to the news software that does the actual posting.  Thus which
   header lines must be included before an article can be posted via
   NNTP is dependent upon the news posting software at the server.
   Typically, some of the header lines that are required for transport
   of a posted article between systems would NOT be required for a
   proto-article that is being submitted via the POST command, as the
   news posting software will supply them.

   It is suggested that those header lines which are used by persons
   reading the articles (as opposed to transport headers) and which are
   likely to contain user-specific information should probably be
   supplied within the proto-article by the NNTP posting client, as that
   is most likely the point at which that information is known.

   Within the context of the Usenet news RFC [currently RFC1036], which
   headers are supplied by the user agent that composed the proto-
   article and which are supplied by the posting software itself is a



Kantor                                                  FORMFEED[Page 1]





RFC DRAFT                                                    August 1990


   program interface issue and does not seem to be addressed, as the RFC
   covers only article transport.  However, in a more global sense,
   there should be some specification of the interface to the news
   posting software.

   Articles submitted for XFER must be complete articles with all
   RFC1036 header fields.


Implementation matters

   A definition of newsgroup matching should be issued to supplement the
   Usenet news RFC since it's not clear either from that spec nor this
   one just what is meant by 'matching' newsgroup specifications.

   There are many commands for which the response from the server would
   be useful to the person running the nntp client, in particular the
   messages returned from authentication, access, and posting commands.
   Implementors should seriously consider that some of these should be
   written to the user's screen.


Changes

   Date and time now use ISO 3307 format, but for backward compatability
   the prior MMDDYY HHMMSS format may still be accepted.  Dates and
   times are always in GMT.

   The default character set for NNTP commands and responses is
   NETASCII, but within the structure of textual transmissions, the 7-
   bit limitation does not apply whenever the underlying transmission
   medium can support 8-bit data.  Thus articles containing 8-bit data
   must be transferred without the high-order bit of octets being set to
   zero whenever possible.

   Several new commands have been added to allow for authentication and
   access control, as well as some transfer options and a new SEARCH
   command to provide for super-whiz-bang news retrieval systems.

   XHDR becomes a subset of the optional HEADER command; for backwards
   compatability a server can handle both.

   Restrictions on the contents of the 4th field of data returned by the
   LIST command are deleted.







Kantor                                                  FORMFEED[Page 2]





RFC DRAFT                                                    August 1990


New commands:

   OPTION {DO | NO} option [parameters] used to request that an <option>
   be turned on or off.  The server will respond with either
           204 option set as requested
           404 option NOT set as requested
   The assumption is that all options are off at the time a connection
   is established.

   Currently, the options are:

   CRYPT [parameters] - causes all textual transmissions to be encrypted
   according to <parameters>.  Since at this time there is no general-
   purpose encryption standard for the Internet and it outside the scope
   of this document to suggest one, this is a host-dependent string and
   is simply used to enable an encryption method previously agreed upon.

   IMAGE opsys - individual articles are not transmitted in NETASCII
   form; instead they are sent by sending a line containing the size of
   the article to be transmitted as
           bytecount CRLF
   (bytecount is a decimal count of octets) followed by the article in
   native storage mode for "opsys." (e.g, no NETASCII conversion).
   After <bytecount> bytes are sent and received, the sender and
   receiver will return to NETASCII mode.  It is therefore imperative
   that <bytecount> be accurate, as otherwise command/response
   synchronization will be lost.  Currently the only defined "opsys" is
   "UNIX", which implies that the articles to be transmitted are a
   stream of characters with LF line separators.

   (Note that this will save some processing on both ends of a
   connection when the systems are running the same operating system.
   It is NOT the intention that non-homogeneous operating systems build
   translation mechanisms; that's what the default NETASCII is for.)

   BATCH [desiredbatchsize] - in batch mode, the way that articles are
   transferred changes: instead of transmitting an article immediately
   after receiving the 335 response indicating that the article is
   desired by the server, the client will add the article to a batch of
   articles to be sent.  When adding the next article to the batch would
   exceed the (specified, else default) batchsize or there are no
   further articles to offer, the client will send the BATCH command,
   wait for a 336 response indicating the server is ready for the batch,
   then send the articles in one transmission.

   For this option, the "will do" response will contain a decimal
   maximum number of bytes in the batch, as in
           204 65536 is the batchsize I'll use



Kantor                                                  FORMFEED[Page 3]





RFC DRAFT                                                    August 1990


   The batchsize will never exceed the desired batchsize given in the
   option request, but may be smaller.  It is the responsibility of the
   client not to exceed this limit when sending multiple articles in a
   batch.

   A batch of articles is as described in RFC1036.  If IMAGE mode is in
   effect, the bytecount is given in the BATCH command and the entire
   batch is sent as a native-mode stream of characters.  In non-IMAGE
   transmission, the batch is sent as a single transmission which ends
   with a dot on a line by itself.

   If a single article would be larger than <batchsize>, it is sent as a
   one-article batch.  This is an exception to the requirement that a
   client not exceed the server's specified batchsize.

   [It is recommended that the batchsize be configured based on known
   characteristics of the communications medium; i.e., a high-speed
   low-loss network would use large batches, perhaps approaching 1
   megabyte.  Moderate-speed networks might find a batch size of 64K
   more practical.]

   IBATCH [bytecount] - specifies that the list of articles that the
   client has to offer the server will be sent after the IHAVE as a
   textual transmission, one message-id per line.  After the terminating
   period (or "bytecount" bytes if IMAGE mode is in effect) is received
   by the server, it will acknowledge with a
           337 [bytecount] send me the following articles
   message and will then transmit a list of the desired articles, one
   message-id per line, to the client.  The client is expected to
   receive the entire textual list and then begin sending articles (or
   batches containing those articles) in the order requested.

   If an article requested is not available when it comes time to
   transmit it, no error results - it is just omitted.

   For this option, the "will do" response will contain a decimal
   maximum of message-ids in the ibatch, as in
           204 1024 is my IBATCH size
   It is the responsibility of the client not to exceed this limit when
   sending the list of message-ids.

   COMPRESSION [<compression-method>] - specifies that textual
   transmissions are to be compressed using a method agreed upon by the
   system administrators concerned.  If systems are capable of multiple
   compression methods, the option may specify which one is to be
   employed by using an agreed-upon keyword.  It is most probable that
   compression will require transparent 8-bit paths and would be of most
   use in conjunction with the BATCH and IBATCH options.



Kantor                                                  FORMFEED[Page 4]





RFC DRAFT                                                    August 1990


   NEW COMMANDS

   BATCH [bytecount] see the BATCH option discussion above. Note that it
   is NOT necessary to have gone through the IHAVE article-id query step
   before feeding a batch; by prearrangement, if you are the only feed
   to a site and wish to unconditionally transmit everything, you can
   just batch it all up and ship it all without asking about individual
   articles.

   Responses:
           336 ship the batch
           236 batch arrived ok
           436 transfer failed

   DATE returns the GMT date and time as known to the server in ISO3307
   format
           111 YYYYMMDDhhmmss[.xxxxxx]
   ex:     111 19891231010203.025

   This timestamp is designed to be turned around and used for the
   newgroups and newnews commands; it isn't accurate enough to
   synchronize clocks - use NTP for that.  Perhaps you should think of
   it as a magic cookie instead of a real time of day.

   AUTHINFO [authtype] [authdata] This command is used to transmit
   authenication data to the server.
   Responses are
           280 authentication accepted
           380 further authentication info needed
           381 <authtype> further authentication info needed
           382 authentication challenge text follows
           481 authentication rejected
           580 authentication failed, goodbye

   How this is used is discussed below.

   Presumably the server may wish to add time delays or a maximum number
   of tries and/or logging to detect or discourage marauders.

   [optional]
   HEADER headerfield[,headerfield] [<messageid>|articlerange]

   Extracts specified fields from article headers.

   headerfield is an RFC1036 case-insensitive header field, minus the
   trailing colon.  Several headerfield requests may be combined in one
   command separated by commas; the limit is that of command length.




Kantor                                                  FORMFEED[Page 5]





RFC DRAFT                                                    August 1990


   articlerange is one of: an article number an article number followed
   by a dash to indicate all following an article number followed by a
   dash followed by another article number.
   e.g.,
   HDRX subject                    extract subject of current article
   HDRX from 5589-6325             extract from of arts 5589 to 6325
   HDRX subject 5589-              extract subject of arts 5589 and up
   HDRX subject,from 5589          extract subject & from of art 5589 only
   HDRX subject <123@ucbvax>       extract subject of art <123@ucbvax>

   Response:
           224 header extracts follow
           numberingroup headertext
           numberingroup headertext
           .

   <numberingroup> is the ordinal number of the article in the current
   group; if no group is currently selected or the article is not in the
   current group when retrieving by article-id instead of a range of
   article numbers, then <numberingroup> may be set to zero.

   <headertext> is the entire header line, unfolded and truncated at the
   NNTP line limit.  It includes the header field: e.g., one multi-field
   response might be
           42 Message-id: <872.243.2343@longid.toronto.edu>
           42 Subject: wombats
           .

   Multiple article requests will return information extracted from
   articles in the requested article order; multi-field requests will
   return all the fields from a single article together before sending
   information from a succeeding article.  No order of header lines is
   specified within the article.

   Note that this command is a modification of the popular but
   nonstandard XHDR command.  Servers desiring to retain backward
   compatability by providing XHDR can probably share a great deal of
   common code when performing this command.

   Note also that you can use this to provide a list of the articles
   actually available in a sparsely-populated newsgroup by simply asking
   for a required headerfield such as message-id.

   [optional]
   NEWUSER - the server returns a unique string which can be used as a
   userid for news statistics gathering purposes.  The intent is to have
   the news client obtain one of these and hang on to it for life; it's
   primarily of use when the client is a newsreader which does not have



Kantor                                                  FORMFEED[Page 6]





RFC DRAFT                                                    August 1990


   a login/security mechanism of its own (i.e., a small system such as
   an IBM-Pclone or a Macintosh) and the news server doesn't implement a
   more extensive authentication system.  The server could gather
   statistics indexed by userid; this allows the automatic assignment of
   such for that purpose.

   [optional]
   SEARCH The response
           390 send search parameter text
   tells the client to send a series of search parameters, which may
   include header fields to look for, keywords, or other possible
   searching strategies.  Sort or retrieval order may also be possible
   to specify.  The search specification is sent as a textual
   transmission (i.e., period-on-a-line-by-itself or bytecount as
   above).  The response from the server will be
           490 invalid search spec
           391 no articles selected
   or
           392 nnnn articles selected
   followed by a textual transmission listing the message-ids of the
   articles as selected by the search specification.

   I anticipate search specs to be things like
           AUTHOR!Obnoxoid@qwerty.com
           GROUP=soc.sex
           GROUP=comp.pregnant
           GROUP=rec.suicide
           SUBJECT!.*Re:.*
           SORT BY Date:
   etc.

   [optional]
   ACCESS privilege [modifier]

   ACCESS followed by a command will return a response indicating
   whether the access implied by that command is allowed in your current
   context.  XFER, READ, and POST are the privileges currently defined.
           270 <privilege> access granted
           470 <privilege> access denied

   A new general response for all commands is added:
           471 insufficient privileges for command

   The ACCESS command simply tells you if what you want to do is
   allowed.  A client can use it to see if need bother with
   authentication procedures or to enquire before attempting some
   command.  Note that it is, strictly speaking, not necessary to use
   the ACCESS command as a server will respond to an unauthorized



Kantor                                                  FORMFEED[Page 7]





RFC DRAFT                                                    August 1990


   command with the 471 response.

   It is anticipated that the actual access will be determined by an
   access control matrix whose parameters may include such things as
   time of day, who you are, what host you're on, what group you want,
   and what you want to do.  Thus ACCESS requests may indeed turn out to
   be complex to process if a site chooses to implement complex
   security.

   I see ACCESS requests for standard NNTP commands (such as the
   following) being standard:
   ACCESS XFER, implying the use of
           BATCH
           IBATCH
           IHAVE
           INFO
           NEWNEWS
           NEWGROUPS

   ACCESS READ, implying the use of
           ARTICLE
           BODY
           GROUP
           HEAD
           LAST
           NEWNEWS
           NEWGROUPS
           NEXT
           SEARCH
           STAT

   ACCESS POST

   and extensions such as

   ACCESS READ PRIVATE
   ACCESS READ NON-WORK-RELATED
   ACCESS READ alt.sex
   ACCESS POST comp.unix.wizards
   ACCESS MAINT

   as part of the access control that some sites might wish to
   implement.








Kantor                                                  FORMFEED[Page 8]





RFC DRAFT                                                    August 1990


                                Encryption:
                                ----------
   This standard attempts to make provisions for the use of whatever
   kind of encryption mechanism a particular site may choose to use.
   Thus no specific encryption method is called for here.  Some sites
   may wish to use no encryption;  others may use encryption methods
   which do not require the transmission of keys or which handle this
   outside of the established NNTP connection.

   Others may wish to use methods which do require the "in-band"
   exchange of keys.  In-band exchange of key data does present a
   problem: the command and response strings must conform to NETASCII
   requirements.  Thus sites using encryption methods which generate or
   use keys containing non-printable-ASCII characters should convert
   those keys to a printable form (perhaps hexadecimal notation) for
   in-band transmission.  Such KEYS can be sent as additional parameters
   to the request to set the CRYPTO option.


                              Authentication:
                              --------------
   The purpose of the authentication provisions in this standard are to
   allow for the implementation of nearly any authentication method that
   sites wish to use.  One thing to keep in mind is that NNTP is NOT a
   general-access protocol such as FTP; in general, NNTP connections are
   either set up by prearrangement between system administrators or are
   contained within one particular bailiwick, such as a college campus.
   Therefore general access procedures are not necessarily required - it
   may only be necessary to prove that you are who you claim you are,
   without much consideration of what to do if you aren't.

   Several scenarios may help explain how the authentication hooks I've
   added are intended to be used.

   1. site with no authentication requirements

   > 200 wombat.no.where NNTPv2 server at your command
   (regular NNTP transactions follow)

   2. site with user-only authentication (probably just for collecting
   readership statistics):
   > 200 throne-of-blood.ucsd.edu NNTPv2 server ready
   < AUTHINFO USER earnest
   > 280 authentication accepted
   (regular NNTP transactions follow)

   3. site which allows anyone to read articles, but you have to prove
   who you are to post them



Kantor                                                  FORMFEED[Page 9]





RFC DRAFT                                                    August 1990


   > 200 friendly.news.net NNTPv2 stick it to me
   (reads a bunch of stuff)
   < POST
   > 470 insufficient privileges for command
   < AUTHINFO USER wizard
   > 381 <PASS> further authentication info needed
   < AUTHINFO PASS superbeing
   > 280 authentication accepted
   < POST
   (regular NNTP transactions follow)

   4. site which uses out-of-band authentication procedures (i.e., the
   actual authentication is done outside of the NNTP protocol
   transactions, but isn't automatic).
   > 200 purity-of-essence.army.mil NNTPv2 what is your need to know?
   (authentication takes place outside of NNTP protocol)
   > 280 authentication accepted
   (regular NNTP transactions follow)

   It is anticipated that actual access will be determined by an access
   control matrix whose parameters may include such things as time of
   day, who you are, what host you're on, what group you want, and what
   you want to do.  That's an implementation decision; the protocol need
   only support the communications required for such.


   Author's  Address:

   UCSD Network Operations
   UCSD C-024
   La Jolla, CA 92093-0124 USA
   brian@ucsd.edu



















Kantor                                                 FORMFEED[Page 10]