jbuck@epimass.EPI.COM (Joe Buck) (01/25/88)
Lately, the net has suffered because of a rash of forgeries.
Controversial posters such as Mark Ethan Smith and Matt Weiner have
been the main victims so far, and I know that neither of these people
is wildly popular with news administrators, but the latest incident
-- a forged newgroup message pretending to be from Gene Spafford --
should give us all pause. If we don't stomp hard on this now,
the net will never be the same again. One of the things I like
about the net is the ability to get the definitive word from somebody
like Dennis Ritchie. If the current trend continues, you'll no
longer have any confidence whether that was the real Dennis Ritchie
or an imposter. And the flame wars will be endless.
Some suggested administrative steps:
1) If you get caught forging a message impersonating another poster,
except for April Fool's day which we'll continue to allow as a day to
fool around a bit, you're off the net, forever. Sites not enforcing
this rule (after being asked to) lose their feed. I don't see how
anything less than the net equivalent of the death penalty is going
to suffice considering how hard it is to catch someone.
2) If a knowledgeable news administrator sees a message with a forged
Approved: header or other such shenanigans, that news administrator
can (and should be encouraged to) issue a forged Cancel message, but
the text of the cancel message should contain the true name of the
person doing this and an explanation of why it's being done.
3) We all make a more concerted effort to track down forgeries and
then apply rule #1.
I had an idea for a partial software solution that would just install
checks at backbone sites (bypassing the problem of getting everyone
to update their software) but it requires more thought. The idea
would be that there are "registered users" who have keys distributed
to all the backbone sites, and articles from, or approved by, these
users would be checked, and rejected if the check fails. This would
prevent forgeries from propogating beyond the backbone. If I ever
get it cleaned up I'll propose it.
--
- Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck
Old Internet mailers: jbuck%epimass.epi.com@uunet.uu.netchuq@plaid.Sun.COM (Chuq Von Rospach) (01/25/88)
>And the flame wars will be endless. Some would claim they already are, but that's beside the point. >Some suggested administrative steps: >1) If you get caught forging a message impersonating another poster, >except for April Fool's day which we'll continue to allow as a day to >fool around a bit, you're off the net, forever. Sites not enforcing >this rule (after being asked to) lose their feed. Um, this nice, but how to you plan on enforcing it? You going to fly out and personally dismember their modem? (that, by the way, would be a criminal act. I don't condone it, even when justified). You going to hold your breath and turn blue until they do what you want? This even assumes that you can figure out who did it, which I'll claim isn't likely, and be able to prove it to someone in authority, which I'll claim is even sillier -- and you can find someone in authority who cares. >2) If a knowledgeable news administrator sees a message with a forged >Approved: header or other such shenanigans, that news administrator >can (and should be encouraged to) issue a forged Cancel message, but >the text of the cancel message should contain the true name of the >person doing this and an explanation of why it's being done. This assumes, of course, that the forged header doesn't also have the forged real name and the forged real explanation.... But then, we're expecting the forgers to play by the rules and do things that we can track down, like putting their names and phone numbers in the forged message. Here's an alternate set of rules I think is more workable. 1) All forged messages should have the name of the forger in them. They should have the word 'forgery' somewhere in the subject line. 2) All people who commit forgery will place a large, green and purple star on their forehead, so when we see them at usenix we'll know not to talk to them. 3) Any priest who hears of a Usenet forgery in confession shall immediately break his vows and post such knowledge to the net so the backbone can take appropriate action. 4) Forgers, in appropriate action, shall have their fingers cut off at the second knuckle, but only those fingers that it can be proven were used to type the actual message (you can do this by seeing what letters are in the message and what fingers caused them to be typed -- there is no reason to punish an innocent pinky, you know.) 5) Most important, sane, decent, mature people won't forge, because it's a stupid, immature and childish thing to do. The rest we have to live with, since Usenet is insecure and non-securable. 6) Folks who come up with plans to fix Usenet should look at the practicality and implementability of them (and realize that, since the net is going on 10 years old, and realize that since these problems aren't new, believe it or not, if there were simple, implementable plans to fix some of these problems, they would have been thought of and implemented before now). And, Joe, before you decide that I'm being exceptionally hard-ass at you, I'll just say that I've seen this proposal before many times. I've made it once, long ago. The practical reality of Usenet is that we tried a policy of getting malfunctioning sites off the net, and it's unenforcable. We're lucky to be able to FIND malfunctioning sites, much less someone in charge of them or someone upstream of them -- and the reality is, the upstream folks know they're malfunctioning, and don't care. Trying to track down and prove forgery is infinitely harder than that, and the upstream folks will STILL not care. It don't work. Unless you want to come up with a secure Usenet (and I've tried, and the security holes are a little too endemic in the design of the software -- to do it would require major changes in the transport layer that would make transferring news quite painful, especially at the current volume levels), you'll have to live with the idiots. chuq Chuq "Fixed in 4.0" Von Rospach chuq@sun.COM Delphi: CHUQ What do you mean 'You don't really want to hurt her?' I'm a Super-Villain! That's my Schtick!
matt@oddjob.UChicago.EDU (Keeper of the Sacred Tablets) (01/26/88)
I don't think that Joe Buck's suggestions are entirely idiotic, but I
do have one additional drawback to mention. If someone from my site
were to net-misbehave it is quite probable that they would be someone
that I do not have the authority to remove from my system. (I run
these machines, but I don't own them.) Does that mean that one user
can knock my system off the net? (Assuming, of course, that all six
of my news-neighbors want it done.) It would be no easier to cut a
potential forger off at the originating machine than anywhere else
down the line, without pulling his account entirely.
) ... I don't see how
) anything less than the net equivalent of the death penalty is going
) to suffice considering how hard it is to catch someone.
I'm no expert on the penal system, but I had understood that
deterence comes not from the severity of the penalty but from the
certainty of its enforcement. If that's correct then you are going
at the problem from the wrong end.
________________________________________________________
Matt University matt@oddjob.uchicago.edu
Crawford of Chicago {astrovax,ihnp4}!oddjob!mattsyd@dsinc.UUCP (Syd Weinstein) (01/26/88)
I agree that forgeries are a major problem that must be handled.
However, we are dealing with a system that does not allow for
electronic signatures.
I did not write any of the net news software, but perhaps those that
did would consider this option:
In a future release of the software add a check that each site when
receiving forwarded news check that the site prior in the path
matches the forwarder.
This might also have holes and be possible for the forger to add a
message that seemed to come through them to the new site. I only
offer this incomplete suggestion to further the discussion on how
to avoid this going to a full public key encryption system for posting
messages as that would be too much overhead.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP
Datacomp Systems, Inc. Voice: (215) 947-9900
{allegra,bellcore,bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235kraut@ut-emx.UUCP (Werner Uhrig) (01/26/88)
let's not get unduely exited over what has (so far) only been a minor, occasional annoyance. I, for one, am not in favor of increased "law and order" unless it is REALLY needed - as it often turns into a self-imposed straight-jacket. The control-message creating the unauthorized ..mac.programmers group was no more than an annoyance and, certainly, counterproductive (if the originator ever meant them to be anything but a venting of accumulated frustration - which I, personally, doubt) and certainly was easily brought under control. and, as far as those claims and counterclaims from Mark and Matt are concerned, who can (or cares to) distinguish the "real" from the "fake" ??!! let's worry about *REAL* problems .... -- werner@rascal.ics.utexas.edu (prefered address) kraut@emx.cc.utexas.edu kraut@ut-emx.UUCP (or ...!ut-sally!ut-emx!kraut)
richard@gryphon.CTS.COM (Richard Sexton) (01/28/88)
In article <1861@epimass.EPI.COM> jbuck@epimass.EPI.COM (Joe Buck) writes: >Lately, the net has suffered because of a rash of forgeries. >Controversial posters such as Mark Ethan Smith and Matt Weiner have >been the main victims so far, and I know that neither of these people >is wildly popular with news administrators, but the latest incident >-- a forged newgroup message pretending to be from Gene Spafford -- >should give us all pause. If we don't stomp hard on this now, >the net will never be the same again. One of the things I like >about the net is the ability to get the definitive word from somebody >like Dennis Ritchie. If the current trend continues, you'll no >longer have any confidence whether that was the real Dennis Ritchie >or an imposter. And the flame wars will be endless. But does it matter ? Isn't this the Dennis Ritchie Turing test ? If the net is undergoing one of it's periodical 6 months UNIX weenie arguments and a posting from "dmr@alice" comes along and ends the discussion right there, no arguments, does it matter if it REALLY WAS Dennis ? Indeed, how do you know Dennis really wrote 'C' ? Maybe it was Joe Talmadge forging this "Dennis" persons name on everything ? -- "...and before too long I might, see those flashing red lights" richard@gryphon.CTS.COM {ihnp4!scgvaxd!cadovax, philabs!cadovax, codas!ddsw1} gryphon!richard
webber@brandx.rutgers.edu (Webber) (01/29/88)
In article <5300@tut.cis.ohio-state.edu>, karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: >... > If you're sysadmin of the news on your site and you haven't even got > the authority to restrict news access, then I'd suggest that you > either [a] demand such authority or [b] quit, because you're working > in an environment where you can't control your users at all, and hence > can't control your environment, which kind of implies that you're not > being allowed to be a sysadmin after all. Hardly. Instead it sounds more like you were hired to maintain the system rather than boss the users. It is a real shame that so many admins post messages essentially indicating that if they can't boss the users then there is nothing in life worthwhile -- sigh. ----- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
woods@hao.ucar.edu (Greg Woods) (01/29/88)
In article <774@brandx.rutgers.edu> webber@brandx.rutgers.edu (Webber) writes: >It is a real shame that so many admins post >messages essentially indicating that if they can't boss the users then >there is nothing in life worthwhile -- sigh. Unfortunately the term "boss the users" carries implications of a motivation based on craving for power that may not, in fact, be present. As a sys admin I do want to be able to control my users, but only because I do not feel that I can do the job properly without the capability to restrict access to the machine (or a software subsystem such as news) by any user that is, in my opinion, abusing the system or doing something that may either damage the reputation of our organization or interfere with the ability of other users here to make use of the machine. Without this ability I cannot guarantee to do my job, which is to keep things running smoothly so that EVERYONE on the machine can get their work done in harmony. I do not want to "control" anyone beyond this. I don't want to keep news articles containing opinions that I disagree with from being posted. I just want to do my job. Fortunately, very seldom do any of our users need "controlling", and most of the time it has sufficed to issue a warning. More often than not it is ignorance rather than malice that leads to abuse of the system (such as the visiting scientist who did about 8 rlogins back and forth between the same two machines, and the student last summer who was posting dirty jokes unrotated). Similarly it is usually a desire to keep the machine in a state that provides maximum benefit to ALL the users, rather than a desire to "boss", dominate or censor anyone, that prompts sys admins to restrict use of the machine by certain users. --Greg
webber@brandx.rutgers.edu (Webber) (01/29/88)
In article <1129@hao.ucar.edu>, woods@hao.ucar.edu (Greg Woods) writes: > Unfortunately the term "boss the users" carries implications of a motivation > based on craving for power that may not, in fact, be present. ... You are right, it is unfortunate that the ``craving for power'' aspect of this comes out so. Actually, it is laziness that is at the root. If action X breaks the software, rather than fixing the software it is alot easier to announce that all users are forbidden to do action X. Of course, once the power to forbid such actions develops, Lord Acton comes along with corruption and you have people doing all kinds of bizzare things. ------ BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (01/30/88)
webber@brandx.rutgers.edu writes:
Instead it sounds more like you were hired to maintain the system
rather than boss the users.
Try again. I was hired to run these systems. There are 4000
undergrads taking courses from us, of which 827 are computer science
majors, 267 computer science grad students, and 65 faculty, and then
you can add in all the extra accounts on our systems from people not
directly in our department but who have access to our systems for one
reason or another.
The only way to run these systems is to keep control of the users at a
certain level. Usually, this consists of little more than blowing
away umpteen-Mb processes that suck up all the swap space on Wednesday
afternoons. We have a serious security problem which reared its ugly
head just last night. For matters such as these, we boss the users
around, and we don't apologize for it.
I have never actually used the mechanism I described to restrict
users; the /usr/lib/news/authorized file is empty and has been so
since creation. But I keep the tools ready if the need arises. The
need came very close to arising about 2 weeks ago; I'm glad I didn't
have to use it.
It is a real shame that so many admins post
messages essentially indicating that if they can't boss the users then
there is nothing in life worthwhile -- sigh.
Stow it. It is a real shame that some admins can't see that there are
environments with needs dissimilar to their own. If I weren't allowed
to destroy runaway monster processes, or if I couldn't do anything
about individuals trying to break into these systems, or if I couldn't
cut off Usenet access to the (thus far purely hypothetical) news
abuser, I *would* quit. My bosses are very intelligent people and
don't restrict me in the areas where I have to be able to act.
-=-
Karlwoods@hao.ucar.edu (Greg Woods) (01/30/88)
In article <778@brandx.rutgers.edu> webber@brandx.rutgers.edu (Webber) writes: >If action X breaks the software, rather than fixing the software it is >alot easier to announce that all users are forbidden to do action X. If action X happens to be important to the purpose of the machine, then this is pretty bad system administration. On the other hand, if action X is "playing rogue", then a system administrator, who typically is responsible for lots of software subsystems, might be perfectly justified in saying that "X is broken and no one has time to fix it". If attempts to do X, due to the problems with X, interfere with other users trying to get work done, then again I think any competent system administrator should forbid users to do X. It's only "laziness" in the sense that the system administrator is not willing to work a 60-hour week. You could just as easily blame this kind of thing on management for not providing adequate support for their machines. But most sites that I am familiar with have enough systems administration staff for just a little more than the day-to-day activities, if that. Sometimes practicality says that the limited amount of time available to fix things is better spent on something other than X. --Greg
webber@brandx.rutgers.edu (Webber) (01/31/88)
In article <1133@hao.ucar.edu>, woods@hao.ucar.edu (Greg Woods) writes:
< ....
< If action X happens to be important to the purpose of the machine, then this
< is pretty bad system administration. On the other hand, if action X is
< "playing rogue", then a system administrator, who typically is responsible
< for lots of software subsystems, might be perfectly justified in saying
< that "X is broken and no one has time to fix it". If attempts to do X,
< due to the problems with X, interfere with other users trying to get work
< done, then again I think any competent system administrator should forbid
< users to do X. It's only "laziness" in the sense that the system administrator
< is not willing to work a 60-hour week. You could just as easily blame this
< kind of thing on management for not providing adequate support for their
< machines. ...
A 60 hour week is only 5 12 hour days. Pretty normal work hours from
all I have seen. Competent system administrators have tended to be more
like old-fashioned country doctors on 24-hour call than factory workers
waiting for the 5pm whistle. I can't imagine anyone thinking of rogue
as part of the software the system administrator maintains (except perhaps
as a hobby if they happen to play). However, if the playing of rogue were
crashing the system, then it would clearly be something worth careful
investigation. After all, rogue isn't an isolated kernel call, but instead
uses much the same calls as the rest of the system so if there was something
wrong with it there would be other problems too.
But, back to the main point, the fact that managements understaff computer
support and/or expect non-professional 40-hour workers to be able to
administer a system is no reason to further expect such people to be up
to managing users as well. While it is to be expected that such overburdened
or misclassified people will occasionally do things they shouldn't,
that doesn't make them right.
----- BOB (webber@athos.rutgers.edu ; rutgers!athos.rutgers.edu!webber)roy@phri.UUCP (Roy Smith) (02/01/88)
In article <784@brandx.rutgers.edu> webber@brandx.rutgers.edu (Webber) writes: > if the playing of rogue were crashing the system, then it would clearly > be something worth careful investigation. After all, rogue isn't an > isolated kernel call, but instead uses much the same calls as the rest of > the system so if there was something wrong with it there would be other > problems too. Interesting point. Depends on your point of view. If I were an SA using system software under a software support contract and my version of rogue caused a kernel crash, I would sure as hell expect the vendor to find the problem, taking exactly the argument outlined above. On the other hand, until the problem got fixed, you bet your bippies I'd outlaw rogue on the system. It's nice to argue how things should be, but people still gotta get their work done. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
henry@utzoo.uucp (Henry Spencer) (02/01/88)
> In a future release of the software add a check that each site when > receiving forwarded news check that the site prior in the path > matches the forwarder. There are two problems with this. First, it is not easy for the news software to determine which site news arrived from; newer versions of uucp do make some attempt to tell you, but old ones don't. Second, and much more fundamental, this thoroughly prevents forgery only if news security is airtight on *all* machines. Bearing in mind that would-be forgers may be on loosely-administered machines (tight security takes effort!), and that some of them may even be system administrators, there are just too many potential leaks in this scheme for it to be worth the trouble. Geoff and I looked at this in connection with moderated groups for C news, and rejected it. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
rwa@auvax.UUCP (Ross Alexander) (02/02/88)
In article <784@brandx.rutgers.edu>, webber@brandx.rutgers.edu (Webber) writes: > However, if the playing of rogue were > crashing the system, then it would clearly be something worth careful > investigation. The playing of rogue, at least around here during 12pm to 4pm, is considered antisocial. Rogue is a cycles-and-communications hog. I shoot rogue players on sight, and make no apologies for it. I also bump idle users and blow away runaway processes. What's the difference between a machine with a 20+ load average and a crashed machine? Precious little, if that machine is a VAX 780. Of course, rogue at 2000 hours is a different thing entirely. Ross Alexander, Sr Systems Programmer Athabasca University, Alberta alberta!auvax!rwa
mcb@tis.llnl.gov (Michael C. Berch) (02/03/88)
I've been paying attention to some of the proposals for "prevention" of
forgeries, ranging from instituting an authentication scheme to
punishing forgers and/or their systems, but even granted the
workability of any of these schemes (a doubtful question) I wonder
whether the forgery "problem" even warrants the significant
administrative and software development costs of attempting to prevent it.
With the exception of the annual April Fool's articles, forgery seems
to be limited to a few groups like alt.flame and some of the talk or
soc groups. Is there any reason to believe that more widespread
forgery will occur? If so, is there any reason to believe that this
represents a significant threat to the existence or functioning of Usenet?
Personally, I don't believe that either of these last two propositions
are proven, and therefore can't justify additional administrative or
software costs.
Michael C. Berch
News/mail admin - lll-tis and its clients
mcb@tis.llnl.gov / {ames,ihnp4,lll-crg,lll-lcc,mordor}!lll-tis!mcbwoods@hao.ucar.edu (Greg Woods) (02/03/88)
In article <21986@tis.llnl.gov> mcb@tis.llnl.gov (Michael C. Berch) writes: >With the exception of the annual April Fool's articles, forgery seems >to be limited to a few groups like alt.flame and some of the talk or >soc groups. Is there any reason to believe that more widespread >forgery will occur? Hard to say. For the most part, you are right, but since it is becoming more and more common knowledge that forgeries are possible, the problem is getting worse, culminating in the recent forged "newgroup" control message claiming to be from Gene Spafford. This is a lot more serious than forging your "opponent's" name to an article during a flame war in alt.flame . So far, we've only had one incident like this, but it's only a matter of time before there are more. If we don't do SOMETHING to prevent it, the net will degenerate into pure anarchy (Yes, I know it is technically an anarchy now, but most sites seem willing to follow the decisions of the backbone). I'm just not sure what the right thing to do is. Henry Spencer already pointed out some of the technical problems involved. --Greg
richard@gryphon.CTS.COM (Richard Sexton) (02/04/88)
In article <1141@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes: >In article <21986@tis.llnl.gov> mcb@tis.llnl.gov (Michael C. Berch) writes: >>With the exception of the annual April Fool's articles, forgery seems >>to be limited to a few groups like alt.flame and some of the talk or >>soc groups. Is there any reason to believe that more widespread >>forgery will occur? > >message claiming to be from Gene Spafford. This is a lot more serious >than forging your "opponent's" name to an article during a flame war >in alt.flame . So far, we've only had one incident like this, but it's >only a matter of time before there are more. If we don't do SOMETHING >to prevent it, the net will degenerate into pure anarchy Did I miss something here ? Is this a crisis ? A threat to national security ? The end of the world as we know it ? Whats the worst that could happen ? What is it with these damn question marks ? -- "I'm not going back to Woodstock for a while..." richard@gryphon.CTS.COM {ihnp4!scgvaxd!cadovax, philabs!cadovax, codas!ddsw1} gryphon!richard
learn@igloo.UUCP (william vajk) (02/05/88)
In article <21986@tis.llnl.gov>, mcb@tis.llnl.gov (Michael C. Berch) writes: > With the exception of the annual April Fool's articles, forgery seems > to be limited to a few groups like alt.flame and some of the talk or > soc groups. Insofar as I can determine, all this flap about pseudos and forged articles has to do with a single individual. If the balance of the information disseminated by this individual received as much attention, we would have a sad state of affairs. Also remember that this individual called for federal regulation of the net in a futile attempt to establish (for this individual) an impossible level of credibility. It is almost predictable that where one avenue has failed, another would be taken. This one individual does not make a general case sufficient to undertake the expense and problems associated with upgrading usenet software to preclude this specific possibility. The resources available are better spent in continuing upgrades to the software along the lines already begun. I, for one, am quite pleased with the features and successes achieved to date and wish to thank all those who have worked long and hard to create usenet. If the changes under discussion are realtively easy to invoke, I will support their inclusion. Under the present circumstances, however, I view the complaint(s) as a non-problem. Bill Vajk learn@igloo > therefor can't justify additional administrative or software costs. >
rwhite@nusdhub.UUCP (Robert C. White Jr.) (02/10/88)
Hi, If everybody really cares about authentication of messages, and message delivery, this is a _simple_ method of true user and path authentication. The major drawback of this scheme is an unknown level of system overhead. [Watch out, this is another idea off the top of my head.... you saw it here live folks!!!] The header is of the form: Authent: ### ### ### The information used is: 1) the four [or less] characters directly proceding the "@" in the message id. 2) the first four [or less] characters of the poster's login id. 3) the first four [or less] of the name of the originating system's name. 4) the first four [or less] characters of the second-to-left- most entry on the "Path:" line 5) the first four [or less] characters of the left-most entry on the "Path:" line 6) the first four [or less] characters of the current system's name, 7) several constants coded into the software. [These items have been selected because they would all be easily available to the software while it is running.] Item 1 is used to generate a two-column key. the even numbered columns forming one key and the odd forming the other. Becaues the key is basied on the accession number portion of the message id, no two messages from the same source user&machine will have the same key. The key thus generated is used as a base for a simple checksum process on the approprate entries [4 of the 2-6 group depending on opperation] producing a number not larger than 127, and a very basic checksum of the two results forms the third numger in the "Authent:" headder line. The constants mentioned in item 7 are the base multipliers and devisors and such. PROCESSING -- Message receipt & validation. Items 1 is used to generate the key. Items 2, 3, 4, and 5 from the inbound message are recovered from the article, and processed through the checksum routine. The results are compared against the contents of "Authent:". If the contents are invalid the "Authent:" is destroyed [probably ommited from the output of the article]. If the contents are validated, a new checksum based on items 2, 3, 5, and 6 is figured, and this number is written on the "Authent:" headder when the article is stored. There is no change in current batching/sending procedures as 2, 3, 5, and 6 on teh current system will be items 2, 3, 4, and 5 on teh destination system. PROCESSING -- Message creation. Durring message creation, all the above processing holds true but it is important that the receiving system will see an overlap of item pairs 2,4 and 3,5, so the processing preformed durring posting should reflect this. PROCESSSING -- Note: It is important that the system take care to understand that the items mentioned may overlap. [i.e. no assumptions about the "Path:" header bew made except the fact that it will contain at least two entries.] This will validate messages, and will make it a general pain for someone to forge entries. Forgery will still be possible, but only by editing the messages after generation and manually re-figuring the "Authent:" for it's aledged path. Exactly what should happen when a forgery [or bad "Authent:"] is received must be left to people with more practical experience on the net. Perhaps, at first, vnews can be set up to print: "Notice: NO AUTHENTICATION on Message" when it displays headers. Needless to say, there will have to be a hack-around until this [or any] authentication system is dern-near universal. An example of such a hack would be the addition of an extra number on teh end which states how many systems were on the Path: when the Authent: was last figured, and then using this as an offset for finding items 4 and 5 durring rnews processing. [and then re-figuring 5 and 6 to reflect current standings] Disclaimer: Then again, maby not........ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< << All the STREAM is but a page,<<|>> Robert C. White Jr. << << and we are merely layers, <<|>> nusdhub!rwhite nusdhub!usenet << << port owners and port payers, <<|>>>>>>>>"The Avitar of Chaos"<<<<<<<<<<<< << each an others audit fence, <<|>> Network tech, Gamer, Anti-christ, << << approaching the sum reel. <<|>> Voter, and General bad influence. << <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ## Disclaimer: You thought I was serious???...... Really???? ## ## Interogative: So... what _is_ your point? ## ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
jpederse@encad.UUCP (02/11/88)
In article <1129@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes:
[that is, in my opinion, abusing the system or doing something that may
^^^^^^^^^^^^^ your opinion must be worth quite a bit
[either damage the reputation of our organization or interfere with the ability
^^^^^^^^^^^^^^^^^^^^^^ You must also be the PR rep {official spokesman}
[of other users here to make use of the machine. Without this ability I cannot
[guarantee to do my job, which is to keep things running smoothly so that
^^^^^^^^^^^^^^^^^^^^^^^ sounds like subtle blackmail to me
[EVERYONE on the machine can get their work done in harmony. I do not want
[to "control" anyone beyond this. I don't want to keep news articles containing
So exactly how far can you go in legislating morallity on "your" machine?
Having been on both sides of the fence (sa on university vaxen and person who
deals with users from a service organization) I'm glad the power to pull the
plug on someone is often monitored by someone who can smooth feathers when
they get ruffled.
--
John Pedersen {hplabs!hp-sdd }
NCR Corporation {pyramid!bigbang }!ncr-sd!ncrwic!jpederse
Electromagical Engineering{seismo!esosun!ucsdhub }
j.pederse@wichita.NCR.COM {sdcsvax,cbatt,dcdwest,ihnp4}rees@apollo.uucp (Jim Rees) (02/18/88)
The information used is:
1) the four [or less] characters directly proceding the
"@" in the message id.
...
Item 1 is used to generate a two-column key. the even
numbered columns forming one key and the odd forming the other.
Becaues the key is basied on the accession number portion of
the message id, no two messages from the same source user&machine
will have the same key.
Not true. The usenet message interchange standard only says that the
entire message-id is unique. For some machines, like notes gateways
(never thought I'd be defending them!) and Apollos running distributed
news, the last four bytes preceeding the '@' are almost guaranteed to
be the same every time.
There are other holes in this scheme as well. It doesn't alter the
fundamental ease with which forgeries can be made, if I understand
it correctly.mouse@mcgill-vision.UUCP (der Mouse) (03/11/88)
In article <586@nusdhub.UUCP>, rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: > If everybody really cares about authentication of messages, and > message delivery, this is a _simple_ method of true user and path > authentication. The major drawback of this scheme is an unknown > level of system overhead. How about "it doesn't work" for a drawback? > [proposal for a scheme with an Authent: header based on several > things, including] > The information used is: > 1) the four [or less] characters directly proceding the > "@" in the message id. You appear to assume this is unique for a given machine. Sorry, but it isn't so. As far as I know, the Message-ID can be anything at all, as long as it is guaranteed not to duplicate any other Message-ID generated anywhere on the entire net (and contains only certain characters, such as the alphanumerics, dots, @ signs...). The convention is to use a trailing @hostname to ensure that the result doesn't conflict with an ID generated by any other machine (this convention clearly works only as long as everyone uses it). But the part before the @ is less standard. Here are some of the things I find in a quick glance through the Message-IDs in the first couple of pages of our history file: 8710070328.AA21589 The first part appears to be a date, the second looks like a sendmail queue-ID. (From Berkeley, ajpo.sei.cmu.edu, etc.) 1289 This looks like a sequence number. (From a great many places.) 1988Jan23.202318.22868 The first part is pretty obviously a date; the second part looks like a time, and the third part is mysterious. The process ID of the posting process maybe? (From U of T - is this C news default format maybe?) 167100020 I dunno. (Message-IDs appearing to conform to this pattern - a large integer - appear with uiucdcsb, clio, hpcupt1.HP.COM, silver, occrsh.ATT.COM, uokmet.UUCP, etc on the right of the @.) cVyQZ5y00XoFyDU0DT This looks like some binary value expressed in base 62 or something equally helpful. (From andrew.cmu.edu.) And when the last four characters are digits, which seems to be common, there are only 10000 possible values! > 2) through 6) are the first four [or less [sic]] characters of > various things. > 7) several constants coded into the software. I still don't see anything here that a forger couldn't simply compute based on the forgery as if it were a normal message. How does this help, except in that it makes it marginally more difficult to create a forged message? der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
wisner@eddie.MIT.EDU (Bill Wisner) (03/24/88)
der Mouse say: >8710070328.AA21589 > The first part appears to be a date, the second looks like a > sendmail queue-ID. (From Berkeley, ajpo.sei.cmu.edu, etc.) Standard sendmail-generated message ID. The ucbvax Internet-to-USENET gateway uses them. >1289 > This looks like a sequence number. (From a great many places.) Yup. Vanilla B newsism. >1988Jan23.202318.22868 > The first part is pretty obviously a date; the second part > looks like a time, and the third part is mysterious. The > process ID of the posting process maybe? Probably. Using PID like that isn't really a safe way to generate unique message IDs; I've known some systems to be active enough that they cycle through the entire thirty-thousand process limit in a day. >167100020 > I dunno. (Message-IDs appearing to conform to this pattern - a > large integer - appear with uiucdcsb, clio, hpcupt1.HP.COM, > silver, occrsh.ATT.COM, uokmet.UUCP, etc on the right of the @.) Isn't it awful? That's a notesfiles message ID. Usually, there is no domain after the sitename, either. ..b