[AG-TECH] AG Security

[Markus Buchhorn]

[Kevin, cc'ed for any comments you might have, presuming you're not on the ag-tech list?]

I quite like Jay's comments on the spatial metaphor for venues, and Ivan's query on what a venue should or should not provide. Having a spatial metaphor to get into a venue probably isn't important (as Shawn noted), but once you are in it, the venue should feel like a "room", I think. It's an identity thing.

Given that the fundamental component of a venue *today* is its IP address-set, we'd need to decide if we want to break that linkage. <shrug>.

It's the multicast design though that needs addressing to potentially support (some of?) the security requirements, unless you only want it at the application layer. Multicast to-date has not offered any security, leaving that to the application layer. AFAICS, you can't stop people joining a multicast group, nor kick them off, in any sensible, scalable fashion. That means that Joe Evil can read your encrypted streams in peace and quiet, record them and run a crack over them at his leisure.

This also impacts bandwidth issues - there is no way to stop a user on a narrow bandwidth link from joining a high-bandwidth multicast group. That impacts every multicast-enabled link between the source and the receiver. 

I don't think the comment "cracking AG's isn't interesting" applies once you run serious meetings over it - and people do/will. For example, if I want to get our BioInformatics people to discuss their projects over the AG, they will want security - their work has $$$ potential.

The IRTF Secure Multicast (SMUG) and IETF Multicast Security (MSEC) groups have been looking into some of these areas (anybody from those groups on this list?). The charter for msec at http://www.ietf.org/html.charters/msec-charter.html includes the following building blocks (BB's):

--------
(BB1) Data security transforms functional building block. This building block provide for group and source authentication and group secrecy, assuming that the parties hold the necessary cryptographic keys. This BB will support both IP-layer and transport/application layer security services. 

(BB2) Group key management and group security association (GSA) functional building block. This building block makes sure that the group members have the cryptographic keys needed for BB1. This includes secure generation, distribution, and update of the cryptographic keys. 

(BB3) Group policy management functional building block. This building block provides means for determination and disemination of group security policy, that governs the behavior of BB1 and BB2. (It is stressed that MSEC will not address general policy management issues, and will concentrate on mechanisms required for BB1 and BB2.) 
---------

There's nothing here though that addresses the "anybody can join" problem, even though they state (first bullet):

--------
The developed standard will assume that each group has a single trusted entity (the Group Controller) that sets the security policy and controls the group membership. The standard will strive to provide at least the following basic security guarantees: 
+ Only legitimate group members will have access to current group communication. This includes groups with highly dynamic membership. 
+ Legitimate group members will be able to authenticate the source and contents of the group communication. This includes cases where group members do not trust each other. 
---------

I think they've patched over the routing issue, and are focussing on the application layer security.

There is an initial focus on one-to-(very)many sessions, which is not an AG-like setup, but the principles should be relevant. I haven't read the drafts yet (no rfc's) but they look interesting - one is a Group Key Management Architecture (gkmarch). 

There's also the secure-RTP (SRTP) work (http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-05.txt) which also seems relevant, I think. That's a lower layer approach than encrypting just the content and handing round keys. MIKey (from msec) I think proposes a way to hook GKMARCH into SRTP.

I would suggest we need to track this work (and ultimately interoperate?), if we aren't already? I haven't seen it mentioned though.

I haven't found anything yet that discusses multicast routing/group-membership security. It may need to be a hook at the very lowest (IGMP) layer into the higher layers (like gkmarch) - but then it needs to talk to the routing layers in between (PIM, MSDP, MBGP, <ugh>...)

Cheers,
	Markus

Markus Buchhorn, ANU Internet Futures Project,        | Ph: +61 2 61258810
Markus.Buchhorn at anu.edu.au, mail: Bldg #108 - CS&IT   |Fax: +61 2 61259805
Australian National University, Canberra 0200, Aust.  |Mobile: 0417 281429