[AG-TECH] VV Spatial metaphor (was AG Security)

[Shawn Davis]

In a general sense, the AG is a utility to hold video conference meetings 
with multiple locations.
I'm a little bit lost on what the idea of spatial idea really does to 
benefit the experience of the AG.  I may be missing something critical here 
simply because I've only been involved with the AG for the past year and 
half, and may be missing out on some of the key goals that were set forth 
when the AG idea was created.  But here's how I see it:

As it stands right now, I see the process of navigating through the lobby 
to the appropriate venue to be nothing more than that - a process.  I'm not 
strolling through the AG virtual world, I'm going to a virtual venue, a 
destination, for the sole purpose of attending a meeting.  What if I could 
bypass the navigation and simply go straight to my destination?  This is 
the capability I have provided within AGSchedule.  Because the ultimate 
goal of an AG meeting is to get everyone communicating on the same set of 
multicast IP addresses, I've created a way to bypass the navigation and go 
straight to your destination.  A time-saving feature, as I see it.  Plus, 
you don't necessarily need to know where exactly your destination is - you 
just go there.  After all, what does it matter?  When you get there, it all 
looks the same.  Everything works the same way.  Your audience/participants 
aren't affected in the slightest bit by where in this virtual world the 
meeting is taking place.

Even if the spatial metaphor for virtual venues is further developed into 
something that is more apparent, how does this help the ability to 
communicate effectively on the AG?
-Shawn

At 12:30 PM 7/19/2002 -0500, Ivan R. Judson wrote:

>I like this conversation, but am afraid in both cases (Stephen's example
>and Sean's scheduler) the spatial metaphor is lost.  Spatial information
>(more deeply than the UI metaphor) is integral to the concept of the
>venues and the AG as a whole.
>
>The scheduler is a tool to make "formal reservation and preparation" of
>a virtual space easier.  The goal in the end is what can you do
>to,in,on,around the space.  The space is implicitly defining the
>meta-information about multicast groups, users, presence, services, etc.
>Perhaps if we define what the venue is supposed to be (ie, what data it
>holds, services it provides, etc) that would be a good first step in the
>process of understanding the appropriate place for various aspects of
>security to live in the AG.
>
>This would be a cool place to insert some idea (or requirement) like:
>
>- The Venue should not be responsible for stream encryption key
>generation and distribution, or
>- The Venue should be capable of stream encryption key generation, but
>allow participants to use other mechanisms to generate and use
>encryption keys for stream encryption
>
>There are many other variants, but something concrete like a set of
>sentences that represent what people desire might make it easier to
>filter through the real issues and find a good clear path out of this.
>
>Thoughts?
>
>--Ivan
>
>..........
>Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
>Futures Laboratory .~.  630 252 0920
>Argonne National Laboratory .~. 630 252 6424 Fax
>
>
> > -----Original Message-----
> > From: owner-ag-tech at mcs.anl.gov
> > [mailto:owner-ag-tech at mcs.anl.gov] On Behalf Of Deb Agarwal
> > Sent: Friday, July 19, 2002 12:18 PM
> > To: s.booth at epcc.ed.ac.uk
> > Cc: ag-tech at mcs.anl.gov
> > Subject: Re: [AG-TECH] AG Security
> >
> >
> > Stephen,
> >
> > Just my 2 cents worth on the topic.
> >
> > We do not have an implementation ready to distribute yet, but
> > we are working on distributed key agreement that will work as
> > you say. The venues server can act as the authorization
> > server and then the participants do distributed key agreement
> > using our protocol.  This way the venues server only (or
> > whatever you want to use for authorization) only needs to
> > know public keys that are authorized at most and normally
> > only knows distinguished names and a trusted CA.  If you want
> > to look at our work so far, the pointer is
> > www-itg.lbl.gov/CIF/GroupComm.
> >
> > Deb
> >
> > S.Booth wrote:
> > > On Fri, 19 Jul 2002, Ivan R. Judson wrote:
> > >
> > >
> > >>Hey Stephen,
> > >>
> > >>I'm not sure I follow your argument below:
> > >>
> > >>
> > >>>This implies that the encryption key is generated by the
> > >>>venues server and we therefore have to trust the venues
> > >>>server (not that we don't trust you but its the principle of
> > >>>the thing) An alternative model would be that the meeting
> > >>>organiser generated a token for each expected participant
> > >>>containing the encryption key and the time of the meeting.
> > >>>The token is public key encrypted. These can then be stored
> > >>>on the venues server, sent by email, stored on a public
> > >>>website whatever.
> > >>
> > >>I think having an automated mechanism for doing key distribution is
> > >>the goal, whether that's done via the venues server (which
> > makes sense
> > >>in the ivory tower model), or other means is definitely open to
> > >>discussion.
> > >>
> > >>
> > >>My personal model for this moving into the future is that a
> > venue is
> > >>something somebody or some group owns.  That means that person or
> > >>group can alter "permissions" on the venue, ie, who's allowed to
> > >>enter/exit, modify the venue, introduce new applicaions, services,
> > >>etc.  This requires identification and authorization.
> > >>
> > >>Currently, we haven't integrated the notion of users into the AG
> > >>completely.  If we did there might be a richer set of data
> > to use for
> > >>exploring different identity and authorization mechanisms.
> > >>
> > >>Getting back to your point, I think it makes infinitely
> > more sense to
> > >>say,
> > >>
> > >>The participants for this private meeting are:
> > >>
> > >>Ivan
> > >>Stephen
> > >>Bob
> > >>Jennifer
> > >>
> > >>And have some mechanism in place to "lock" other
> > participants out of a
> > >>venue, in addition to "throwing them out" of a venue they
> > don't belong
> > >>in.  In addition, I think the metaphor is "private meeting" not
> > >>"encrypting streams", the mechanisms for making a meeting private
> > >>include encrypting streams, but also allocating different multicast
> > >>addresses for each meeting, or perhaps other more creative things.
> > >>
> > >>Does that make sense?
> > >>
> > >>--Ivan
> > >>
> > >>PS -- I don't find the ACL to be the problem in the current
> > model, I
> > >>find the problem is Bob is the only one who can edit it to
> > be the real
> > >>problem :-).  That being said, we've just institued a
> > policy whereby
> > >>bob no longer can have vacation since he's so critical to this
> > >>part...NOT
> > >>
> > >
> > >
> > >
> > > I think you are entirely right about the model for the user
> > interface
> > > model. You integrate with a booking system and select participants
> > > from the database. The nsca scheduler already does this. I'm more
> > > concerned with how you would implement this interface in a secure
> > > fashion. OK the probability of someone trying to break AG
> > is low but
> > > cryptography is fun.
> > >
> > > Imagine you modify the ncsa scheduler to optionally supply
> > a randomly
> > > generated session key to booked sessions. Lets think how you would
> > > break this system. Assuming we don't have the compute power
> > to brute
> > > force the session key the next obvious step is to try to
> > hack into a
> > > system that has the key. Obviously any one of the meeting
> > participants
> > > would do, but if the key was originally generated by the scheduler
> > > this becomes the most attractive target to attack as you
> > could subvert
> > > the code that generated the key and gain access to ALL private
> > > sessions. On the other hand if the scheduler only holds a
> > database of
> > > public-keys for AG users and public-key encrypted session keys are
> > > generated on the home machine of the person making the booking then
> > > uploaded to the scheduler the user interface looks the same but the
> > > security risk is much less.
> > >
> > > Of course this is probably overkill for most AG users.
> > Maybe we should
> > > just lobby for a single dialog box on the event server to make it
> > > easier to set the session key by hand, then tell people to exchange
> > > keys by secure email. If you are not paranoid you probably
> > don't care
> > > about encryption. If you are then you won't trust an
> > automated system
> > > anyway :-)
> > >
> > >
> > >
> > >                             Stephen
> > >
> > ======================================================================
> > > |epcc| Dr Stephen P Booth             Project Manager
> >     |epcc|
> > > |epcc| s.booth at epcc.ed.ac.uk          Phone 0131 650 5746
> >     |epcc|
> > >
> > ======================================================================
> > >
> > >
> > >
> > >
> >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ~~~~~~~~~
> > Deb Agarwal                          e-mail:DAAgarwal at lbl.gov
> > MS50B-2239                           phone :(510)486-7078
> > Lawrence Berkeley National Lab       URL: http://www-itg.lbl.gov/~deba
> > Berkeley, CA 94720
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > ~~~~~~~~~
> >