Re: ietf-nntp New draft available
Chris Lewis <clewis@nortel.ca> Tue, 02 September 1997 18:29 UTC
Received: from cnri by ietf.org id aa18618; 2 Sep 97 14:29 EDT
Received: from announcer.academ.com (majordomo@ANNOUNCER.ACADEM.COM [198.137.249.60]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid OAA24819 for <ietf-archive@cnri.reston.va.us>; Tue, 2 Sep 1997 14:26:44 -0400 (EDT)
Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.8.5) id NAA25067; Tue, 2 Sep 1997 13:21:07 -0500 (CDT)
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.8.5) with ESMTP id NAA25062 for <ietf-nntp@ANNOUNCER.ACADEM.COM>; Tue, 2 Sep 1997 13:21:05 -0500 (CDT)
Received: from bcarsde4.localhost (mailgate.nortel.ca [192.58.194.74]) by academ.com (8.8.5/8.8.5) with ESMTP id NAA09889 for <ietf-nntp@academ.com>; Tue, 2 Sep 1997 13:20:44 -0500 (CDT)
Message-Id: <199709021820.NAA09889@academ.com>
Received: from bcarsfba.ott.bnr.ca (actually bcarsfba.bnr.ca) by bcarsde4.localhost; Tue, 2 Sep 1997 14:18:52 -0400
Received: from bnr.ca by bcarsfba.bnr.ca id <21164-0@bcarsfba.bnr.ca>; Tue, 2 Sep 1997 14:17:52 -0400
Date: Tue, 02 Sep 1997 14:12:00 -0400
To: ietf-nntp@academ.com
From: Chris Lewis <clewis@nortel.ca>
Subject: Re: ietf-nntp New draft available
Sender: owner-ietf-nntp@academ.com
Precedence: bulk
In message "Re: ietf-nntp New draft available", 'sob@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@nortel.ca; Dept 8M86, Ottawa, Canada. (613) 763-2935.
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Chris Lewis
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Stan Barber
- ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Jonathan Grobe
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Jack Hudler
- Re: ietf-nntp New draft available Brian Kantor
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Clive D.W. Feather
- Re: ietf-nntp New draft available Stan Barber
- Re: ietf-nntp New draft available Clive D.W. Feather
- Re: ietf-nntp New draft available Paul Overell
- Re: ietf-nntp New draft available Stan Barber