In [kirst2], we stated that we would do the following:

• Set up a testbed with two links between UCL and the CAIRN; one will be the current CAIRN link, the other via ULCC/UUNET that runs only native IPv6. On the UCL side, LEARNET will be connected in. We then investigate mechanism for QoS with two high-bandwidth islands connected by a pair of lower-speed connections - with full QoS in place on the links.
• Provide full implementation of the Session Initiation Protocol (SIP) - including its security extensions. This will require some re-work of the media tools, to allow use of an underlying IPSEC infrastructure. Most of the current IPSEC implementations do not support addressing of multicast groups; this deficiency will have to be addressed. We will incorporate also those encryption algorithms that are recommended in the IETF community.
• Deploy a security infrastructure, so that group key pairs, or even the whole Session Descriptions, are stored in a Secure Web store with access controlled by group membership; in addition, Certificates containing the Public Keys of any potential participants will be kept in Secure DNS servers. Such a mechanism will be more in tune with the security deployment. In the original proposal, the group key pairs were kept in a secure DNS; holding confidential information in a Secure DNS is now contrary to the declared policy on DNSs.
• Provide secure multicast WEBCAST facilities to provide authenticated and encrypted pre-distribution of presentation material. This work requires the originator to set up security associations, to ensure that the appropriate privileges should be granted. Here we expect to use the normal ISAKMP/Oakley exchanges.
• Provide access control and confidentiality on the UCL media-on-demand server, to add stored material into conferences. This will require both the use of IPSEC with multicast, and the incorporation of the normal ISAKMP/Oakley exchanges to authorise the storage.
• Ensure the UCL Universal Transcoding Gateway can process encrypted media streams in a trusted gateway - using standard Internet security procedures. We believe this will require an IPSEC transcoding stage in the Relay. The control of such stages will require the use of IPSEC with multicast, and the incorporation of the normal ISAKMP/Oakley exchanges to authorise the control of the Relay and the decryption/re-encryption stage in the Relay. This gateway will also be used for connecting in mobile and other devices.
• Investigate the use of RTSP and/or SIP, with appropriate security extensions, to control the media server and gateway described above.
• Deploy secure conferencing over CAIRN with full security infrastructure, all the above features, and both SIP and SAP. This will use as much as possible of the normal IPSEC based security; application-level security will be used only when we can think of no way of performing the functions at a network level.
• Investigate the functionality required to provide a Secured Virtual Private Network between the members of the ICB. This will include working through how to deal with the differing security policies of the ICB-member networks. While UCL will be one of the parties to this Coalition System, an important role will to act as a facilitator to the other partners - in the provision of secured applications, infrastructure, and practical assistance. Our participation in the above-mentioned CAIRN will ensure that this will provide an additional collaborator in the VPN.

While we have largely followed the plan envisaged, there have been some deviations. The deviations have occurred because facilities expected were not available, the work intended no longer made sense, or because we thought it preferable to do some of the work items in a different order because of some external events..

Any of the applications that required IPSEC have been delayed. We now have IPSEC for Solaris, Microsoft Windows, NetBSD and FreeBSD; the latter two come from the KAME [kame] releases. Most of these have only become available during the last quarter, and some still have not been delivered with encryption. Moreover, the current implementations require privileged access to the IPSEC stack to enter any keying material; this is impractical from our user applications. We are resolving how to do it before we use any IPSEC in the tools or servers in anger. This has delayed this aspect of activities to year 2.

There have been some problems with the QoS work on two channels, because we only have one available. The reasons for this, and our activities, are discussed in Section 2. The work with secured conference tools has continued well; it is largely completed without IPSEC, and is considered in Section 3. The work on secured SIP, multicast WEBCAST, servers and UTG is on-track; the work during this year has been mainly to complete the non-secured versions in a form suitable both for IPv6 and security; it is considered in Section 4. The VPN work is proceeding albeit slowly; it is discussed in Section 5. Use of Resources is considered in Section 6.

We have provided a web-based system for the storage and access of information in a way that can be secure. Currently, the system can is used to store and access session details for multicast conferences. Users can join the sessions easily via their web browser (using our SPAR Java applet to start the media tools in secure mode). While we have designed the system to allow participation in secured conferences, its use is not restricted to this case.

The web server uses HTTP-S for the transport, so the browser-server dialogue is encrypted over the network. Currently, this uses a UCL self-signed certificate. Since this is "unknown" to browsers, it is untrusted so needs to be accepted by the user initially. The URL is https://www-secure.cs.ucl.ac.uk/ and the main page frame has clickable options (e.g. to register, manage groups, show sessions etc.) Users first need to register on the server by creating a user-profile. Currently this is a simple form to provide name/organisation/e-mail-key details and set a user-id and password for future authentication and access to the server. Currently, no authentication checks are made on who can register, and only basic checks are made on the user data supplied. Browser-supplied user certificates can also be used as

an alternative to usernames/passwords to access the store. Currently, the server will accept user certificates signed by the UCL Trustfactory, or Verisign Class0 certificates

Registered users can create/manage "groups" and assign members (other registered users) who may access them. A group manager can also create secure conference sessions by submitting a form giving the details (title/media used/expiry time/scope etc.)

Registered users can also access "pages" for the groups to which they belong, and retrieve the information in the list of sessions and join active conferences. Such conferences can be joined in several ways:

• manually - the user needs to start the conference media tools on their host with the addressing/attribute details shown
• automatically by using a small platform specific "helper" program and MIME-type (which needs special configuration on the browser). This method is obsolete but can be used if a Java-capable browser is not available.
• automaticaly using the SPAR Java Applet - which is platform independent and needs no browser configuration. This is the preferred/recommended way but currently only Netscape's Communicator and Microsoft's Internet Explorer 4/5 are supported.

Note: for creating and joining sessions defined on the server, PGP keys are not needed or used..

Simplistically, the Java applet parses the SDP, extracts essential parameters and then starts the tools with the parameters on the client machine. The SDP content is embedded within the HTML as a parameter to the applet. The advantage of using HTTP-S to communicate the SDP content between client and server is that the SDP content (with encryption keys) will also be secure.

For obvious security reasons standard Java applets do not have permissions to access local resources and thus cannot execute software on the client machine. To overcome this, both Netscape Communicator and Microsoft Internet Explorer 4 allow applets to be digitally signed with a private key associated to a RSA object-signing certificate. If the user accepts the certificate, therefore trusting the applet, then the browser allows the applet access permissions outside the Java security sandbox. Communicator and Internet Explorer implement different methods and technologies for digitally signing and distributing objects:

Communicator requires Java applets to be signed using Netscape's Netscape Object Signing software. The certificate and Java code are then packaged using the JAR file structure. Signed Java applets need to explicitly request permission to access local resources, such as executing software using the Netscapes Capabilities API extensions. The request causes Communicator to prompt the user, asking them to either accept or deny the relevant permission. The dialog box also contains the certificate as verification of the source and authenticity of the code.

Internet Explorer requires Java applets to be signed using Microsoft's Authenticode software and packaged using a CAB file structure. A signed Java applet also has to request permission to access local resources by using Microsoft's Com API extensions. However unlike Communicator, the specific request doesn't prompt any user action. Instead the user is asked to accept the applets' certificate when the applet is encountered by the browser and by doing so grants universal access to local system resources.

More information regarding the applet can be found on the SPAR web page: http://www-mice.cs.ucl.ac.uk/multimedia/software/spar/

The Server is running the Apache Web software [apache1], which is IPv6 capable. The tools are already IPv6 capable, if started with IPv6 addresses. The whole system is, therefore, IPv6 capable whenever the browser is so capable. At present this only applies with the Microsoft Explorer IE4 or IE5.

We have incorporated a SAP listener with the Conference Store. This actually runs SDR, and allows announcements to be stored in a portion of the store. This acts as an announcement proxy. So far this has been configured only with the latest insecure version of SDR, so that only public announcements can be so stored. We are not yet sure whether it is worth extending this to the secured announcements, since we do not really want to pursue that avenue in any case.

The Server We expect to extend the server function to store arbitrary data, possibly unrelated to conferences. For example we plan to provide a secure certificate repository/depository, and to hold documents that require secure controlled access.

User-certificate authentication The current certificates are not signed by a CA trusted by the Server. If it were so trusted, proof of identity at registration could be accepted. We expect to provide some mechanism for using both roles and user names with such certificates, and to make provision for Certificate Revocation Lists.

Server replication To avoid the single point of failure, the server will be replicated so that alternative/backup/secondary servers can be accessed. This will be simple to do if the secondary servers have read-only copies of the information (e.g. updated daily/hourly), but more involved if users can update information on any server.

SPAR & Alternative Browsers Browser's that do not support signed applets but do have a "plug-in" architecture could use SUN's Java Plug-in to view the applet. The Plug-in requires the applet to be signed and packaged using Netscape's Object Signing software but it does not implement Netscape's Capabilities API. Since the API is not supported by the Plug-in, any certificate accepted by the user, would grant universal access to local system resources.

Other Extensions The server and SPAR Java Applet will be extended to process further media options/attributes; we now process most of the SDP, and support different media via configuration plug-ins passed along with the SDP by the server]

Currently we process only:

• the session title and description
• the multicast address, port, TTL and encryption key for each media
• audio, video, whiteboard and text media types

Different methods of choosing/obtaining multicast addresses will be supported eventually. We expect to study the integration and trade-off between this type of system and use of SAP and SIP.

The staffing of the project started fairly slowly, because of the delay in agreeing the original proposal. However, one graduate student started early on some of the components work, and the work on secure conferencing tools has proceed well. The persons associated with the project have been:

The UCL staff associated with the RADIOACTIVE project has been:

• Jon Crowcroft - Co-PI

• Panos Gevros – The QoS work of Section 2

• Kris Hasler – Implementing the secure conference store (SPAR), and updating the secured SDR
• Peter Kirstein - Co-PI

• Piers O'Hanlon – Investigating the variants of IPSEC at our disposal

• Colin Perkins – Maintaining the encryption portions of the Mbone tools
• Ed Whelan – Developing the security infrastructure, and working with the VPNs

1. Travel

During the last year, funds from SCAMPI have helped defray expenses for attendance at IETF, security and ICB Meetings. It would normally have defrayed expenses at DARPA PI meetings, but our attendance at these have been charged to RADIOACTIVE to date.