ietf-nntp Minutes from the WG (these have been submitted to IETF)

[Chris Lewis]

In message "ietf-nntp Minutes from the WG (these have been submitted to IETF)", 
'sob at owlman.academ.com' writes:

I hope this assists you.  Sorry I couldn't make it to the meeting.

>There was a suggestion to provide a mechanism for getting the various
>AUTHINFO GENERIC mechanisms supported. Chris Lewis was not at the meeting,
>but his input will be solicited. Such information could be returned
>as part of a LIST EXTENSIONS response or another command or as a response
>to AUTHINFO GENERIC without any arguments.

I was anticipating do this via "AUTHINFO GENERIC LIST", and have LIST
be a authentication scheme that provides the list of authentications
available, then "nests" to a selected one.  The advantage to this is
that NNTP doesn't need to define how this is done.  The disadvantage
is that I may have to get around to doing some sort of AUTHINFO GENERIC
subprotocol spec/BCP a bit sooner than I thought.

Do people consider this acceptable?  As in, can we leave how to do
"LIST" out of the spec and leave it to a later date - assuming for now
that browser-end authenticators "know" which ones are available?  Then
LIST can be added later without touching the NNTP spec.

We might simply want to say that "LIST" is a reserved authentication type. 

>There was also a request to
>clarify which commands are subject to authorization and to clarify the
>difference between the 450, 452 and 502 responses when doing various forms
>of access control. 502 was not included in AUTHINFO section of the current 
>draft except in the "transition issues" section. It was strongly suggested 
>that 502 be used when there is no access to this command irrespective of 
>authorization credentials.

The return codes have been changed on me so many times, I have to read
the spec again.

>There was also some confusion about the requirement
>to log the email address in the AUTHINFO GENERIC section. Since this was
>included based on information from Chris Lewis, he will need to be polled
>about this as well.

The intent here is that the server can use this to provide or check
a "Sender:" or "NNTP-Posting-User" or such like header.  Doesn't need to
be the email address of the originator or even mailable at all - merely
needs to be a RFC822-formatted address that allows the site admin to
identify the user, or generate X-trace headers or whatever.

Ie: <random number>@<your domain> (as in 0900639 at nortel.com) is perfectly
fine.  I want to be able to specify separate domains here, so that we
can disambiguate between multiple domains here.

>Finally, there was discussion about how information
>made available to a client may change depending on the change in authentication
>credentials. There was a general discussion about how the response from
>LIST might differ depending on the current state of credentials. RFC 977
>was not clear on this. Many implementations do not do restrictions on the 
>response to LIST, but when individual GROUP commands are issued for groups 
>for which the client does not have adequate credentials, access may be 
>denied.

The existing prototype implementations (INN & latest NNTP) insist on
authenticating before responding to any command that can see group
content, or list groups, and through serendipity, "LIST GROUPS" only
lists the groups that they have access to.  I would prefer to
retain this behaviour.

This has practical implications:
	- if you tell a user about a group, but the server refuses to
	  serve it, some browsers get upset.
	- if you tell a user about a group, then later authentication
	  causes LIST GROUP to not mention the group, many browsers will
	  treat the group as bogus and get very upset.
	- Wearing my security hat, even revealing the names of forbidden
	  groups is bad.

In my prototype implementation, nnrpd.c (defines the commands) is thus:

Those with TRUE in the third column require authentication:

    {	"authinfo",	CMDauthinfo,	FALSE,	3,	CMDany,
    {	"article",	CMDfetch,	TRUE,	1,	2,
    {	"body",		CMDfetch,	TRUE,	1,	2,
    {	"date",		CMDdate,	FALSE,	1,	1,
    {	"group",	CMDgroup,	TRUE,	2,	2,
    {	"head",		CMDfetch,	TRUE,	1,	2,
    {	"help",		CMDhelp,	FALSE,	1,	CMDany,
    {	"ihave",	CMD_unimp,	TRUE,	1,	2,
    {	"last",		CMDnextlast,	TRUE,	1,	1,
    {	"list",		CMDlist,	TRUE,	1,	3,
    {	"listgroup",	CMDgroup,	TRUE,	1,	2,
    {	"mode",		CMDmode,	FALSE,	2,	2,
    {	"newgroups",	CMDnewgroups,	TRUE,	3,	5,
    {	"newnews",	CMDnewnews,	TRUE,	4,	6,
    {	"next",		CMDnextlast,	TRUE,	1,	1,
    {	"post",		CMDpost,	TRUE,	1,	1,
    {	"slave",	CMD_unimp,	FALSE,	1,	1,
    {	"stat",		CMDfetch,	TRUE,	1,	2,
    {	"xgtitle",	CMDxgtitle,	TRUE,	1,	2,
    {	"xhdr",		CMDxhdr,	TRUE,	2,	3,
    {	"xover",	CMDxover,	TRUE,	1,	2,
    {	"xpat",		CMDxpat,	TRUE,	4,	CMDany,
    {	"xpath",	CMDxpath,	TRUE,	2,	2,
    {	"xthread",	CMDxthread,	TRUE,	1,	2,
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 8M86, Ottawa, Canada.  (613) 763-2935.