[AG-TECH] AG Security

[Ivan R. Judson]

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

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax