[AG-TECH] AG security and multicast ?

[Ivan R. Judson]

The beauty of Adam's suggestion is that it's exactly what the AG team has
been trying to get enough time to build. This is the kind of work we'd like
to see -- but I don't believe the NCSA scheduler has been released yet for
others to hack on it. The work I believe is a small amount using the
existing interfaces that are available.

If this can't be done in short order, I support Brian's point that for most
users a passcode/password -- similar to what is used by conference calls or
web meeting software, should be sufficient _to gain access_ to the venue (to
get past the bouncer), but it's really of *no* use if the communication
within the venue isn't secure -- then as Jennifer points out, you're only
relying on obscurity.

Who wants to hack on the scheduling software (either NCSA's or a new one)?
That's where the interesting "automation" is. It won't solve all the ad-hoc
stuff, but it'd go a long way towards solving a lot of the mundane
problems...

--Ivan

> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov 
> [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Adam Taylor
> Sent: Monday, April 11, 2005 11:01 AM
> To: ag-tech at mcs.anl.gov
> Subject: RE: [AG-TECH] AG security and multicast ?
> 
> My two cents...
> 
> To bad there wasn't a way that when you go to confirm you 
> reservation in the AG Scheduler you must enter the DN of the 
> site you will be at to confirm your reservation.  Then, 5 min 
> or so before the meeting starts, a background process 
> (something that can talk to the venue server and scheduler) 
> reads in the DNs from the scheduler for that room and time 
> and sets the ACL for that room for that given scheduled time 
> block.  When that meeting is over, the background process 
> removes that ACL for that room and creates another one for 
> the next meeting in that room.  If there is more then 30 min 
> or so between meetings then the background process just 
> removes the ACL for that period of time.  Just make sure all 
> rooms are encrypted (different key per meeting or something 
> like that) and that should make it pretty secure.
> 
> At least in my head it does :-)
> 
> Adam Taylor
> Computing Center
> University of Louisiana at Monroe
> 
> 
> -----Original Message-----
> From: owner-ag-tech at mcs.anl.gov 
> [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Jennifer Teig 
> von Hoffman
> Sent: Monday, April 11, 2005 10:28 AM
> To: ag-tech
> Subject: Re: [AG-TECH] AG security and multicast ?
> 
> It does seem to me that the current steps for making a 
> meeting secure are clunky from the point of view of an 
> end-user with average technical skills. If I understand 
> correctly, they have to:
> 
> 1) find out the DNs for each of the meeting participants (who 
> may not themselves know how to do this, so they may need to 
> send instructions. 
> also, they may be using a room-based node, and therefore have 
> to get yet another party involved)
> 
> 2) have the administrative permissions on the server where 
> their meeting will be held, to be able to create an ACL for a 
> given room
> 
> 3) know how to use the GUI server adminstrator tool, which is 
> not necessarily intuitive for an end-user with average 
> computer literacy
> 
> (I may be wrong -- if I am, somebody please correct me!!)
> 
> Seems to me that usually steps 2 and 3 are usually being done 
> not by the person who scheduled the meeting, but by the 
> server's main adminstrator. 
> And my hunch is that step 1 is often being done by the server 
> admin as well.
> 
> My hunch is that very few meetings are using ACLs. Anybody 
> got stats on that?
> 
> I don't have an alternate to propose, but would happily 
> participate in brainstorming on making this more 
> user-friendly if the developers are interested in that kind 
> of input/feedback.
> 
> Cheers,
> Jennifer
> 
> 
> Gavin W. Burris aka 86 wrote:
> > I think allowing anyone into a secure meeting until you "lock the 
> > door" is a poor security model.  No need to lock the door and be 
> > worried about who you have already let in, because it is really not 
> > that user unfriendly to have an attendee list and add them 
> to a secure 
> > room with the GUI server administration tool.  If you don't do 
> > security properly, it is just another hoop someone has to 
> jump through 
> > to get what you don't want them to have.
> > 
> > Derek Piper wrote (on Mon, 11 Apr 2005 at 08:28):
> > 
> >>	Something I've been asked about that's security related is about
> having 
> >>the ability to 'lock' a room from within the venue client, akin to 
> >>having a closed and locked door for a real conference room. 
> Then, if 
> >>the room were set up to encrypt the traffic and people 
> couldn't just 
> >>'jump-in' it might make private meetings more attractive to 
> those that 
> >>have a need for it. Sure you can set up a room with 
> allowing certain 
> >>certificates, but that's cumbersome to have to do on a per-meeting 
> >>basis if all you want is something like a bunch of 
> 'conference rooms'. 
> >>Having to have an operator tailor a room to a particular 
> meeting isn't 
> >>a very user-friendly way of doing it.
> >>	I asked a while ago on the list of a good way to do 
> that and the 
> >>response was it'd be something I'd have to do myself. If 
> enough people 
> >>think it's a feature they want, maybe we can convince the 
> AG software 
> >>writers/maintainers to add functionality?
> >>
> >>	Derek
> >>
> >>
> >>Gavin W. Burris aka 86 wrote:
> >>
> >>>Here are two good resources:
> >>>http://multicasttech.com/
> >>>http://multicast.internet2.edu/
> >>>
> >>>I get asked about security more and more now.  People are 
> concerned 
> >>>that their research will be broadcast to anyone with a 
> >>>multicast-enabled network.  VIC and RAT do offer 
> encryption keys, and 
> >>>that is an option to enable with AGTk venue servers.  
> Rooms can have 
> >>>access based on your globus certificates, too.  And AGTK 
> uses SSL for 
> >>>its client/server connections.
> >>>
> >>>
> >>>Would it be feasible to route multicast though a VPN for 
> very secure 
> >>>meetings?  Say, run a VPN server on the same machine that 
> the venue 
> >>>server is on, have clients connect their VPN client to it, 
> and then 
> >>>fire up AG over the encrypted tunnel?
> >>>
> >>>
> >>>
> >>>Dioselin Gonzalez wrote (on Wed, 6 Apr 2005 at 09:05):
> >>>
> >>>
> >>>>Hello everybody,
> >>>>
> >>>>As part of our distance learning project, we need 
> in-depth technical 
> >>>>information about security mechanisms and multicast allocation in 
> >>>>the AG.  Are there any documents or papers about this?
> >>>>
> >>>>The team will be doing low-level implementation, so we need  
> >>>>hard-core documentation for techies :o)
> >>>>
> >>>>Thanks,
> >>>>
> >>>>Dio.-
> >>>>
> >>>
> >>>
> >>--
> >>Derek Piper - dcpiper at indiana.edu - (812) 856 0111 IRI 323, 
> School of 
> >>Informatics Indiana University, Bloomington, Indiana
> > 
> > 
> 
> 
>