Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction

[USENET news manager <[e-mail]>]

Rich Salz wrote:
>
>>Given that creating the NNTP-Posting-User header may involve inserting
>>information from an external and potentially malicious source
>
>Don't do that.
>
>I mean this in a more than flip manner.  If the server is attempting to
>identify who the client is, and report that information, then it must
>have a way of being able to trust the information that it puts out there.
>This *might* mean, for example, an admin-maintained list of ipaddr's
>where identd can be trusted (e.g., general timesharing machines).

That would be totally unworkable in many situations - e.g. here, in a 
university environment where I have no control over most of the 15K+ systems
registered on our network (probably 20% of them running UNIX, rest mostly 
DOS/Windows PCs and Macintoshes) and a great many of the systems are managed
by their owner, some graduate student that got landed with the job, ... in 
particular, with minimal central control. Probably many thousands of
distinct system managers (for varying definitions of system manager). In the
case of the LINUX boxes, most people probably don't even realise they're
typically giving ident responses out-of-the-box.

In an ISP environment, to take another example, where they provide dialup IP
connectivity for individual systems or for whatever network the customer
has, they are not going to have the time to ask whether ident can be trusted
on any, or all, the systems a particular customer has today, and no telling
whether it will true for the systems connected tomorrow. They've no way of
knowing, in any case, if the person they ask is telling the truth. As long
as they pay the bills and stick to the Acceptable Use Policy...

If you insist on only "guaranteed" (for some random definition) identity
information being included, you probably might as well not bother defining
the header, because it will be used so rarely as to be useless.

>If you're just gonna randomly connect somewhere and take whatever spews out,
>then why not just let the bloody client put whatever value they want?

For a start, because in many cases the information will be more trustworthy 
than information supplied by the newsreader/user, though of course in many
cases these days the sysadmin of a random UNIX box is also the user. Even
there the ident information may be more reliable, as in the case of LINUX 
boxes providing it without the sysadmin (=potentially malicious user) even
realising it's set up by default.

In any case, without some form of tamper-proof signing of all articles, 
you've no assurance that some server between the originating system and you
has not altered the headers (and/or body), even if the ident info or 
whatever was reliable at the point of posting.

On the other hand ... the information in the header, as it reaches you,
DOES provide potentially valuable information. It *may* be accurate. Only
the person running the originating system will know for sure how reliable
it is (and that person may be out to mislead you and dodge responsibility), 
but for a well-run system with responsible management, if you can point
out that user xyz as identified in the header (assuming it reached you 
unmodified, so they would have to be cautious in trusting what you told 
them) on their system abc sent an article which was objectionable for
some reason, that may at the very least be sufficient for them to have a 
word with the person concerned. Or after cross-checking with their logging, 
they might be 99.9% certain that the person really was responsible and take
more serious action, or take a harder line during the interview ("you did 
this, why?" rather than "did you do this?").

                                John Line

-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)