SNEWS Security plans


Subject: SNEWS Security plans
From: Alec Habig (habig@budoe2.bu.edu)
Date: Tue Nov 23 1999 - 10:55:52 EST


Hi SNEWSers,

As requested at the videocon, here's a short summary of my plans to
improve the security of SNEWS. (apologies for the delay, I got sucked
onto an airplane immediately after the meeting).

Comments, suggestions, etc. welcome and appreciated!

The two security things I'll implement for SNEWS in Dec. after the SK
meeting:

1) Establish a PGP key with which the server can sign alert messages.
   Get this key propagated onto the world's key servers, so Joe Random
   Astronomer can quickly verify that an email alert is from us and not
   a spoof.

Hurdles -

  a) getting this set up to be done in an automated way. By default,
     message signing is done interactively to ensure that the message is
     really coming from you. If it can be done in a batch fashion, then
     anyone who can run the batch gets to generate signed messages. We
     just have to live with this security hole, since automation is our
     whole reason for existing.

  b) Doing this as universally as possible. Gnu Privacy Guard
     (http://www.gnupg.org) looks like our best bet. Being open-source,
     it can easily be updated to deal with new developments (such as
     interoperability with commercial signing programs), and is free for
     whomever might want to set up the software to check out keys.

2) Change over the SNEWS server to use the Secure Socket Layer
   (http://www.openssl.org/). This would allow the client/server
   connections to operate in much the same fashion as the "ssh" program
   does for interactive logins - each experiment has a public/private
   key pair, encrypts their alert packet with their private key and the
   server's public key, and the server decrypts with its private key and
   the client's public key. This ensures that the server knows from
   whom it is getting alerts with pretty good confidence.

Hurdles -

  a) Getting our SNEWS code altered to deal with this - this is my job.

  b) Getting the libaries compiled on each experiment's machine so they
     can link their client with it - this could be the more difficult
     part, esp. for non-unix machines.

Alec

-- 
       Alec Habig, Boston University Particle Astrophysics Group
			   habig@budoe.bu.edu
		       http://hep.bu.edu/~habig/



This archive was generated by hypermail 2a24 : Tue Nov 23 1999 - 10:56:35 EST