>There have been several requests for help with authentication over the
>past few months.
>
>If anyone wants to adapt an existing REXX posting utility to handle
>authentication, here's a start! Ethan's REXX script is about 11k
>or 400 lines with comments. I will mail (or post) it if requested.
>
Hi everyone. I would love to have a copy of this so I play with it. I
would really like to get the NNTP authentication working with Souper/Yarn
> I'm not really familair with the NNTP
>codes involved beyond the server just saying it requires authorization.
Firstly Sorry to Lou Verdon for not forwarding the attached document to
him earlier like I had promised. I have snipped it heavily so that only
relevant parts are included in this message. Secondly, sorry to anyone
who isn't interested in this for the long message. Thirdly, to anyone who
is interested, see attached document for the current NNTP authentication
protocol.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you know how to use PGP and support its use please encrypt all mail
to me. The more PGP traffic across the internet the more commonplace it
will be and the harder it will be to ban and to crack the sensitve messages
I have a new key (12 Aug 1996). Please replace 0x335FEA39 with 0x51187691.
Available by finger -l goodyer@voicenet.com
Fingerprint of new key: 13 F8 C2 E6 ED BB 21 93 84 E3 0C A9 19 36 A8 BD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
INTERNET-DRAFT S. Barber
Expires: September 1, 1996 Academ Consulting Services
April 1996
Common NNTP Extensions
draft-barber-nntp-imp-03.txt
Status of this Document
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
In this document, a number of popular extensions to the NNTP
protocol defined in RFC977 are documented and discussed. While
this document is not intended to serve as a standard of any kind,
it will hopefully serve as a reference document for future
implementors of the NNTP protocol. In the role, this document
would hopefully create the possibility for some level of
interoperability among implementations that make use of extensions.
<BIG SNIP>
3.1 AUTHINFO
AUTHINFO is used to inform a server about the identity of
a user of the server. In all cases, clients must provide
this information when requested by the server. Servers are
not required to accept authentication information that is
volunteered by the client. Clients must accommodate servers that
reject any authentication information volunteered by the client.
There are three forms of AUTHINFO in use. The original version,
an NNTP v2 revision called AUTHINFO SIMPLE and a more recent
version which is called AUTHINFO GENERIC.
3.1.1 Original AUTHINFO
AUTHINFO USER username
AUTHINFO PASS password
The original AUTHINFO is used to identify a specific entity
to the server using a simple username/password combination.
When authorization is required, the server will send a 480
response requesting authorization from the client. The
client must enter AUTHINFO USER followed by the username.
Once sent, the server will cache the username and may send
a 381 response requesting the password associated with that
username. Should the server request a password using the 381
respose, the client must enter AUTHINFO PASS followed by
a password and the server will then check the authentication
database to see if the username/password combination is valid.
If the combination is valid or if no password is required,
the server will return a 281 response. The client should then
retry the original command to which the server responded with
the 480 response. The command should then be processed by
the server normally. If the combination is not valid, the server
will return a 502 response.
Clients must provide authentication when requested by the server.
It is possible that some implementations will accept authentication
information at the beginning of a session, but this was not the
original intent of the specification. If a client attempts to
reauthenticate, the server may return 482 response indicating
that the new authentication data is rejected by the server.
The 482 code will also be returned when the AUTHINFO commands
are not entered in the correct sequence (like two AUTHINFO
USERs in a row, or AUTHINFO PASS preceding AUTHINFO USER).
All information is passed in cleartext.
When authentication succeeds, the server will create an email
address for the client from the user name supplied in the
AUTHINFO USER command and the hostname generated by a reverse
lookup on the IP address of the client. If the reverse lookup
fails, the IP address, represented in dotted-quad format, will
be used. Once authenticated, the server shall generate a Sender:
line using the email address provided by authentication if it
does not match the client-supplied From: line. Additionally,
the server should log the event, including the email address
This will provide a means by which subsequent statistics generation
can associate newsgroup references with unique entities - not
necessarily by name.
3.1.1.1 Responses
281 Authentication accepted
381 More authentication information required
480 Authentication required
482 Authentication rejected
502 No permission
3.1.2 AUTHINFO SIMPLE
AUTHINFO SIMPLE
user password
This version of AUTHINFO was part of the proposed NNTP V2
specification and is implemented in some servers and clients.
It is a refinement of the original AUTHINFO and provides
the same basic functionality, but the sequence of commands
is much simpler.
When authorization is required, the server sends a 450 response
requesting authorization from the client. The client must enter
AUTHINFO SIMPLE. If the server will accept this form of
authentication, the server responds with a 350 response. The
client must then send the username followed by one or more
space characters followed by the password. If accepted, the
server returns a 250 response and the client should then
retry the original command to which the server responded
with the 450 response. The command should then be processed
by the server normally. If the combination is not valid,
the server will return a 452 response.
Note that the response codes used here were part of the
NNTP V2 specification and are violations of RFC 977. It
is recommended that this command not be implemented, but
use either or both of the other forms of AUTHINFO if such
functionality if required.
3.1.2.1 Responses
250 Authorization accepted
350 Continue with authorization sequence
450 Authorization required for this command
452 Authorization rejected
3.1.3 AUTHINFO GENERIC
AUTHINFO GENERIC authenticator arguments...
AUTHINFO GENERIC is used to identify a specific entity to the
server using arbitrary authentication or identification
protocols. The desired protocol is indicated by the
authenticator parameter, and any number of parameters can
be passed to the authenticator.
When authorization is required, the server will send a 380
response requesting authorization from the client. The
client should enter AUTHINFO GENERIC followed by the
authenticator name, and the arguments if any. The authenticator
and arguments must not contain the sequence "..".
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.
If the server returns 501, this means that the authenticator
invocation was syntactically incorrect, or that AUTHINFO
GENERIC is not supported. The client should retry using the
AUTHINFO USER command.
If the requested authenticator capability is not found or
there is some other unspecified server program error, the
server returns the 503 response code.
The authenticators converse using their protocol until complete.
If the authentication succeeds, the server authenticator will
terminate with a 281, and the client can continue by reissuing
the command that prompted the 380. If the authentication fails,
the server will respond with a 502.
The client must provide authentication when requested by the
server. The server may request authentication at any
time. Servers may request authentication more than once
during a single session.
When the server authenticator completes, it provides to the
server (by a mechanism herein undefined) the email address
of the user, and potentially what the user is allowed to
access. Once authenticated, the server shall generate a Sender:
line using the email address provided by the authenticator
if it does not match the user-supplied From: line. Additionally,
the server should log the event, including the user's
authenticated email address (if available). This will provide
a means by which subsequent statistics generation can
associate newsgroup references with unique entities - not
necessarily by name.
3.1.3.1 Responses
281 Authentication succeeded
380 Authentication required
501 Command not supported or Command syntax error
502 No permission
503 Program error, function not performed
nnn authenticator-specific protocol.
<ANOTHER BIG SNIP>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMhn4UqJSmGBRGHaRAQEtrwQAhl910MSHPL9vNL1NDcNnJOIZc6+JHkPX
7QlCX2EF7fr6mxrEawOxnq9zW3u/bSNwcvL0+Jq6y6DuFAdUQYhSBwy7ysmnjz9m
tMvcmjlL3ZE+iZQAxGlSrdn7ii5MxynFEgmK4zX9yI7S0dwNEf2cZaEW8BwZhN7w
1MXAHmxtkX8=
=/mvT
-----END PGP SIGNATURE-----