ICE-CAR

Interworking Public Key Certification Infrastructure

for Commerce, Administration and Research

UCL Secure Conference Store

Overview

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 be used in two ways: to store and access PGP keys for use with secured SDR, and to store and access session details for multicast conferences. The second use is so arranged that 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 keys. Users only have access to the information for the groups to which they belong.

User details: Server access

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 SSL 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/PGP-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, an only basic checks are made on the user data supplied.

Registered users can create/manage "groups" and assign members (other registered users) who may access them. A "random" PGP key-pair is created for each group (e.g. for use with SDR if encrypted sessions need to be announced). 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: PGP keys or 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. The MBONE tool SDR is not used either.

Browsers

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.

Implementation:

Server

The server consists of set of CGI scripts (written in Perl for efficiency and ease of coding) that control access, generate dynamic HTML pages, and manage databases.

Conferences

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 can 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 field terminator used in the SDP is replaced with a 'browser friendly' alternative, as SDP's CR/LF field terminator is removed by the browser. The advantage of using HTTP 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:

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

Extensions/Future work

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.

Server additions

Users should be able to change/update their profile (e.g. change password etc.). Users should be able to request to join a group. Groups managers should be able to set a mode to allow users to create sessions. We will extend to full strength encryption when suitable servers are located.

User-certificate authentication

The current userid/password authentication will be extended so that users can identify themselves with a browser-supplied certificate. Also, if the certificate is signed by a trusted CA, 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.

IPv6

The system will be extended to work with IPv6, but this will require a web server and browser that supports IPv6 and HTTP-S. If the browser does not support Java applets then SUN's Java plugin could be used (see below). The server scripts/databases would need minor additions to process IPv6 addresses (e.g. to generate SDP, media attributes etc. suitable for IPv6 working).

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 Plugin to view the applet. The Plugin requires the applet to be signed and packaged using Netscape's Netscape Object Signing software but it does not implement Netscape's Capabilities API. Since the API is not supported by the Plugin, any certificate accepted by the user, would grant universal access to local system resources.

Extensions

The server and SPAR Java Applet will be extended to process further media options/attributes (ie. improve on the SDP support). Currently only the following part of the SDP is processed: 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.