1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
|
Authentication to a NNTP server with tin
Tin is able to do authentication to news servers according to the "Common
NNTP Extensions" (see below). There are several ways of authentication
described in that text which are referred to as Original AUTHINFO, AUTHINFO
GENERIC, and AUTHINFO SIMPLE. Tin supports the Original AUTHINFO and the
AUTHINFO GENERIC methods. In addition to answers to authentication requests
as described in the "Common NNTP Extensions", tin also provides
authentication at connection startup.
Authentication is always done in the same manner: First, tin tries an
AUTHINFO GENERIC authorization. If this fails, Original AUTHINFO is used.
Authentication requests will be handled whenever they occur; the command
that caused the request will be sent again.
For an authentication with the Original AUTHINFO method, tin needs a
user-name and a password for the current news server. This information is
obtained from a file .newsauth in the TIN_HOME directory. The format of the
.newsauth file is as follows:
news.server1 password1 [username1]
news.server2 password2 [username2]
...
The first line matching the current news server is taken. The delimiters
between the fields MUST be spaces. If a password contains spaces, you have
to surround the whole password by double quotes. If no user-name is given
for the current news server, the user-id of the user who started tin is
assumed.
Security consideration: tin does not prove if the .newsauth file could be
read by others. The user is responsible for accurate permissions.
If you do not have a .newsauth file in your TIN_HOME directory, tin prompts
you for a user-name and a password. This is NOT done at connection startup,
because there is no way for tin to find out if an authentication at this
time is needed. If you need to authenticate at the beginning of your news
session, you MUST provide a .newsauth file.
The AUTHINFO GENERIC authentication was implemented by someone else and has
not been tested by me since I do not know a server that supports this.
To use AUTHINFO GENERIC, set up an environment variable NNTPAUTH with the
command and its parameters to invoke for authentication. The content of
NNTPAUTH is also used as the authenticator in the AUTHINFO GENERIC response
to the server. The environment variable NNTP_AUTH_FDS is used to store file
descriptors for reading from and writing to the server, and for a temporary
file ("cookie"); the three descriptors are separated by dots. The
authentication command can take use of NNTP_AUTH_FDS when invoked; it should
exit successful if the authentication was accepted.
If NNTPAUTH is empty or not available, tin sends an "authinfo generic any
<user-id>" command to the server and expects the result as an NNTP response
code.
The AUTHINFO SIMPLE authentication method is not supported by tin. If you
need this, drop me a message or see the source code in auth.c. With the
specification below, the implementation should not be difficult.
Dirk Nimmich (97-04-05)
<nimmich@uni-muenster.de>
---- cut here ---- Barber: Common NNTP Extensions ----
[Complete document at
<URL:http://src.doc.ic.ac.uk/computing/internet/internet-drafts/draft-barber-nntp-imp-05.txt.Z]
INTERNET-DRAFT S. Barber
Expires: December 1, 1996 Academ Consulting Services
July 1996
Common NNTP Extensions
draft-barber-nntp-imp-05.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.''
[...]
3. Other Extensions
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.
It first appeared in the UNIX reference implementation.
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
response, 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 a proposed NNTP V2
specification, which was started in 1991 but never completed,
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
proposed 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[8]
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.
[...]
5.0 Security Considerations
The use of the AUTHINFO is optional. This command as documented
has a number of security implications. In the original and simple
forms, all passwords are passed in plaintext and could be
discovered by various forms of network or system surveillance.
The AUTHINFO GENERIC command has the potential for the same
problems if a mechanism is used that also passes cleartext
passwords. RFC 1731[8] discusses these issues in greater detail.
[...]
This document expires December 1, 1996.
---- cut here ---- End of Barber: Common NNTP Extensions ----
|
