[AG-TECH] AG Security

[S.Booth]

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|
======================================================================