brian@ucsd.Edu (Brian Kantor) (08/07/90)
In article <2023@trlluna.trl.oz> summer@shiva.trl.oz (Mark Summerfield) writes: >In article <16779@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: >|In article <2009@trlluna.trl.oz> summer@shiva.trl.oz (Mark Summerfield) writes >|>Can anybody think of a compatible way of authenticating the initial entry >|>in USENET of an article? >|If it comes in from NNTP, sure. Just install the current version and >|enable the authentication code. >Could somebody explain what this is, and how it works please? Ok, since I designed and wrote it, I'll explain it. In nntp-1.5.9 and later (.10 is in alpha test now) you can enable a weak authentication system. The nntp posting client's mini-inews has suid access to a file which contains a password for posting. It has to supply this password in cleartext across the network for a posting to be accepted by the authenticating nntp server. The mini-inews inserts user identification information in the article's headers, so the initial entry of the article into the network contains user identification that was correct as of that time, assuming no compromise of the sending system. Thus connecting to the nntp port with telnet won't let you submit a faked article directly. This scheme is compromisable in several ways; a client must be considered insecure if the user has access to the system console, so it's not very useful for workstations - the user can simply bring the system up as root and go look at the file, or su to whoever does have access to the file and peek that way. In an environment such as ours, where we have many multiuser systems that use NNTP to submit articles, it's good enough. The consoles are in a secure area, so users can't get to them and presumably can't become root to peek at the file. What we were trying to stop was people telnetting into the server's nntp port. This same scheme can be used to authenticate newsfeeds from neighboring sites. This means that feeds from systems that have users on them are protected from the users on those systems. NNTP has always allowed you to protect the server from other hosts. In environments where the workstations or the network itself are NOT secure, this scheme is inadequate. There are hooks in the NNTP enhancement that allow for many different kinds of authentication schemes to be used, including Kerberos, which I feel would be excellent for this application. We did consider the use of public-key stuff in a manner similar to the proposed privacy-enhanced mail, but the cost of doing it put us off. Even at a theoretical license charge of just $1 per user per year, we'd be spending enough money on license fees to finance a graduate student to research an alternative. So what's available now is adequate for some environments. If you have some way to securely protect the password, it's adequate for many. If you can protect the password and exchange it in an encrypted manner, it's much more secure than any of the rest of Usenet is, and that's probably good enough. BTW, in case you were going to ask: the RFC for the NNTP enhancements is being edited on my workstation in that window just over there ---------------> so maybe I'll get it out in the next week or four. As a note, something I tried as an experiment works, if you have the spare cpu cycles to spend on it. You and each of your UUCP newsfeed neighbors can agree on a mutual encryption key, and simply ship the rnews batches over encrypted. Since rnews itself would become a shell script that unconditionally feeds the incoming batches through crypt before passing them to inews, plaintext files coming from someone spoofing your uucp neighbor or running rnews directly on your system would wind up feeding inews gales of garbage that it would simply discard. Make rnews and postnews sgid to 'news' and restrict access to inews to people in group news, and you've probably closed most of the common holes for faking news articles. - Brian