Slashdot Mirror
Using IRC for Electronic Meetings?
paenguin asks: "Our Linux User Group sometimes needs to hold Exec meetings, electronically. We have used IRC in the past, but it leaves us with a problem: there is no easy or built-in way to prove who is who. Do Slashdot readers know of a way to provide non-repudiation over IRC, or of another open source method of holding group electronic meetings where we can verify that everyone is who they say they are?" Wouldn't a private IRC server, with a combination of suitable IRC services (ala NickServ and ChanServe) and fairly restrictive policies, be one solution to this problem? How would you set up such a system? For those willing to brave the setup hassles, might some form of secure IRC also be an option?
I'm sorry I don't know much about the server end, I figure lots of other people can answer that question. I just know how I'd go about it once the server is up and running.
I was quite active on Austnet. They had NickOp which was used for registerring a nickname and for
logging in. They had Chanop which was for maintaining channels etc. They had noteop for sending messages. So, to answer your question, I'd either use Austnet, or build a private IRC server with similar funcationality. Then, create a channel via chanop, and set access to every registerred person so that Chanop ops them. Why do this? Well, you have 120 seconds to enter your password when you use a registerred nick. Chanop will not op you until you are logged in. So if somebody comes on using a nick they shouldn't, they won't be opped. When they have the @ next to their name, they've logged in, and you know who you're talking to.
"Derp de derp."
I'm considering proposing an IRC network across our group for real-time multi-person chatting -- rather than Messenger or ICQ. There are so many nice things about the very mature IRC system that gets drowned out by all the pre-teens on public IRC networks, it's worth exploring.
Yes, to elaborate further in the comment in the story, the best way to establish this kind of 'identity' scheme is to make use of a set of services. Andy Church makes a very good IRC Services package which is available at http://www.ircservices.za.net which is more than capable for performing the task at hand.
You'll need an IRC daemon which is also able to be tightly integrated with services, and for that task, I recommend using Bahamut (available at http://bahamut.dal.net. As the URL implies, it's the same IRCd that DALnet uses. In particular, you're looking for a channel mode which restricts channel access to registered clients only. In Bahamut, this is the +R channel mode (which is different from +r.)
Services has a channel option known as 'RESTRICTED' which will only allow people who are on that channel's access list into the channel. Everyone else will be kicked and banned automatically by services. Thus, you can have reasonable assurance that everyone who's in the channel has A) identified to their registered nick with services, and B) is supposed to be in the channel, since they're on that channel's access list. Furthermore, the status of someone's identity can be checked by doing '/MSG NickServ STATUS ', where is the nickname you want to know the status of. NickServ will then tell you if the nickname is identified to properly (i.e. via a password.)
Some of the more advanced IRC options include replacing the ancient 'ident' system with something more modern. On IRC, anyone who isn't 'identified' has a tilde (~) prefixed to their username. However, since almost anyone can put anything in the ident reply these days, this has become practically useless (it used to be that you could tell, with reasonable assurance, what user was coming from what Unix box with ident -- not so anymore.) Instead, it's possible to setup an authorization scheme that makes use of IRC's 'PASS' command to also 'identify' to a unique username.
My Synchronet IRCd (http://www.synchro.net/docs/ircd.txt) makes use of this scheme by letting users be 'identified' whenever they provide the correct password and username that corresponds to the local BBS account (Synchronet is a very nice piece of BBS software for Linux/Win32/BSD/etc.) That way, a user coming online from a certain BBS without a tilde in their username is an indicator that they've identified correctly to their local BBS account. That's just one of the ways ident can be replaced to provide something more useful.
Jabber also supports SSL and is extensible (so can support things like group-conference room logging).
Power corrupts. PowerPoint corrupts absolutely. E. Tufte
Pretty Pictures!
Or you could use SILC which is an encrypted/authenicated chat network. Every client has to generate a public/private keypair, so you could get/post public key fingerprints in the workplace/wherever, then simply authenicate each user who comes into the channel, or password protect the channel.
My email addy? should be easy enough.
Lily is a CMC (computer mediated communications) server that supports user authentication and discussion history. Lily is mature; the oldest lily server has been in constant service (with only occasional brief downtime for upgrades) for over ten years.
Yeah, SSL-enabled IRCds are available, including UnrealIRCd (www.unrealircd.com). Haven't tried to use the SSL myself, but it's a good IRCd with a nice set of features and good Services integration. I think you can even have SSL server links as well as client connections. The network I frequent uses Anope (www.anope.org) IRC Services, which include the password-based nick registration system mentioned above.
Sorry, my karma just ran over your dogma.
More importantly, Jabber supports GPG-signed and -encrypted instant messaging. That system in a Jabber converence room should solve the original problem perfectly.
Of course, then we started writing bots to emulate our presence on the channel when we were gone ("How's the new release looking?") and the company went bankrupt, but that's beside the point. :P
Al Qaeda has ninjas!