[AG-TECH] AG security and multicast ?

[Brian Corrie]

Hi All,

Just a comment that I have based on what our users have said. This is in 
comparison to VRVS, which many of our users utilize. The ability to be 
able to set an access password on a venue would be a good thing. This is 
fairly weak security, but would meet many user's needs.

The VRVS model is to set up a meeting, have the meeting organizer set 
the password, email/phone the password to particpants, and away you 
go... If that was done on an encrypted room, it may gives a lot of the 
required functionality without some of the overheads. From a security 
standpoint, not terribly strong perhaps, but...

Just some thoughts...

Brian



Jennifer Teig von Hoffman wrote:
> 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
>>
>>
>>