ietf-nntp New draft available

[Chris Lewis]

In message "Re: ietf-nntp New draft available", 
'sob at academ.com' writes:
>> Section 9.1.2 page 12: I don't understand the comment about "reissuing the
>> command that prompted the 350". It *appears* to me that this is saying that
>> *any* command can return a 350 code, even if the specific description
>> doesn't mention it. If not, what does it mean ? The only references to 350
>> I can find are in the AUTHINFO command itself, and the request for
>> authentication is actually a 205 response from the greeting or MODE READER.
>> Whatever's going on here, it needs rewriting.

>I will see what I can do about clarifying it. Perhaps Chris can comment on
>this further.

I note that you have revised the return codes extensively with the
Transition Issues section.  And I think you've gotten confused with the
350/450 stuff.  The transition issues documentation is incorrect.

Existing implementations use "480" not "350" - I think you should be using
450 here, not 350.  "381" (and hence 350 now) was only for AUTHINFO USER/PASS,
and hence it doesn't apply here.

Here's the return codes for AUTHINFO GENERIC as currently implemented
in INN and NNTP 1.5.12+:

	480	Authentication required

	500	If "authinfo" is an unknown command
	501	If only "authinfo user/pass" is supported.
	501	If a detectable error was found in the command
		(eg: ../ in authenticator, no parameters after
		"authinfo generic" etc.)
	502	authentication failed
	281	authentication succeeded
	503	If authenticator could not be invoked (missing,
		fork failed etc.  Try authentication again.)
	nnn	authenticator-specific protocol.

In a nutshell, then, a GENERIC session might now look like this:

	C: LIST GROUPS
	S: 450 Authentication required
	C: AUTHINFO GENERIC <args>
	S: nnn (where nnn is either an authinfo return, or an authentication
	   specific return[*]
	C: <auth specific>
	S: <auth specific>
	...
	S: 250 Authorization Accepted OR S: 452 Authentication rejected
	C: LIST GROUPS			 C: try again or shut down
	S: LIST GROUPS response

[*] Note that there is no explicit code for "go ahead with next step of
authentication" here - you either get the server saying "whoops it broke",
or, the server-side authenticator launches straight into the first response
code in its dialog.  In effect, the authenticator's dialog starts out with
a "provide me with your credentials" return code.  I don't think there
needs to be a "Continue with authentication" code, then have the client
side explicitly say "okay, starting", but I'm open for suggestions.

To clarify the question at hand, the server can respond with a "authentication
needed" (was 480, now should be 450) after _any_ command, except (as per the
sources I've reviewed for INN):

	MODE READER
	DATE
	AUTHINFO (for obvious reasons ;-)
	HELP
	SLAVE

Theoretically, as long as it doesn't do it for AUTHINFO, things should be
fine.  It wouldn't hurt to require authentication for the other four.

Part of the rationale for this is, for example, that the server doesn't
know what list of groups to provide to the user until after authentication.
A newsreader could get very confused if it did a LIST GROUPS, and then
after authentication, groups disappeared.
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 8M86, Ottawa, Canada.  (613) 763-2935.