DARPA SCAMPI Project Year 1 Technical Report
Jon Crowcroft and Peter Kirstein
Department of Computer Science, University College London
2 July 2000
This is the first year report for the DARPA Scampi Project, funded from July 1 1999.
Most of the work has been in the completion of secure conferencing tools with application-level security. This has included upgrading to IPv6, and the incorporation of a new tool for secure announcements based on a Web store with use of group technology to restrict access. There has been considerable preparatory work in a number of areas which will bear fruit I in the second year: putting up and study of IPSEC in various modes; porting to Java versions of basic components such as the Universal Transcoding Gateway, the Multimedia Recorder and Reliable Multicast components. There have also been preliminary tests of a Virtual Private Network technology; this will eventually include the Xbone technology of ISI, and incorporate a number of the sites of the International Collaboration Board. Finally, the report describes our progress in all these areas, and indicates our intentions for the final year of the project.
We had a previous report D079 Supporting Internet Multicast Multimedia, which lasted from January 17, 1996 July 16, 1999 UCL. We requested two extensions to this project one to the end of 1998, and one for a further two years to the end of 2000. In the event, the first, no-cost, extension was granted, and a final report on the project was written [kirst1]. The second extension was considered, and approved in principle. In the event, partly because of a change in the project officers at ITO, the second extension was not approved before the end of the project. For this reason, a new contact was negotiated, which started on July 17, 1999 and terminates on September 30, 2001 [kirst2]. The new project, now called SCAMPI, was partially finishing off aspects of the original proposal, and partly starting new work which were a logical extension of the original project.
This report is the first annual report on the work done under the SCAMPI Project.
In [kirst2], we stated that we would do the following:
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.
In our original proposal, we stated that the two-channel aspect of this work depended on our obtaining a new channel to CAIRN based on UUNET and DARPA, and maintaining our current one. The new channel was to have the international portion provided by UUNET, but DARPA was to provide the termination between Palo Alto and the nearest CARIN node in Berkeley. In the event, while the link was ordered, its progress has not been followed up by the US Government procurement agent, and it has never arrived. Moreover, the DARPA share of funding for the previous link to Goddard MSFC was terminated in late 98 (this link was co-funded with NASA up to that date). NASA thereupon stated that the main purpose of the link they were supporting would be for bilateral tests with UCL. NASA permitted the link to be connected to CAIRN for specific experiments and videoconferences, but this was not the normal case. The co-ordination of the through routing has proved an administrative nightmare; the arrangements for the re-routing had to be carried out manually, and many times it did not occur. However, early in 2000, the UK academic network, SuperJANET, established peering with Abilene on Internet-2. There had been an agreement between DARPA and Internet-2 that CAIRN sites on existing networks could peer with the latter, and that any usage for DARPA purposes would not count as transit traffic. For this reason, we have been able to establish a link between UCL and a node at ISI via SuperJANET and Abilene. This link took some time to establish, but is now available.
We carried out extensive QoS experiments over LEARNET between Essex U and UCL in late 1999. These included layered audio codecs and video-on-demand; they included also correlation between user satisfaction and QoS (as measured by deliberate errors and manipulations of priorities in weighted fair queuing). The results were provided in some detail in [gevros], [sasse]. We expect to complete these measurements before the end of 2000, by using at least the new Internet-2 path to CAIRN, and possibly also the NASA path as a second channel.
The UCL work during the first three years of the project went a long way towards providing versions of the conference tools for Video (VIC), Audio (RAT), shared editing (NTE) and session announcement (SDR). While VIC and RAT were based on the earlier tools from Van Jacobson and McCanne at LBL, they were substantially modified at UCL. [kirst1], which was presented at DISCEX 2000, provides many background references to that work. The tools could be secured by DES encryption, and the encryption keys included in the Session Description of the conference [Han1]. The main problem was how to distribute information about private conferences only to parties authorised to participate.
The principal way that information about multicast conferences was distributed was by Session Announcement (SAP) or Session Invitation (SIP). During the previous project, we modified an earlier tool from Van Jacobson (SD), and provided SDR We then worked through the MMUSIC group of the IETF to standardise security procedures for SDR. By the end of the previous project, the authentication aspects of SAP had been standardised; we were unable to get agreement on standardisation for confidentiality for announcements. Nevertheless, we developed a version of SDR, which used public key cryptography to sign announcements; this was according to [Hand2]. We also developed an implementation which did symmetric encryption, with the symmetric key itself distributed by the use of an asymmetric Group Encryption Key (GEK). The GEK was distributed securely, e.g. by PGP or S-MIME, to the authorised participants. This mechanism was described in [kirst3], and an implementation provided; the latest version is SDR v2.7e. All the UCL software is available from the UCL web site [perk1].
During the current period, the tools RAT, VIC and NTE were made IPv6 capable, when linked with the relevant IPv6 stacks. This required some re-writing, to ensure that there was no explicit use of ipv4 addresses in the code. The tools listed in the developers versions on the UCL Web page have this capability. The latest version of SDR, v2.9, has been modified to be IPv6 capable (based on some ISI work) but has had the security routines commented out. This is because we have not considered it worthwhile to put in the effort to fully upgrade the secured version to include IPv6. Since secured SAP was not standardised, we feel that version of SDR would have limited use. Instead we have developed an alternative mechanism which provides security, and has been extended easily to IPv6.
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.
Groups of users can be created for access control to the information and group managers can add/remove users, create/delete sessions, change session keys. Users only have access to the information for the groups to which they belong.
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:
Note: for creating and joining sessions defined on the server, PGP keys are not needed or used..
Any web browser that supports HTTP-S can access the secure server. Joining conferences using the SPAR Java Applet requires either Netscape's Communicator or Microsoft's Internet Explorer 4/5. Users of other browsers should use one of the alternative methods of starting the MBone tools.
The server maintains a database of conference sessions (created using user-supplied details plus a random set of multicast addresses, ports and encryption keys). The server picks multicast address from our "glop" range although other scope ranges could be used. The addresses are random but unique across all active sessions defined. The ports are random (even numbered) but unique for each media defined for the session. The session encryption keys are random alphabetic strings - they can be changed at any time (e.g. when a group manager removes a user). The server automatically removes a session after the expiry time (as set when created). When a user joins a session, a server script generates an HTML page referencing the SPAR Java applet and encodes the session details as SDP data (passed in the HTML as a parameter to the applet). The applet is run by the browser and parses the SDP to execute the media tools on the host with the correct addresses/ports/keys required for the session.
Sdp PARser (SPAR) Java Applet
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:
Communicatorrequires 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.
Integration with SDR
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 ExtensionsThe 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:
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.
Most of the components in this section are in a similar state. We have had versions of them from previous work, and intend to put them in a secured form in the second year of SCAMPI. However, they have needed to be put into a better form for this purpose, and the work has been co-ordinated with another DARPA-funded project RADIOACTIVE [kirst4]. It has been necessary to rewrite many of the components so that they are pure Java, and can be put into a form of Proxylets which can be used in Active Services since all these components are used in that role; this rewriting is largely complete. An additional problem is that we have wanted all this work to be both IPv6 enabled and use IPSEC where possible. The IPSEC modules have only recently become available. The IPv6-enabled Java will become available only towards the end of 2000 As a consequence, the securing will take place in the final year of SCAMPI.
In the project plan, we expected to provide secured SIP by now. In practice, there was a version of SIP in the SDR of Section 3.2. However, this was based on earlier standards, and the whole protocol has assumed very considerable importance. We have decided to base our work on an implementation from Bremen U [ott1], which is being done in another project in which we both participate. This implementation will be available at the end of July 2000; we will start our work on the secured version only when this implementation becomes available.
An important component for this is the implementation of a reliable multicast. This has been implemented [vicis1], and implementation of the Proxylet is well advanced [kirst4]. Its secured implementation is expected during the second year.
The MMCR server has been rewritten in pure Java. It is also being made into a Proxylet under RADIOACACTIVE in fact as different proxylets for a proxy cache recorder, and a player [kirst4]. The securing will be co-ordinated with its becoming a Proxylet under RADIOACTIVE.
This component, which was based on Amirs work at Berkeley [amir], has had to be largely re-written in Java. It will be developed first as a transcoding gateway in RADIOACTIVE, but the security aspects will be completed here.
Under the aegis of the International Collaboration Board (ICB), one part of the SCAMPI project has been to participate with other members in the development of a Virtual Private Network (VPN) connecting the relevant sites. The prime mover in this work has been the Canadian Department of National Defence (DND), who has tasked NIRNS in Ottawa to work on the project. NIRNS has provided a number of working papers [spag1 spag4]. They also carried out some VPN tests with N3CA towards the end of 1999. We have been helped by both Cisco and Entrust to prepare for additional experimentation with NIRNS.
For the creation of VPNs, we need the IPSEC software. We have installed 12.05Ton our Cisco 2611 (we could not get it for our 4700, and also it does not support IPv6). We have configured manually an IPSEC tunnel for a VPN between NIRNS and UCL. We need the Cisco ISO 12.06(T) or later for our Ciscos to interwork with Entrust and use certificates. Unfortunately, the relevant software from Cisco is not yet available in its IPv6 mode, and the part of Cisco with which we work has not been able to provide the IPv4 versions. We are working with Cisco to overcome these temporary problems. We have installed also the Entrust-v5 system, including its Connect software. This should allow us to load certificates in an automated way into our routers from an Entrust database. We should then be in a position to configure in an automated way the VPN connecting NIRNS with UCL both in its IPv4 and IPv6 modes. We will then extend the activity to the other ICB sites.
We have been working also with Touch of ISI, and have installed his Xbone software at UCL [touc]. We participated in a demonstration of Xbone, when the Director of DARPA visited ISI in May 2000. We expect to combine the Xbone work both with the VPN activity under the ICB auspices, and with the Active Networks activity carried out under RADIOACTIVE.
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:
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.
[amir] E.Amir, S.McCanne and R.Katz, ``An active service framework and its application to real-time multimedia transcoding'', ACM SIGCOMM Computer Communication Review, Oct 98.
[apache] URL: expert.cc.purdue.edu/apache.html
[gevros] PT Kirstein et al: "
[Han1] M Handley et al: "SDP: Session Description Protocol", RFC 2327, Apr. 1998.
[Han2] M Handley et al.: SAP: Session Announcement Protocol, IETF draft, Jun. 1999.
[kirst1] D079 Supporting Internet Multicast Multimedia, Final Report, 24/04/99, Jon Crowcroft and Peter Kirstein, Department of Computer Science, University College London, 1999.
[crow2] J Crowcroft et al: "Mechanisms for Supporting and Utilising Multicast Multimedia, Proposal to DARPA for an extension to D079", Department of Computer Science, University College London, June 1999
[kirst3] PT Kirstein et al: "Secure Multicast Conferencing", DISCEX 2000, pp 54-63, IEEE Computer Society, 2000.
[crow4] J Crowcroft et al: "DARPA Radioactive Project Year 1 Technical Report", Department of Computer Science, University College London, July 2000.
[mccann2] S.McCanne, V.Jacobson and M.Vetterli, ``Receiver-driven Layered Multicast'', SIGCOMM `96, August 96.
[spag1] J Spagnolo, "International Collaboration Board VPN Pilot Project Preliminary plan", NIRNS, September 1999.
[spag2] J Spagnolo, "International Collaboration Board VPN Pilot Project - Cisco/IPSec Router Testing", September 1999
[spag4] J Spagnolo, "Entrust International Field Trials, Experience With S/MIME", NIRNS, March 2000
[ott1] J Ott et al: "The Gateways, Relays, Session Announcement and Management facilities in Software Release II", MECCANO Deliverable 6.2/7.2, Department of Computer Science, University College London, July 2000.
[rlc] Receiver Driven Layered Congestion Control (a.ka. rlc) ftp://cs.ucl.ac.uk/darpa/infocom98.ps.gz and ftp://cs.ucl.ac.uk//darpa/rlc-dps.ps.gz
[sasse] A Sasse et al: "HIGHVIEW project: Final Report, Department of Computer Science, University College London, Dcember 1999.
[vicisano1] L.Rizzo and L.Vicisano, ``A Reliable Multicast data Distribution Protocol based on software FEC techniques'', The Fourth IEEE Workshop on the Architecture and Implementation of High Performance Communications Systems (HPCS '97), June `97
[touc] J Touch et al: "The X-Bone" , Third Global Internet Mini-Conference in conjunction with Globecom '98, Sydney, Australia Nov. 8-12, 1998.
NIRNS3] International Collaboration Board VPN Pilot Project Examination of IPSec VPN Technologies, September 1999