The original of this document is RTF

Project Number: 1007 ( RE)

Project Title: Multimedia European Research Conferencing Integration (MERCI)

Deliverable Type: (PU/LI/RP)* PU

Deliverable Number: D10.1

Contractual Date of Delivery: 31 August 1996

Actual Date of Delivery: 9 September 1996

Title of Deliverable: Security Architecture for MERCI

Work-Package contributing to the Deliverable: 10

Nature of the Deliverable: (PR/RE/SP/TO/OT)** SP

Author(s): Knut Bahr, Stefan Braun, Elfriede Hinsch, Peter Kirstein

Abstract:

This deliverable provides the security architecture to be used in MERCI project - to the extent that it has been defined. We first overview the facilities provided in a number of other projects, in particular the following: PASSWORD, ICE-TEL, Van Jacobson's MBONE, MICE, the IETF and ITU-T. These facilities in some of the earlier work like PASSWORD and the MICE work have been superseded; only a specific subset of ICE-TEL's are applicable; Van Jacobson's work is not well documented; the IETF and the ITU-T activities are not fully compatible, and in many cases the relevant standards still being defined. Next we give an overview of the MBONE tools and protocols, in their unsecured state; this serves as a basis for the later work. We then overview general security considerations, and analyse security implementations as they are relevant to conferencing. An overview is provided of the ITU-T protocols relevant to conferencing; many of these need to be extended for secure conferencing.

Having provided the necessary background, two chapters provide the meat of this Deliverable. First we specify the security procedures to be used for MBONE conferencing. These include both securing the basic tools, and providing mechanisms for key distribution. Here our main proposal is to use modified versions of the Session Announcement and Session Description protocols; these are reliant on Public Key systems, and methods for key distribution by Directory, WWW and electronic mail procedures. Finally, we go through a similar exercise for the securing of coupled ITU-T and MBONE conferences; here the ITU-T mechanisms are not fully defined, and different facilities for securing the coupled systems are needed.

Keyword list:

multimedia conferencing, security, MBONE, multicast, video, audio, shared workspace, RTP/2

Table of Content:

1. Introduction

2. Status and Related Projects

2.1 Introduction
2.2 The PASSWORD Project
2.3 The ICE-TEL Project
2.4 Van Jacobson's work
2.5 MICE Activities
2.6 IETF Activities
2.7 ITU Activities

3. The MERCI Tools Without Security

3.1 Overview
3.2 RTP, the Real-Time Transport Protocol
3.3 The Media Tools
3.4 SDR

4. Main Security Functions

4.1 Requirements
4.2 The Methods of Meeting the Requirements
4.3 Available Technologies
4.3.1 Introduction
4.3.2 Security Technologies in Current Use over the Internet and Mbone

5. Secure Multimedia Conferencing in the ITU World

5.1 Confidentiality and Authentication for H.3xx Conferences
5.1.1 Functional Description of ITU-T Recommendations H.233 and H.234
5.1.2 Usage of H.233 and H.234 on top of networks other than ISDN
5.1.3 Draft ETSI Standard prETS 300 xxx: Eliminating the Need for a Trusted MCU
5.2 Admission Control for T.120 conferences
5.3 Security features provided by TELES.VISION Systems

6. Secure Multimedia Conferencing in the Mbone World

6.1 Functional Description
6.2 Encryption of Data Streams
6.2.1 General Requirements
6.2.2 Encryption built into the conferencing tools
6.2.3 Application-independent encryption
6.3 Conference Announcements and Invitations - The SDR Suite
6.3.1 Introduction
6.3.2 SAP and SIP Formats
6.3.3 Authentication and Integrity of Session Announcements
6.3.4 Confidentiality of Announcements
6.3.5 Session Invitations
6.4 Multimedia Servers
6.5 Conference Announcements and Invitations - The E-mail Case
6.5.1 Introduction
6.5.2 The Secure Conferencing User Agent
6.5.3 Assessment
6.6 Key Distribution in MERCI
6.6.1 Public Key Availability in MERCI
6.6.2 Group Keys

7. Bridging the ITU and Mbone Worlds

7.1 Summary of Security Features in the ITU- and the Mbone Worlds
7.2 Integrating the ITU and Mbone Multimedia Conferencing
7.2.1 General
7.2.2 Realisation of the Mbone/H.320 Gateway
7.3 Security Functions in the Mbone/ H.320 Gateway

8. Conclusions

References

1. Introduction

Secure multimedia conferencing is needed in open collaborative working, when confidentiality and privacy are an issue of multi-party communication and when it is desired to authenticate the participants and the organisers of conferences.
Currently, there are basically two "worlds" of conferencing: systems based on ITU standards and communications over circuit-switched nets like ISDN, and systems which are based on Internet, Mbone and standards developed by the Internet Engineering Task Force (IETF) - which is the main standardisation body for the Internet. So far, commercial users tend to work with tools from the first category, whereas scientific researchers often use the other kind. This situation, however, is changing. Though the main focus of project MERCI is multimedia conferencing within the Internet/Mbone world, the project also aims to provide bridges between the two worlds. So, it will - among other things - investigate how a secure conferencing can be provided between the packet-switched and the circuit-switched worlds.
The MERCI project is not aiming to develop security technology; as much as possible, it will incorporate technologies from previous EU projects, from the concurrent ICE-TEL project, and from partners who are active in the ITU and IETF worlds. It will attempt to link to other security technologies as they become available. Nevertheless, there are limits to the amount of help it can get from other projects.

Return to Table of Content

2. Status and Related Projects

2.1 Introduction

A number of projects and activities are addressing the subject of security - and are relevant to the MERCI project. In this section we will address those whose results we expect to use in this project. The most important of these are the PASSWORD project, the ICE-TEL project, the work of Van Jacobson at the Lawrence Berkeley laboratories (LBL), the MICE project, the work in the IETF, and the work in the ITU. Each is discussed below.

2.2 The PASSWORD Project

The PASSWORD project was a European Union project which was completed in mid-1994. It had a number of important outcomes:

While this project was important in its time, few of its outputs are still directly usable in MERCI. The toolkits have undergone massive improvements since the PASSWORD days; the European Directory Service was based mainly on QUIPU, which is a 1988 Directory service, and does not interwork with current (1993) X.500 Directory services; the X.509v1 certificates are too limited for a real infrastructure, and are being replaced by X.509v3 ones in the commercial world; the PEM implementations standardised at that time have been overtaken by current Internet secured mail products: S/MIME and MOSS.

2.3 The ICE-TEL Project

The ICE-TEL project [icetel] is aiming to provide a Public Key infrastructure for Europe. It is also providing security toolkits, Certification Authorities, holding certificates in Directories, and supplying the applications of secured directories, secure E-mail and secure World Wide Web. In secure E-mail, it will be working with formats like PEM [pem1, pem2, pem3, pem4], MOSS [moss] and S/MIME [smime]. The products from the ICE-TEL project will be invaluable for MERCI, and will be used as much as is feasible. Nevertheless, ICE-TEL is targeted at document services; it has no remit to cover real-time conferencing. Moreover, multimedia conferencing is essentially predicated on groups of users interacting; hence there are significant differences on the way security services are best invoked in this environment. This will become clearer in the course of this report.
The following important aspects of ICE-TEL will certainly not be redone in MERCI; to the extent that they can be used in this project, the ICE-TEL tools and deployment will be used:

2.4 Van Jacobson's work

Van Jacobson at the LBL provided the principal tools that have been used in Mbone conferencing: the audio tool (VAT) [vat], the video tool VIC [vic], and the Shared Workspace tool WB [wb]. These were initially provided in unsecured versions, and source forms have been made available via the Internet. They have since been secured; because of US export laws these versions may not be exported from the US with strong encryption. Any tools developed under the MERCI project should have the capability of interworking with Van Jacobson's tools if this can be achieved.
Van Jacobson has also developed a Session Announcement package (sd) [sd],which has been in wide use to announce the intention to hold Mbone sessions.

2.5 MICE Activities

Under the MICE projects, Van Jacobson's tools have been developed further. Two audio tools were produced (RAT and IVS), which had a compatibility mode with VAT. A video tool was produced (IVS), which could interwork with VIC. Moreover, secured versions of RAT and IVS were produced, and the unsecured versions of VAT and IVS were secured with encryption implementations from UCL and INRIA. While interworking between the secured versions from LBL and those from MICE had been discussed, it was not achieved at the end of the project (earlier versions had interworked, but both projects had changed their implementations, so that interworking was not achievable at the end of the MICE project).
Under the MICE project, GMD had also provided a Security User Agent, which used a version of PEM to distribute keys. This software was demonstrated at the 1995 Stockholm IETF conference, and was quite usable. However, it relied on the use of a particular version of a mail tool based on UNIXmail. This version of the Secured User Agent was just a first prototype and not widely deployed.
The version of sd developed by Van Jacobson was somewhat extended in MICE. Moreover a new shared text editor NTE was developed. Both of these will be used further in the MERCI project.

2.6 IETF Activities

The IETF has a wide range of relevant activities; these are being followed in considerable detail by many of the Telematics projects. In the context of this report, we are only concerned with the IETF activities relevant to secure conferencing. There are many Working Groups on Authentication, Transport Layer Security, E-mail and the WWW. Some of the work in these groups is relevant, and it is being followed closely by the groups at UCL and GMD - partly for MERCI and partly ICE-TEL purposes. Four working groups are particularly relevant: the MMUSIC group on conference control, the AVT group on Audio-Video Transport, IPSEC on IP layer security, and the PKIX group on a Public Key infrastructure. The work on secure mail and secure directories is also relevant.
In the context of the AVT group, it would have been possible to specify secure data streams at the IP level or the RTP transport level. This has been done in the IETF, but it is not yet clear what versions will proceed to implementation. This is discussed further in Section 6.2. There are currently a limited number of interworking tools, so it has been decided for the moment to incorporate encryption into the tools themselves. For the Mbone tools used in MERCI and those from UC Berkeley, the IETF acts as an extremely valuable forum for information exchange, and a mechanism to ensure interoperability - even before the WGs provide standards.
In the context of Session Announcement and Session Invitation, which are treated in MMUSIC, it has been agreed to provide secure Announcement and Invitation Standards; any MERCI work here is in full knowledge of the MMUSIC work - in fact Mark Handley from UCL currently chairs the group and is introducing the MERCI standards into the IETF.
As will be discussed later in this report, we are considering alternate mechanisms for session announcement, key exchange and invitation, which are out-of-band and depend mainly on secured message or directory usage. In view of this, we also have to follow the relevant WGs in the IETF.

2.7 ITU Activities

The ITU has defined protocols for multimedia conferencing in its H.3xx and T.12x series of recommendations, for example:

Mechanisms to support confidentiality and authentication for ISDN-based multimedia conferences are defined in ITU-T Recommendations H.233 [itu-h233] and Draft H.234 [itu-h234]. Both Recommendations assume that (real-time) data exchanged between peer nodes are encrypted by symmetric encryption mechanisms such as DES or FEAL and define mechanisms to agree upon the encryption algorithm, to exchange session keys and perform authentication.
H.233 and H.234 were originally developed for ISDN-based multimedia conferencing. They make use of data channels provided by H.221 [itu-h221] to exchange data and in some cases exploit the isochronous nature of ISDN networks (e.g. for the synchronisation of session key changes).
For some non-ISDN environments (especially the telephone network) H.233 and H.234 can be applied without major modifications. In other environments (LANs, ATM) some adaptation is required. The discussion about these adaptations is still ongoing: SG 15 of the ITU will consider security for H.323 and H.310 terminals and its relation to IETF encryption at its next meeting in September 1996.
Both H.233 and H.234 define the above security mechanisms on top of individual communication links and not between the end systems in a multi-point conference which are usually interconnected in a star topology by means of an MCU. Because the MCU can decrypt all incoming data streams it must be a trusted entity. Draft ETSI standard "Service Access Control and Synchronisation for Audio-visual Services" [etsi-xxx] defines how the mechanisms defined in H.233 and H.234 can be applied between end-systems in a multi-point environment so that the MCU does not have to be a trusted entity.
In addition to the above ITU-T Recommendations, T.124 [itu-t124] provides limited functionality to control the access to a conference.

Return to Table of Content

3. The MERCI Tools Without Security

3.1 Overview

The user group for multimedia conferencing in MERCI is scientific and research. The software used must fit into their normal working environment. So mainly desktop conferencing is realised and there is a lesser emphasis on conference rooms. Most of the work in MERCI is focused on Mbone conferencing, but the interoperation between Mbone and ITU conferencing is also an important objective. So the desktop workstations include both terminals which run Internet applications and others which run ISDN and ITU conferencing applications.
The ITU conformant terminals for multimedia conferencing are wide-spread commercial products for ISDN. They realise the H.320 suite of ITU-T Recommendations, which specify a visual telephone service for narrow band ISDN channels of p x 64 Kbps up to 1920 Kbps guaranteed bandwidth for communication between 2 partners. Multipoint controls units (MCUs) are used to bridge three or more such terminals together in a multipoint conference. At a higher level, the T.120 suite of recommendations defines a general conference control and architecture. It also proposes a protocol T.126 [itu-t126] suited for application sharing, but since this is not finalised yet, current implementations are proprietary in that respect.
The MERCI tools for multi-media conferencing in the Mbone include several intercommunicating packages. These include the following: a Real-Time Transport protocol (RTP) [rtpprot], which is mounted above the Datagram protocol UDP; media tools, and Session Establishment suite (SD) or its modification Session Description Rendez-vous (SDR) [sdr] software. This last announces Mbone sessions, and has facilities to start the media tools and to invite conference participants. Each is considered in turn below.

3.2 RTP, the Real-Time Transport Protocol

The communications infrastructure for the data transport is based on packet switched networks with Internet protocols and on Mbone as a virtual network [mbone] on top of it. This allows applications to work in a multicast mode (one-to-many connections) without the need for any central service. There are a number of lower level protocols in use. First, for the Mbone, the Internet Protocol (IP) has been extended to allow the destination address to be a multicast group. A tree structure for each multicast group is maintained in a set of multicast routers. These routers used to be separate from the main unicast routers in the Internet; increasingly the main routers are providing facilities also for multicast routing.
Above the IP level, there are several end-end protocols. The two main ones are the User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP). The former sends unsequenced, unacknowledged, datagrams; the second maintains reliable data streams - adjusting the data rate to ensure that losses are minimised. The latter is used for applications where it is of paramount importance to get the data from one end to the other reliably - even at the cost of additional delay. The former is used when delay is more important - particularly if late retransmission is comparatively useless as in audio communication..
The Real Time Transport Protocol (RTP) is layered above UDP. This has facilities for multiplexing different streams, incorporating sequence numbers and time-stamps [ntp] both for when packets were sent and when they were received, and for interpolating control messages with the data. Another property of RTP is that it gives an indication of each receiver being active to all the other participants in the multicast conference. It does this by requiring Sender Reports (sr) and Receiver Reports (rr) being sent along the multicast routes.

3.3 The Media Tools

Among the media tools used are the following: VAT is a conference tool for audio [vat], WB is a whiteboard tool which substitutes for a regular whiteboard as well as a slide projector [wb], IVS [ivs] or VIC [vic] are used for the user video interface in workstations. Recently we have added additional tools: Free-Phone and the Robust Audio Tool RAT [rat], the shared workspace Network Text Editor (NTE) [nte]. VAT, Free-Phone, RAT, VIC and IVS are all designed to operate above RTP. They use the timing information from the RTP packet format to adjust their play-out. Each tool is run on a separate multicast address.port number pair, and is started with its own set of parameters.
When any of the Mbone tools are started, an indication of this fact is passed to each of the other participants.

3.4 SDR

SDR provides facilities to announce conference sessions, invite participants, and start tools. The announcement portion implements the Session Announcement Protocol (SAP) [sap], which in turn announces periodically a description of each Mbone session which is to be held; the session description has a format defined in the Session Directory Protocol (SDP) [sdp]. The session announcement is simply multicast to a well-known multicast address and port. It has a Header and a Session Description Payload. The Header gives Message Originator, Message Type and a Message ID; the Session Description Payload is the description of the protocol parameters. It is possible to modify or delete a pre-announced session by sending a modified announcement; this contains the same SAP header, with a different version number, and instructions for modification or deletion.
To invite users to participate in a session a specific UDP message is sent to a well-known port on the home machine of a specific individual, containing the same Session Description information. The details are given in the Session Invitation Protocol (SIP) documentation [sip]. An agent at the known location of the invitee responds. The invitation is either accepted, rejected, or a datagram is returned suggesting that an alternate location be contacted.
Finally, there are tools, and a graphical user interface, in SDR which allow one to click onto a specific session, and its parameters are passed to a command line which starts the requisite media tools.
SDR is fundamental to the use of the MERCI tools on the Mbone; session announcements are normally made publicly to minimise the number of simultaneous Mbone conferences that are attempted - to ensure that there are adequate resources on the Internet. While it is possible to start the individual tools manually, it is much more common for a user to start the whole conference session together using SDR.

Return to Table of Content

4. Main Security Functions

4.1 Requirements

The following security requirements should be met to achieve secure conferencing. The conferencing systems and tools used must provide the corresponding security functions; if they do not, they should be enhanced as far as the available technology allows such extension with a reasonable effort.

4.2 The Methods of Meeting the Requirements

These requirements may be met by conferencing tools with built-in security or by enhancing conferencing tools with suitable security functions; this requires encrypting the information exchanged among participants, by keeping the encryption keys confidential and by having participants authorised.
For the purposes of this project, the following security functions have been identified as basic building blocks needed to construct a set of features to choose from:

Encryption allows both access control and confidentiality.
In case of a centralised conference service with point-to-point connections to the clients, it may suffice to restrict the conference access by a password or better an authenticity control function. Assuming that the conference centre is made safe enough to prevent unauthorised intruding or eavesdropping, one could do without data encryption. Only when confidentiality is an issue, would it be required to encrypt the transmitted data.
In case of decentralised conference services and multicasting over Mbone, the network does not offer any distinct access control facilities. So, if a conference shall be restricted to a specified set of participants, the broadcast information will have to be encrypted. In any case, there is also danger of a "denial of service" attack by spoofing session announcements or modifications - so that authentication is required.
For performance reasons, symmetric cryptography is used for encrypting large data volumes. The encryption is done by means of a so called session key. The same key is used for both encryption and decryption, and each participant needs to know the key. This key may be valid for one or more sessions, depending on the particular situation, and it may differ depending on the type of data.
The session keys used to encrypt and decrypt the audio, shared workspace, and video data streams, must be distributed to all conference participants. The keys have to be distributed confidentially so that unauthorised users cannot get a hold of it. Thus, a proper key distribution method is needed.
Key distribution may be done "out-of-band", that is through a communication separate from the conferencing environment, for example by a verbal exchange of keys in a meeting or in a telephone call, or by secure E-mail. This mechanism does not really scale to large numbers of conferences, or large numbers of participants, and is not considered any further here. On the other hand, when key distribution is to be done within the conferencing environment, one needs secured, i.e. encrypted, channels for this purpose. Asymmetric cryptography is well suited for this case and various techniques based on this method have been chosen for MERCI: secured E-mail, secured directory access, or a secured Session Announcement. It should be noted that while secured E-mail works well with small numbers of conferees, it does not scale well with large numbers.
Asymmetric cryptography is used to authenticate persons and to preserve integrity, e.g. by means of digital signatures; it can also be used to encrypt small amounts of confidential information. Each person requiring this facility is given an asymmetric key pair consisting of a public key and a private key. The private key must be kept secret by the owner. In order to confirm the correct identity of a key owner, it may be required that the public key be certified by a trusted third party - the certification authority (CA). In this case, certification functions are needed. Such functions will be provided for MERCI - mainly from the ICE-TEL project.
There are different ways of safely storing the asymmetric key pair with its owner. A common method is the provision of a so called Personal Security Environment (PSE). The PSE holds an asymmetric key pair and comprises the pertinent management functions. Alternatively, public keys may be stored in a central directory, for example an X.500 directory.
In MERCI, every user who wants to take part in confidential conferences will need a PSE with a key pair of his/ her own and possibly a certificate for the public key. At the least this key is needed for the purpose of ascertaining who is participating in a conference. Because of the group nature of many conferences, it would be possible to distribute a Group Key (i.e. an asymmetric key pair with the private part kept secret by the members of a group) and to allow announcement, session key distribution and change to a conference to be carried out by any member holding the group key; in practice this mechanism is unlikely to be considered adequate - because of the difficulty of telling when keys have been compromised. It is possible to consider variants, however, where conference announcements are made through a group key, but participants join conferences using their private keys.
Thus there have to be facilities accessible to generate asymmetric key pairs and to distribute them. The original distribution of the private keys might be via an out-of-band system such as telephone or secure E-mail. The distribution of the public keys for the authentication of information could be by E-mail, by use of a directory, or could use the same mechanisms as the session announcements. For small numbers of conferees, with relatively well-known sets of participants, it is possible to hold caches at well known sites of the public keys of potential participants. For large scale use with a broad population, such local mechanisms would break down.
In most large-scale security applications, it is normally assumed that it is possible to communicate with a directory for public keys, to avoid requiring that they must be sent with the encrypted information, and to have an infrastructure of certification authorities to verify the currency of certificates which contain these keys. These procedures may be run independently of conference applications; the infrastructure may serve for a whole range of security relevant applications - not just for conferencing. Currently the IETF and the ICE-TEL project are just two of the bodies considering how to deploy a Public Key infrastructure; the former has not decided how to provide it, while the latter will use X.500 directories. In the specific case of secure Mbone conferences, many of the participants will be part of the Internet community, and have no need to use security for any other purpose than conferencing. One of the questions we will need to resolve is how much infrastructure we can expect from our participants.

4.3 Available Technologies

4.3.1 Introduction

For the first security prototype in project MICE, it was decided to use the formats and procedures developed in the European PASSWORD project [password]. As a result of PASSWORD, there exist compatible security software packages for example at the partners INRIA, UCL and GMD. This technology includes the basic mechanisms for encryption, digital signing, use of certificates, and use of Certification Authorities. There also existed secured applications, in particular X.500 Directory implementations and the PEM secure message packages, which could be used to transmit information securely between the participants. Initially it was proposed that MERCI continue along these lines, but there are certain problems in this course of action; these include the following:

As a result there have to be some reconsideration of our original strategy. It is still necessary to encrypt the real-time data streams sessions; the appropriate technology can be extracted from one or more of the toolkits provided by PASSWORD. The session keys must still be distributed securely; this requires either that they be distributed by a secure system, or they must be accessible in some storage only to authorised recipients. The technologies available to achieve these are discussed below.

4.3.2 Security Technologies in Current Use over the Internet and Mbone

The ICE-TEL project is continuing the work of the PASSWORD project. The software from this project is now available in some form, though it is being continually upgraded. It offers the following services:

  1. Tools to Provide and manage a Private Security Environment (PSE) for a user:

  1. Provision of security functions and an Application Programming Interface (API) to them:
    There is a library of security functions and a cryptographic API which allows one to incorporate security into multimedia conferencing applications with the following features:
  2. Secured Applications

Return to Table of Content

5. Secure Multimedia Conferencing in the ITU World

5.1 Confidentiality and Authentication for H.3xx Conferences

5.1.1 Functional Description of ITU-T Recommendations H.233 and H.234

ITU-T Recommendations H.233 and Draft H.234 were developed as a part of the H.320 suite of ITU-T Recommendations which define multiplexing schemes, coding algorithms, communication procedures and protocols for ISDN-based multimedia conferencing equipment. H.233 and H.234 define mechanisms to achieve confidentiality and authentication between parties communicating via an individual communication link. Such links exist either between two terminals (point-to-point connection) or between a terminal and an MCU (multi-point conference).
Figure 1 shows the underlying model of a link encryptor [itu-h233]:


Figure 1: Block Diagram of a Link Encryptor

The link encryptor consists of an encryptor block and a decryptor block. Both are interconnected by two channels, namely a data channel which carries the encrypted data and a control channel which is used to pass unencrypted control information (the so-called ECS channel). Both channels are usually multiplexed into a single data stream; in H.320 terminals, H.221 provides this multiplexing function.
H.233 and H.234 define a set of messages to be used on the unencrypted ECS channel. Furthermore, they define at which point in time commands which may be contained in the message should be applied, for instance at which point in time encryption of real-time data should be activated or at which point in time a session key should be changed. For this purpose, they build on the isochronous nature of the ISDN network. In some cases, this makes it difficult to apply H.233 and H.234 in other environments, e.g. on top of LANs.
H.233 and H.234 assume that real-time data (such as audio- and video data) are encrypted by means of symmetric encryption algorithms such as DES or FEAL.
Messages defined by H.233
The messages defined by H.233 may be used by communicating entities to find out which decryption algorithms the other side supports and to select a corresponding encryption mechanism:

Algorithm capabilities (P8) indicates which algorithms for decryption the sender of the message supports (FEAL, DES, ...) and for which types of data streams (audio, video, LSD, HSD, MLP)
Algorithm command (P9)indicates the encryption algorithm which the sender will use after the next synchronisation point.

Furthermore, H.233 defines error messages which a party may use to indicate to the communication partner that it could not carry out a specific command.

Messages defined by H.234

H.234 builds on H.233 and defines mechanisms to exchange keys over an unsecured link and to perform authentication. The exchange of session keys can be achieved according to one of the following mechanisms:

H.234 defines the following messages related to the session key exchange

Request Privacy System (P0)indicates that the sender wishes to use an encryption system and which algorithm for key exchange he/she supports (ISO 8732, Diffie Hellman, RSA).
Here is Session Key Information (P6) the sender of this message is exchanging session key information.
Key Exchange Info (P3)
(Diffie Hellman) 		the sender of the message is sending the contained key as a part of the Diffie-Hellman mechanism
Intermediate Key Exchange Info (P4) (Diffie-Hellman) the sender of the message is sending the contained key as a part of the Diffie-Hellman mechanism.
Check Code Info from the MCU (P5) (Diffie-Hellman) an MCU is sending the contained check code information resulting from Diffie-Hellman exchanges.

H.234 defines the following messages related to Authentication:

Authentication Initiation (RSA.P1)
(RSA) 		the sender of this message wants to start an authentication procedure with the receiver and sends information required to start the procedure.
Authentication Response (RSA.P2)
(RSA) 		the sender of this message responds to an authentication initiation and sends information needed for the authentication procedure.
Authentication Complete (RSA.P3)
(RSA) 		the sender of this message, being the initiator of the authentication procedure, sends the information needed to complete the authentication procedure.
Authentication Failed (RSA.P4)
(RSA) 		the sender of this message indicates that something has gone wrong in the authentication procedure.

H.233 and H.234 describe the above messages, the sequence of their use to exchange keys, agree on an encryption algorithm to perform authentication as well as their parameters in detail

5.1.2 Usage of H.233 and H.234 on top of networks other than ISDN

H.233 and H.234 were developed to be used in conjunction with multimedia conferencing systems operating over ISDN (H.320). In some cases, these Recommendations make use of the isochronous nature of ISDN.
In the meantime, the ITU has also developed recommendations which define how to perform multi-point multimedia conferencing on top of other networks, e.g. GSTN (H.324), LANs (H.323) and ATM (H.310). In some cases, H.233 and H.234 have been adopted to provide security functions for these environments, in other cases, the discussion about these issues is still ongoing in the ITU:

5.1.3 Draft ETSI Standard prETS 300 xxx: Eliminating the Need for a Trusted MCU

In ITU conferences, multiple audio-visual terminals are interconnected by means of one or more Multi-point Control Units (MCUs). The security mechanisms of H.233 and H.234 are only defined for point-to-point links and thus in a multi-point environment the MCU would decrypt the data from all its associated links. The MCU must therefore be a "trusted MCU".
In order to overcome this problem, ETSI has defined draft standard [etsi-xxx] which extends the applicability of the mechanisms defined in H.233 and H.234 for the communication between end-systems in a multi-point environment so that a trusted MCU is not required. It achieves this by making use of frame-synchronous control and indication signals as specified in ITU-T Recommendation H.230 [itu-h230].
According to [etsi-xxx], key distribution and authentication between end-systems in multi-point conferences with non-trusted MCUs are controlled by a "Chair Control Terminal (CCT)" which is a normal audio-visual terminal with the capability to generate session keys and which supports ITU-T Recommendation H.230. The RSA algorithm is used for authentication and to encrypt session keys.
The CCT communicates with the other end-systems directly, i.e. it exchanges the messages defined in H.233 and H.234 with these terminals. Terminals are identified by the 16-bit terminal identifier assigned to them when connecting to the MCU. The MCU routes messages from the CCT to the selected DMC terminal. The CCT selects a terminal to communicate with by placing the 16-bit terminal identifier into so-called IV blocks which are exchanged between the terminal and the MCU.
Involved in the exchange of session keys are the messages P6 (Here is Session Key Information) and a newly defined message P12 (Key Received Confirmation):

Key Received Confirmation (P12) the sender indicates that the terminal has received the new session key supplied by the MCU

The MCU broadcasts session keys to all participants, using the message P6. Each participant, after receiving the message P6, confirms it using P12. The MCU sequentially establishes connections over the ECS channel to each participant to receive the confirmation. The MCU should repeat P6 until it receives P12 from the participant or a specified time has elapsed. The partner is dropped when no confirmation is received.

5.2 Admission Control for T.120 conferences

The T.120 series of ITU-T Recommendations defines conference control mechanisms for multi-point multimedia conferences. It was designed to be used in conjunction with the ITU-T Recommendations of the H.3xx series. The supported conference models, the possible roles of participants as well as their corresponding privileges as well as most security features in this context are defined in T.124 "Generic Conference Control (GCC)" [itu-t124]. Conferences are always created on specific MCUs and can then be joined by other nodes. Alternatively, conferences can also be set up as "dial-out" conferences in which the MCU calls the dedicated conference participants. The architecture of the T.120 protocol stack is depicted in figure 2.


Figure 2: ITU-T T.120 Infrastructure Recommendations

GCC provides conference-level security mechanisms in several ways. On the one hand, it allows the Conference Convenor to configure the conference as "unlisted". In this case, the conference is not listed in response to a GCC-Conference-Query request and is thus not visible by normal means. Potential conference participants must be informed of the availability of such a conference on a given MCU by other means.
In addition, the IMTC suggests the following GCC mechanisms to control the access to a given conference:

5.3 Security features provided by TELES.VISION Systems

The TELES.VISION H.320 software architecture supports powerful security facilities to protect multimedia conferences and telematic sessions against unauthorised listeners/watchers. The security features of TELES.VISION are based on a combination of asymmetric key mechanisms (RSA) and symmetric key mechanisms (DES) as well as on the relevant ITU-T Recommendations H.233 and H.234. Security services provided by TELES.VISION comprise authentication, confidentiality, digital signature and access control.
TELES.VISION authentication facilities comprise local authentication and peer-to-peer authentication. By means of local authentication mechanisms a user proves that he is the owner of a chipcard which he has previously inserted into the chipcard reader of the system. This chipcard contains his private key which is later required for peer-to-peer authentication (described below). Local authentication is achieved by comparing a Private Identification Number (PIN) entered by the user with the PIN stored on his chipcard. In case that both values match it is assumed that the user is the owner of the corresponding chipcard. Local authentication is also used to grant or refuse a user access to a specific terminal. In this case, any TELES.VISION service can only be used after the user has performed a successful local authentication.
TELES.VISION peer-to-peer authentication services are based on asymmetric key mechanisms. A user authenticates himself by encrypting his name by means of his private key and sending the result to the communication partner. The communication partner verifies the identity of the user by decrypting the message with the public key of the user.
The private key of the user is stored on his chipcard. In order to authenticate the user, his name is encrypted by the chipcard and sent to the communication partner. During this process, the private key of the user never leaves the chipcard.
Public keys of communication partners are stored on either the hard disk of the machine or in a remote data base. In order to verify the identity of a remote communication partner, a TELES.VISION system first retrieves the public key of this partner and then uses it to decrypt the message sent by him. When the decrypted message provides the name originally encrypted by the authenticating user, the authentication is considered successful.
In addition to authentication, TELES.VISION also provides confidentiality services. Confidentiality is achieved by encrypting data with a session key before sending them to the communication partner(s). The encryption of data in this context is performed according to the (symmetric) DES mechanism. This mechanism can be implemented far more efficiently then the asymmetric mechanisms such as RSA and is thus more suitable for the encryption of high volume data such as audio- and video data in a multimedia conference. Prior to the start of the session, the session key is encrypted with the public keys of all partners designated to join the session and distributed to these partners. The session key is exchanged at regular intervals.
The security services provided by TELES.VISION fully comply with the relevant ITU and ISO recommendations in this area, especially ITU-T recs. H.233 and H.234 and ISO 7498-2.
Corresponding to the different ITU-T Recommendations for multimedia conferencing on top of different networks, there are different types of TELES.VISION systems, namely TELES.VISION / H.320 systems, TELES.VISION / H.324 systems and TELES.VISION / H.323 systems. The full security functionality as described above is currently implemented only for the TELES.VISION / H.320 systems.

Return to Table of Content

6. Secure Multimedia Conferencing in the Mbone World

6.1 Functional Description

The original LBL conferencing tools, VAT, VIC and WB were designed with encryption functions built in. However because of license restrictions, export restrictions, or national regulations they are not internationally available with built-in encryption. Nevertheless, it is possible to communicate across borders in crypto-mode when crypto-modules were added nationally in a compatible way. Most tools do in fact have an interface for adding encryption, and this is being utilised in some of the approaches.
There are three other important activities involved. One is the incorporation of security features into SDR announcement and invitation protocols, the second is the distribution of the PassPhrase from which the DES key can be derived in a secure manner to the targeted recipients; the third is the imposition of security at the transport level. Each of these is considered below. An important aspect of the solutions we are considering for secure conferencing is our desire to minimise the special infrastructure required by participants of secured conferences.

Return to Table of Content

6.2 Encryption of Data Streams

6.2.1 General Requirements

It is fundamental to secure conferencing that the data streams be secured. There are several ways of encrypting the data streams. One is to integrate encryption into each multimedia tool. Another is to use an encrypted transport layer, and to use the unsecured version of the tools themselves. A third is to use the current real-time transport level, but to encrypt at a lower level. The IETF has made provision for each level to be used, and we will mention here both what proposals are being made for standardisation, and what we intend to do in the MERCI project.
We discussed in Section 3 the different levels used; these are the media tools themselves (e.g. VIC, VAT etc.), the Real Time Protocol (RTP), UDP used to carry the data units, and IP itself. Security requires a complex set of mechanisms to achieve good results - and it is often very difficult to show that any particular implementation achieves it. For this reason, it is desirable to minimise the different mechanisms used.
At the lowest level, one can use a secured version of IP. Proposed standards are available from the IETF Working Group IPSEC [ipsec-arch, ipsec-auth]. There are several problems in proposing to use the IPSEC suite for secure conferencing. The most serious is that the Standards are still in the process of formulation, and products are not yet available; in fact there is some doubt whether products will become available at all with IPv4, but that instead vendors may wait until IPv6 is deployed. Certainly to use this level requires kernel versions of IP, and these are beyond the scope of the MERCI project - and the IETF Working Groups also have decided that interim solutions are essential. It is certainly possible to apply encryption to whole UDP; some of the IPSEC recommendations, like [ipsec-esp] could be applied at this level. Many of the concerns about using IPSEC apply also to the use of secured UDP.
The next logical place to apply encryption is at the transport level; this is the level adopted by the ITU for dealing with security issues. For some functions, it is the only place where security can be imposed. There is, however, little IETF activity in implementing the security features at this level. This is partly because the Mbone tools use application-level framing, so that the RTP transport is tied in with the tools themselves, and partly because no appropriate lower level exists below RTP other than at which IPSEC would be applied.
It is possible to change the encryption key during the conference. In the ITU case, there is central control, and it is possible to signal the need to change keys in a control stream; it would be possible to make similar provision in control portions of RTP; however, the independence of the data stream would require receivers to try both the previous and next key. Provision is made for this in some implementations of the key exchange.
In Section 6.2.2 we consider the mode in which the security features are provided inside the separate tools. This has the disadvantage that mechanisms have to be introduced into each tool separately, and have to be updated when the tool itself changes. Nevertheless, it allows each tool to introduce those features considered most suitable for it; moreover, integrating such activities as encryption with the tool, is probably the most efficient from an implementation viewpoint. Finally, it is possible to provide application-independent encryption at the tools level. This would avoid the need to mesh with the individual, possibly closed tools, but it will be less efficient, and may be less secure. The main difficulty is to locate an interface at the tools which is suitable for attaching encryption. Nevertheless, Section 6.2.3 addresses one attempt at this approach.
For the Mbone tools every effort is made to use compatible data formats; similarly within the ITU world with H.320. But between the ITU and Mbone worlds, different formats of data are used. For secure conferencing, it is then necessary to convert between these formats, which can be done only with the unencrypted data. Thus in such gatewayed conferencing, it is necessary for the gateway to hold the encryption keys, and to mediate between the unencrypted formats.

6.2.2 Encryption built into the conferencing tools

Securing the Mbone tools has the advantages that it can be done using the full infrastructure of the RTP transport protocol and of Multicast. As described in Section 3.3, the MERCI project is using mainly RAT for audio, VIC or IVS for video, WB for shared whiteboard, Network Text Editor (NTE) for shared text editor and SDR for session announcement. Where possible, all these tools have been, or are being, enhanced with the possibility for encryption. SDR is concerned only with announcement and start-up of sessions; this is considered in Section 6.3. The media tools themselves require the provision of information specifying the encryption algorithm used, other parameters to describe the encryption and the encryption key. In the only version of this implemented so far for the MERCI tools, the encryption algorithm used is the symmetric single DES [des], and the only parameter needed is the encryption key. In each case, we are using an initiation vector and an encryption key. The developers of the tools have agreed to pass information about the symmetric key in the form of a PassPhrase; this is conformant to [rfcprop], which has been agreed in the IETF. This PassPhrase is passed through an MD5 [md5] module, to ensure true randomness of the encryption key; the first 56 bits after passing through the module are used as the Encryption Key; this mechanism has been built into the above existing media tools. Because the PassPhrase is 7bit printable ASCII, as are all the other parameters provided by the tools, it is possible to provide the whole Description Payload, as in Section 3.4 as a printable block.
One aspect of security is the interworking of the tools. This has been demonstrated between the secured VAT from LBL and the secured RAT from UCL, and between the secured VIC from LBL and the secured VIC from UCL. There are also secured versions of the shared workspace tools WB and NTE.

6.2.3 Application-independent encryption

The above section shows clearly that built-in encryption relies on the tool developers. If for a particular tool, encryption is not built-in or is not built in a suitable way, we either have to wait for the developers to implement it or wait for the source code to become available and do it ourselves. The aim of application-independent encryption is to put a given tool or a set of tools, in a security shell without modifying the tool. This would also provide a possibility for user groups to install a security shell which they can choose and which they trust. Unfortunately, todayís media tools have usually been designed for, and are meshed with, a specific environment (e.g. ITU or Mbone conferencing, ISDN or RTP etc) and are thus hard to isolate. We therefore feel it is necessary to experiment with one or two alternatives in order to be able to evaluate and validate solutions to come.
We can look at a media tool as a device which transfers a certain payload and in addition requires control information to do the job. End-to-end encryption demands that the control information, which is needed to route information through the Internet and Mbone, must be readable by the routers. Thus, only the payload proper (audio, video, shared application data) can be encrypted. On principle, this can either be done at the user side or at the network side of the tools. We discuss here the latter only.
The tools communicate via sockets. Thus the socket interface may be used for application-independent encryption in the following way: Applications send their data to sockets which in the case of the Mbone are specified by a multicast or unicast address and a port number. Such an address/ port number is specified for each tool used in a conference. An encryption module could be inserted between each tool and its sockets, like a filter. The application gets a local address and port number to send the data to an encryption module, which encrypts the data and sends them out to the originally specified conference address. In the opposite direction, the encryption module receives data from remote partners, decrypts them and sends them to the local tool. Such a module will be implemented for experimental purposes by GMD. However it is important to ensure that the implementation would be portable across different platforms, and not require fundamental changes in the Operating Systems. It remains to be seen whether these goals are achievable.
For practical use, the security module must be made so that an application with a security module can interwork with an application with a built-in encryption.


Figure 3: Application independent security module

An advantage of application-independent encryption by separate module would be to allow change from one encryption method to another one merely by changing modules - and not the tools themselves. This approach is also in line with the basic concepts of SSL and GSS-API, to name just two examples. The Secure Sockets Layer Protocol (SSL) [ssl] is application-protocol independent, but requires applications using it to have the appropriate APIs to call it. It provides an RSA-based authentication protocol with symmetric encryption and is in use with Netscapeís WWW browser. Currently, it supports only privacy between two partners; moreover, RTP does not have an interface to SSL, and SSL is not used by any of the MERCI tools. It is not clear at what stage future versions will cover multicast and Mbone applications; but this will certainly be discussed in the context of IPSEC. The GSS-API [gss] defines an interface to authentication and confidentiality functions at a level independent of underlying mechanisms and protocol environments. A new version is currently being drafted in the IETF. Such an API would be very useful to have a broader choice of security mechanisms for encryption. The use of this technique with the Mbone tools would require, however, some significant changes in RTP and some of the tool interfaces, which are not envisaged currently.

Return to Table of Content

6.3 Conference Announcements and Invitations - The SDR Suite

6.3.1 Introduction

Irrespective of the means of securing the data streams adopted in Section 6.2, we have a need both to securely announce conferences in an appropriate way, and to distribute the means to decrypt the data of secured conferences in an appropriate manner. The subsequent sections describe ways of dealing with both of these issues. If the conference is to be encrypted, then the requisite encryption parameters for the tools must be passed in the Description Payload as described in Section 6.2.2; this is the Description Payload which will be discussed in the remainder of this section.
There are a number of security issues immediately evident from the overview of SDR given in Section 3.4. It is necessary to ensure the authenticity and integrity of the SDR announcement, it is necessary to ensure that only authorised persons modify Session Announcements, and it is necessary to provide facilities for announcing securely encrypted sessions - providing the relevant proposed conferees with the means to decrypt the data streams. The Session Announcements are made to announce to all potential conferees the existence of a conference. It has, however, another function - to try to minimise conflicts for Mbone resources by spreading out the number of simultaneous conferences.
The Session Invitation has a different, though related, purpose - namely to invite particular entities to participate. So far the entities have been mainly people; however, the concept is being extended to include Servers, which would record the session or might playout specific pre-recorded portions.
Thus there are a number of threats which we must try to address in the securing of the SDR tool, and some constraints. These include the following:

6.3.2 SAP and SIP Formats

6.3.2.1 Introduction

While the formats for SAP and SIP without security are well defined in the current Internet Drafts, those with security are still under discussion.
The authors of the drafts would ideally like to rely on the use of IPSEC, the secure IP, to take care of most of the security problems. Unfortunately the reality is that IPSEC is not yet ratified, that its key management aspects are not really defined, and that there are no clear ideas of how the Public Key infrastructure required for IPSEC will be constructed. For this reason, it is not an option to use IPSEC for secure conferencing in the near future, and we cannot shrug off the security aspects. Hence, we present here the current state of the Internet drafts, and propose ad hoc solutions for MERCI - knowing that these will have to be modified later.

6.3.2.2 The Current Format of SAP according to the IETF draft

To discuss the securing of Session Announcements properly, we must give more detail on the SAP format. This Section is based on the current drafts [sap] and [sdp], but there are still some changes that are bound to occur before the formats are finalised. At present the security aspects are envisaged as being detailed in a separate document; here we will both describe the present state, and suggest how we would like to see it evolve.
Two security considerations apply to SAP data packets; first there are concerns about the authentication of the announcements, second it is necessary to provide information about the media tools in a manner that maintains confidentiality from recipients not expected to participate in the conference. The need for authentication has been discussed in Section 6.3.1. It can be achieved by including an Authentication and Integrity Header in each announcement, which provides a signature of the announcement or invitation, signed with either the private key of the conference organiser, or the private group key of the conference group. By comparing the signatures computed with the cached (or discovered) public keys of the relevant Signatories, the authenticity of the announcement can be verified. If the Session Description Payload is encrypted, a bit in the Header so indicates. In that case, a further Security Parameter Security Header is added to the packet. The current SAP draft gives no details of the nature of this Session Description Payload encryption, and hence of the Parameter Security Header; this is still being discussed in the MMUSIC group. Because it is still under discussion, details of the Parameter Security Header are not given here.
SAP data packets have the format shown in figure 4:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1   MT  |E|P|   auth len    |        msg id hash            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         orig source                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                optional authentication header                 |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      optional timeout                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Parameter Security Header                     |
|                             ....                              |
+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
|                   optional random number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session Description payload                   |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4 The SAP data formats

The full description of the different fields is given in the SIP and SAP documents. Here we give only a broad description of the fields relevant for the discussion here:
MT: Message Type
One of the following:
0 Session directory announcement packet. The session description payload (SDP) is described in [sdp].
1 Session directory deletion packet. The payload is a single SDP line consisting of the origin field of the announcement to be deleted.
E - Encryption Bit
If the encryption bit is set, the Session Description payload of the SAP packet is encrypted, and two additional fields are added to the packet: Time-out and Random. The Time-out field is not encrypted, but the Random field is encrypted along with the Session Description payload.
Authentication Header
This contains a digital signature (encrypted cryptographic hash) of the Session Description payload (or expiry timestamp, and encrypted random field and Session Description payload if the payload is encrypted). It also contains the public key with which the authentication header can be checked, and information to identify the encryption algorithm and mode used.
Originating Source
This gives the IP address of the original source of the message.
Time-out
When the session payload is encrypted, and the session description is being relayed or announced via a proxy, the detailed timing fields in the SDP description are not available to the proxy as they are encrypted and the proxy is not trusted with the decryption key. Under such circumstances, SAP includes an additional 32-bit time-stamp field stating when the session should be timed out. This field is included after the authentication header, and the digital signature in the authentication header encompasses the time-out, so that a session cannot be maliciously deleted by modifying its time-out in an announcing proxy.
Parameter Security Header
The format of this header is not yet defined in the SAP draft, and is still under discussion. At its simplest it is a pair of 32 bit numbers; one is the source IP address, and one is a 32 bit DES Encryption Key Identifier. In this form, it is assumed that each authorised receiving site has previously received a cache of keys from the Source IP. An alternative, which is under consideration for the MERCI project, is that this might be a full PEM message. This would then include the DES Encryption Key, encrypted with the Public Group Key of the Conference Group; it would also include the Distinguished Name of the Conference, This information would be sufficient, if the Public Group Certificates are stored in a Directory; in case we assume that recipients might not have Directory access, it might also include the full Public Group Certificate. The IETF Working Group does not like this latter form, because it could make the SAP datagram too long. There has also been discussion about distributing the Public Group Certificates as separate Session Announcements to reduce the size of the SAP messages for the conferences themselves. We return to this question in the next subsection
Random
This field is only present when the payload is encrypted. It is encrypted along with the payload, and is used to perform the randomisation task normally performed by an initialisation vector in algorithms such as cipher-block chained DES. This 32 bit field should contain a genuinely random number. After decryption, this field is discarded.
Session Description Payload
This contains the Session Description Payload for the media tools, including information about the DES key(s) used to encrypt them, if secure conferences are being used.

6.3.2.3 SAP and SIP formats proposed for MERCI

In the SAP draft, it is assumed that some form of encryption information is contained in the Parameter Security Header, but the form will be specified in a later Internet Draft. This is clearly not adequate for MERCI purposes. We propose that the initial format used for Parameter Security Header have the form of Source IP and 32 bit DES Encryption Key identifier - with the keys themselves distributed out-of-band by a form of secure E-mail. We must agree with the ICE-TEL project which of the forms of secure E-mail they will be deploying will be used.
As a second step, we will have the Parameter Security Header use the same secure E-mail message format to send the Encryption Key - encrypted with the Public Group Key of the Conference Group. In this mode, we will assume that for MERCI purposes, access to an X.500 is available for the storing of the Public Keys, and that this Directory structure has been provided by the ICE-TEL project.
Here there are still some subtle unresolved issues, since we may define versions for MERCI purposes, but these will have to change when the official Internet drafts are agreed in the IETF. At first sight, it would seem clear that we can use exactly the same form of encryption information as in our favourite form of electronic mail. This is not the case, since we are much more restricted on message length; the authors of the drafts will work hard to ensure that a total announcement fits into one UDP packet of 1K Bytes.
As a result, in the second of our formats for the Parameter Security Header, will use the same procedure as PEM for the Encryption Information. A random Data Encryption Key (DEK) is generated, and an Interchange Key (IK) is used to encrypt the DEK by RSA, using the Public Group Key of the Conference Group. The Random Number in the SAP/SIP Header will be pre-pended to the Description Payload before DES encryption by DEK, and removed after decryption.

6.3.3 Authentication and Integrity of Session Announcements

In SAP the Authentication Header can be used for two purposes:

In some circumstances only verification is possible because a certificate signed by a mutually trusted person or authority is not available. However, under such circumstances, the session originator may still be authenticated to be the same as the session originator of previous sessions claiming to be from the same person. This may or may not be sufficient depending on the purpose of the session and the people involved. In Section 6.6, we discuss further the assumptions we are making for the purposes of the MERCI project.
Clearly the key given in the authentication header should not be trusted to belong to the session originator unless it has been separately authenticated by some other means, such as being certified by a trusted third party. Such certificates are not normally included in a SAP header because they take more space than can normally be afforded in an SAP packet, and such verification must therefore take place by some other mechanism. However, as certified public keys are normally cached locally, authentication of a particular key only has to take place once, rather than every time the session directory retransmits the announcement.

6.3.4 Confidentiality of Announcements

Confidential Announcements are made by encrypting the Session Description Payload. However there is still discussion in the IETF around whether (case 1) to use symmetric encryption of the payload, with a set of symmetric keys passed in a separate channel, or (case 2) to use asymmetric encryption of the payload, using a public group key and passing the private group key in a separate channel, or (case 3) to use hybrid encryption by encrypting a symmetric session key, using an asymmetric group key. In any case the encryption algorithm is not specified in the SAP packet - this is communicated to permitted receivers out-of-band along with the corresponding decryption key. In the first case a cache of keys is assumed for a series of conferences; in the second and third, one key only is needed for each group - but extra information, namely the public group key used, must be carried in each announcement.
For the moment in a SAP announcement, we will use as the asymmetric mechanisms of Section 6.3.2.3 For SAP announcements, the Interchange Key (IK) is the public group key associated with the group organiser of the conference. This requires that a private group key be associated with the conference series, and has been distributed by other means to all the allowable participants. It may be that at a later date we (and others in the MMUSIC group) will wish to distinguish between the group name of the conference and the Originating Source; in that case further information must be provided in the SAP/SIP Header on the additional source.
Clearly the notion of a shared group private key as part of a public key system is somewhat a contradiction in terms. It would have been possible to use private key identifiers instead, to keep session Announcements small in size. We will certainly experiment with this in MERCI, but expect to adopt the above mechanism to ease the problems of key interchange in the MERCI environment where some Public Key interchange infrastructure can be assumed from the ICE-TEL project.
By using the Public Key technology, and distributing the relevant private key by PEM [pem1-4], S/MIME [smime] or PGP [pgp] to each of the proposed conferees, we can maintain the security related information like validity and certification in the form of a certificate. Here we can use as a distribution medium SAP itself, E-mail or a Directory System.

6.3.5 Session Invitations

Session Announcement is somewhat different from Session Invitation. In the first there is a general announcement; in the second specific people are being invited. It is still possible to send a User Datagram, but now we expect a reply. Moreover for invitations, it would be possible to achieve similar functionality by sending an E-mail message - though in the current drafts [sip] and [sdp], a User Datagram is assumed, with reply. The two mechanisms achieve somewhat different purposes. The first would be used if one wishes to invite someone immediately; the second if the invitation is in advance. Moreover, both methods could be used also to request invitations to join a conference; the details of the formats to be used still require further work. Irrespective of what happens in the IETF, in MERCI we will experiment with both the UDP and the message formats. The format for such a message can be made identical to that of a SAP, except that there is a different message type. There may well be significant differences both in the way the information is passed, and in the actual form of the Parameter Security Header.
Confidentiality of Invitations
A restricted Conference Announcement goes to a group of people who collaborate in such a way that a decision is made in advance who may participate; this implies some out-of-band key information has been passed between the members of the group. For the Session Invitation, this exchange has not taken place. Hence either we must again have an out-of-band communication, or by some other means we must have been able to locate the public key of the proposed invitee.
For a SIP invitation, we will use again the mechanisms of Section 6.3.2.3. Now for IK we will use the public key of the person being invited. Thus only the invitee can decrypt the message. If the invitation is going to a group of people, by UDP, each is sent a separate UDP message. However, we may well organise a list expander, which prefaces each invitation Description Payload by the session key encrypted with the public key of that particular invitee. If we use E-mail for the invitation, then sending to a list will have just this effect in any case.
Integrity and Authentication of Invitation
It is not clear how important these are. However, it is normal in E-mail to perform an MD5 digest on the message as a Message Integrity Check (MIC), to encrypt it with the private key of the Sender, and to enclose it in the Encryption Information. Using one's own private key, one can decrypt the message, and construct a new MIC. By finding the public key of the sender (which can be included in the invitation), it is possible to decrypt the MIC sent and compare it with that computed. Thus it is possible to check both the integrity of the message and its authenticity.

Return to Table of Content

6.4 Multimedia Servers

It will be straightforward to extend the Mbone tools to the inclusion of multimedia servers. They are merely other participants of the conference, subscribing to the same multicast address/port. If the conferences are to be stored in the clear, it is necessary only to interface SDR to the Server Application module, and the same decryption can be carried out. We expect that, in practice, we will invite the server to participate by a Session Invitation rather than a Session Announcement, but this has not been decided yet.
If the conferences are to be stored encrypted, it is possible to just store the data streams without any decryption. In this case the only timing data available is the Received Time-stamps, but these are probably adequate to get reasonable play-out.
We intend to verify that there are no problems with these approaches. None have been discovered to date, but no implementation has yet started.

Return to Table of Content

6.5 Conference Announcements and Invitations - The E-mail Case

6.5.1 Introduction

There are two steps to get into a conference: (1) Announcing a conference and inviting conferees, and (2) entering a conference by starting the necessary multimedia tools. SDR covers both of them, as described in Section 6.3, and an E-mail solution would also have to cover both to be acceptable.
Traditionally the announcement of, and invitation for, conferences where people physically meet in some place has been done by letter mail and nowadays may be done by electronic mail. The same procedure is possible for multimedia teleconferences. The organiser of such a conference would inform participants by E-mail of the details of the scheduled conference, e.g. date and time, agenda, tools to be used, addresses and port numbers for each tool.
In case of a secure conference, when session key(s) are required for encrypting conference data, these are distributed to the participants in an E-mail, along with all the other announcement information. Of course, the session keys - as well as the other conference information - must be sent confidentially so that unauthorised users do not get a chance to acquire them. That means that the mailed announcement is encrypted so that only the intended participants are able to decrypt it. In addition, the receivers of the mail must be able to verify that its originator is authentic; so it provides means to authenticate the originator as well as the receivers.
Entering a conference should be as easy and safe as possible. What could be easier for someone who has been invited by E-mail than to accept the invitation by clicking in the mail. For this purpose, the mail carries an active element which the user has to hit and the conference is opened. The active element actually hides the technicalities needed to start the required conferencing tools and security functions.
Most of the requirements expressed for the SDR suite in Section 6.3.1 apply also for E-mail. It is necessary to ensure the authenticity and integrity of the of E-mail announcement, and it is necessary to provide facilities for announcing securely encrypted sessions - providing the relevant proposed conferees with the means to decrypt the data streams.

6.5.2 The Secure Conferencing User Agent

The Secure Conferencing User Agent (SCUA) [scua], is a mail tool offering the required functionality. It lets users create, announce, and open conferences in a secure manner. It is a feature of the SCUA, as in SDR, that it allows the sender to include specific conference information (like tools to be used, addresses, port numbers) in the mail in such a way that the receiver can directly open the conference from the mail, simply by clicking at it (so-called active mail). SCUA was developed by GMD, based on a prototype implemented for Project MICE; is has been advanced since, makes use of security functions provided by ICE-TEL, and will be available for MERCI as a tool for tests, utilisation and enhancements in accordance with experience and the state of technology.
SCUA is written in the programming languages C, C++, and TCL/TK. The message presentation protocol is in accordance with the MIME (Multipurpose Internet Mail Extensions) standard [mime2, mime1]. Mail delivery is based on Internet Mail, and the SENDMAIL [sendm] command is used for UNIX. This ensures optimum compatibility. SCUA handles regular mails like other mail tools; in addition it offers the possibility to exchange privacy enhanced mail, a feature which is not restricted to the announcement of conferences. The privacy protocol is currently implemented according to PEM [pem1 - pem4]. The approach corresponds to that of SDR (as described in Section 6.3.2.3) and the current state of ICE-TEL. For the moment, PEM is quite adequate as a security wrapper for messages, but it did not gain wide acceptance for professional E-mail systems, and more recent Internet standards may be a better choice. Issues of secure messaging are being dealt with in ICE-TEL and we will adopt solutions forthcoming from them. Thus, future E-mail implementations may have to support other platforms and use other mail formats, for example a secured MIME format, such as MOSS [moss] or S/MIME [smime].
The present version of SCUA uses the library functions of SecuDE for its security functions. This is a software package, available on the Internet, to provide security functions (e.g. generate asymmetric key pairs, support certification, generate and read PEM messages, etc.), used in ICE-TEL.
Confidentiality of Announcements
Confidential announcements are made by encrypting the mail body. For the moment, we use the same procedure as PEM. A random Data Encryption Key (DEK) is generated, and an Interchange Key (IK) is used to encrypt the DEK by RSA. The IK is the public key of the recipient. For a group of recipients, there are as many IKs as there are recipients. The sender of a secured announcement is strongly authenticated and the body of the E-mail is electronically signed.
Anybody taking part in this scenario is required to have a personal security environment (PSE) with an RSA key pair which is certified. Where these do not already exist (for other purposes) they have to be distributed to the allowable participants by some means in advance.
When a conference group prefers to use a group key instead of individual private keys, as discussed in Section 6.3.4, they are free to do so, as SCUA is transparent to these variants.
Conference Invitations
A session invitation has the purpose to invite a particular person to participate in a conference session which is either ongoing or is about to start. This session may or may not have been pre-announced. SIP provides a technique for this, which is discussed in Section 6.3.5. We can achieve similar effects with E-mail.
With E-mail, we always use an individual's E-mail address to call her/him. While SIP sends an invitation as a single UDP datagram, SCUA would send it by regular mail - possibly with high priority if priorities are supported by the mail services involved. A specific receipt confirmation is not implemented for this purpose; however some mail systems do offer the option on a general basis. The alerting option of mail systems may be used for ringing the called party. However, no means are provided for call progress signalling back to the caller.
For a confidential invitation we will use the same mechanisms as for confidential announcements. For IK we will use the public key of the person being invited. Thus only the invitee can decrypt the message. If the invitation is going to a group of people, each is sent a separate E-mail, or the group is sent a mail with a list of individual IKs.

6.5.3Assessment

Conferences may be pre-scheduled or ad hoc. In the first case, time, date, agenda, programme etc. are agreed by the participants in advance. Examples are seminars and MERCI project meetings. In the second case, meetings are arranged spontaneously and participants called together instantly. An example is a telephone call. E-mail is particularly well suited for the first case.
Features of the E-mail solution without security are:

The transport mechanism, the formats, the addresses and the standards for E-mail are common and widely used. In particular the following aspects are relevant here:

Addressing is a machine independent addressing of persons, so from which ever terminal a user starts her/his mail tool, s/he will be notified of a conference and may even be able to enter it. (Note that the H.320 world has machine addressing).

The transport mechanism is well established in most organisations. Conference announcements and invitations do not need any network or server resources in addition to those for regular mails. There are no additional firewall problems with conference calls.

The amount of information which can be sent by E-mail is not nearly as restricted as for 1kByte UDP datagrams.

The procedure goes along with other common applications. E-mail is sent to inform partners of a conference, in this case with additional details such as addresses, time, date and the used tools. It is convenient to start a conference right from the mail instead of starting another tool or starting the conference manually.

Conferencing and mail services are integrated into a single tool, instead of adding a new tool. No extra tool for conference management is needed. (Note that today, many Internet multicasts are two-way announced: by mail/ WWW and by SDR).

The use of the SCUA is not restricted to the Mbone environment; it is also usable to announce and start H.320 conferences.

With E-mail, partners can negotiate conference parameters rather than simply set them.

Security Issues:
The standards being developed for secured mail such as PEM, S/MIME, or MOSS are appropriate and directly applicable to conferencing. When conference announcement are hidden in encrypted mail, it is virtually impossible for unauthorised persons to discover that a conference was announced at all.
Authentication mechanisms and digital signatures within E-mail are particularly useful for inviting the public to restricted conferences, for example conferences where participants need to show a membership or Id card to enter, pay an entrance fee, or simply are limited in number.

Return to Table of Content

6.6 Key Distribution in MERCI

6.6.1 Public Key Availability in MERCI

SAP and SIP are not tied to any single authentication or confidentiality mechanism. Authentication Headers must be self-describing, but their precise format depends on the authentication mechanism. Confidentiality of Announcements and Invitations must have similar agreed mechanisms. At present the algorithms used for securing the media tools are limited to DES; this is merely an implementation decision, and could easily be changed - if all the tool developers made the necessary changes. There is less need for a similar limitation to the confidentiality algorithms in SAP or SIP, since these protocols still have a very small number of implementations.. There are requirements for key distribution to allow authenticated and confidential conference announcements and invitations in SDR; there is also a need for such key exchange to distribute the DES keys for secured media tools. If this second function is done inside SD, as proposed in Section 6.3.4, it is not necessary to distribute further session keys for each conference.
However in each case, it is necessary to have some mechanism to distribute some keys securely. For MERCI purposes, we will assume that we have a Public Key mechanism in place, which allows the establishment of a Private Security Environment, and hence the distribution of public/private key pairs. For the MERCI partners, and in fact for any partner even loosely associated with the FRAMEWORK IV Programme, we can rely on the ICE-TEL project to provide such key pairs. We will assume, therefore, that each participant in the MERCI secured conferencing suite has such a pair, and that the public key can be put into an X.500 Directory in the form of an X.509v3 certificate, if this is desired. Moreover, access to that Directory can be facilitated by either LDAP (the light-weight access protocol which has been standardised, and has been stated to be adopted by Microsoft and Netscape), or directly accessible by WWW browsers. Finally, some people might feel more comfortable if their certificates were available on a WWW page rather than a X.500 Directory, because that is their way of working.
Unfortunately, we cannot assume that all our participants want to use this particular infrastructure; several may have more ready access to the PGP suite of programmes, and already may have PGP certificates. This technology is more prevalent than any other single one at present, and there is no need for our security mechanisms to distinguish against it. We should be prepared therefore, that any MERCI participant should have either a X.509v3 or a PGP certificate, and be prepared to send certificates via one of the following mechanisms: E-mail, X.500 Directory or WWW. It is possible to store confidential information in Clear Text in X.500 Directories or in WWW pages, but this is not really advisable for large populations. For this reason, we assume that private keys can be distributed by E-Mail; certificates can be reliably held also in the Directories or the WWW.

6.6.2 Group Keys

We intend to provide private/public key pairs not only to individuals, but also to groups of individuals who regularly participate in conferences. For each such group, there is a group organiser, who is responsible for maintaining the group membership, and of distributing group keys. Every member of a group must request membership, providing a Certificate for the reception of the group keys. The group organiser must satisfy him/herself that the request is genuine - taking such precautions as are deemed appropriate by the group members. Their Certificates will then be cached by the group organiser - either it or its derived public key, may be distributed to the other members of the group if this is desired. It is possible that the set of certificates may be stored in a directory or WWW page.
Eventually we expect to have versions of SDR which have the full functionality of Section 6.3; in this case there is no other mechanism required. If the group organiser wishes not to send the symmetric keys inside SDR, they may send a set of them to the group secured with the private group key.
When a change in group key is desired, a new such key is sent to all members of the group by a secure E-mail (secured with the public key of the recipient).

Return to Table of Content

7. Bridging the ITU and Mbone Worlds

7.1 Summary of Security Features in the ITU- and the Mbone Worlds

The following tables summarise the security features in the ITU- and the Mbone world.
A) Confidentiality
Confidentiality for Multimedia Conferencing involves encryption mechanisms, session key exchange mechanisms and the corresponding protocols. Session keys can be exchanged before the conferencing session starts or within sessions. In the latter case, the synchronisation of session keys exchanges has to be considered.
In ITU terminals, the same session key is used for the encryption of all media streams (audio-, video-, data) whereas in the Mbone world, different keys may be used for different media types.

ITU-Terminals Mbone Tools
Encryption ConceptsLink Encryption,
End-to-end with prETS300xxx 		End-to-end Encryption
Supported Encryption AlgorithmsFEAL,
DES (OFB-8),
B-CRYPT (ISO/IEC 9979) 		DES (RAT, VAT, VIC)

(Others could be used)

Key Exchange before session startpre-arranged Pre-arranged, during Session Announcement or Session Invitation
Key exchange within sessionsISO 8732,
Diffie-Hellman,
RSA-based 		Can just change from a cache of keys, and try the next one
Protocols for Key ExchangeH.233 / H.234 / prETS300xxx SAP, SIP

Figure 5: Algorithms and Protocols for Confidentiality

B) Authentication

ITU-Terminals Mbone Tools
Authentication AlgorithmsRSA RSA
Key Sizenot defined Not defined, probably 1024
Authentication ProtocolH.234 (based on X.509) -
Certification Hierarchy3 levels:
AVSE (Audio Visual Service Ent.)
CCA (Country Certification Auth.)
GCA (General Certification Auth.) 		Not defined; will use ICE-TEL
Certificate FormatH.234 X.509v3 / PGP
Access to Certification Authoritynot defined not defined, various will be tried

Figure 6: Algorithms and Protocols for Authentication

C) Access Control

ITU-Terminals Mbone Tools
Protected EntityT.120 Conferences -
Access Control MechanismsPassword
(One-way hash, Authentication) 		Through secured distribution of session key, and encrypted announcements
Access Control ProtocolsT.124 -

Figure 7: Algorithms and Protocols for Access Control

D) Data Integrity

ITU-Terminals Mbone Tools
Protected Data-Session Announcements

Figure 8: Algorithms and Protocols for Data Integrity

E) Non-Repudiation

Not provided for ITU Terminals or Mbone Tools.

7.2 The MERCI Approach to Integrating the ITU and Mbone Worlds of Multimedia Conferencing

7.2.1 General

Interworking between the Mbone Tools and H.320/T.12x-compliant Desktop Multimedia Conferencing (DMC) terminals will be achieved by means of a Gateway (Mbone/H.320 Gateway).
When designing such a gateway, it is important to consider that Mbone and ITU style multimedia conferences have different characteristics:

It is the task of the gateway to mediate between both conference styles. Figure 9 illustrates the control and data flows between an ITU terminal, an Mbone terminals and the gateway. In this diagram, dotted fat lines depict protocols which allow Mbone terminals to actively establish connections to a remote site and perform conference control functions (such as invitation of other sites, creation of ITU conferences on an MCU, acting as a conference chairman etc.). Two protocols are involved in these activities:

SCCP is not supported by Mbone terminals yet, since it has currently only draft status. It is being further developed in WP 8 of the MERCI project. In this context the Session Controller, a tool which realises SCCP, will be developed and distributed just like other Mbone tools. The Session Controller will be installed on Mbone terminals in addition to the other Mbone tools (RAT, VIC, ...) and will locally co-operate with these.

Figure 9: Schematic of data and control flows in the H.320/Mbone Gateway
The following approaches to the development of the gateway are thus conceivable:

  1. The gateway could be designed in a manner in which it expects that Mbone terminals support SIP and SCCP. In this approach, the gateway would translate SIP / SCCP to the corresponding H.32x / T.120 functions. It would thus serve as a proxy for Mbone terminals to the ITU world.
  2. The gateway could be designed in a manner in which it expects that Mbone terminals support SIP but not SCCP. In this case, Mbone terminals would have the possibility to connect to the gateway but no further means to control conferences, exchange session keys within sessions, act as the conference chair etc. would be supported. Furthermore, a pre-defined mapping between ITU conferences and IP multicast addresses would have to be set up at the gateway in advance.
  3. The gateway could be designed in a manner in which it does not expect that Mbone terminals support SIP or SCCP. In this case, it would have to analyse the RTP traffic coming from Mbone terminals to trigger appropriate actions such as setting up and closing down virtual H.323 connections on behalf of Mbone terminals. Due to the fact that in this scenario no channel exists for the exchange of conference control information between the Mbone terminals and the gateway, the overall level of functionality in the conference is very limited.

The initial version of the development of the Mbone/ H.320 gateway follows the second approach, i.e. it will assume that Mbone terminals support SIP but not SCCP. Later versions of the gateway will provide more enhanced conference management functionality to those Mbone terminals which support SCCP. Later versions of the gateway will also consider the third approach and mixed approaches.
It should also be noted that the Mbone tools do not necessarily support the same media coding as H.320 terminals. For example, RAT supports redundant audio, which is not supported in H.320; RAT does not support the G.711 [itu-g711] which is standard for T.120. Similarly, there are video encodings supported in the one which are not necessarily supported in the other. There are two ways to resolve this problem. First an extra media translation module can be located in the gateway; this is already done in VAT relays. Secondly we can mandate that only certain encodings be used which exist in both communities; this is often done both in the Mbone and the ITU worlds.

7.2.2 Realisation of the Mbone/H.320 Gateway

The Mbone/H.320 Gateway is realised by means of separate components, namely

These components may later be integrated into a single Gateway. Figure 10 shows the involved components and their interrelations.

Figure 10: Control- and Data-flows in mixed Mbone / H.320 Conferences without Security

7.3 Security Functions in the Mbone/ H.320 Gateway

The Mbone/ H.320 Gateway will allow H.320 Terminals to join conferencing sessions with Mbone terminals. In this context, the following security functions will be supported:

The following additional functions can be supported if the Mbone terminals support SCCP:

Figure 11: Control- and Data Flows in secured mixed Mbone/H.320 Conferences

Security functions will be implemented at several stages and follow the general approach taken to the realisation of the gateway (i.e. approach (1) or (2) as described above). The developments will take into account the existing security facilities (encryption, key distribution, access control) supported by H.320 Terminals and the Mbone world.
Figure 11 illustrates the flow of data in secured mixed Mbone / H.320 conferences.

Return to Table of Content

8. Conclusion

In the earlier MICE project, we thought that security could be provided by slightly extending the Mbone tools, and sending keys to the partners by E-mail. Although we are still exploring this approach for a small scale experiment, the use of the Mbone tools is now so broad, and over such a large set of platforms, tools and environments, that this approach is no longer adequate. This report shows how broad a range of tools are now used in the Mbone environment, and how necessary it is to provide techniques that scale. Moreover, we can now make a set of assumptions which are quite different from those in the MICE days. Almost all users of the Mbone conferencing tools now use SDR, and a small set of media tools. They are quite prepared to take the latest version of these tools for conferencing - but are not normally prepared to change their E-mail systems. While we are trying, in this and other projects, to set up a Public Key infrastructure in Europe, this approach is slow to take root here. These considerations have influenced strongly the architecture developed here for secure Mbone conferencing. On the whole we have wished to modify the existing tools and mechanisms, and to make minimal additional demands.
In the ITU world, the considerations are quite different. Very considerable effort has gone into the development of Standards, and the needs of security have been considered from the beginning. However, there is a much larger number of players starting to provide implementations - and it is much more difficult to define smaller additional tools because they are needed as a result of experience. There is a large existing body of Standards, around X.500 Directories, X.500 and MCUs, which the ITU is quite prepared to mandate as needed. It is to be hoped that the ITU user community will subscribe to all these requirements for their conferencing, and that the infrastructure needed will be provided at reasonable cost.
In this report we have outlined the main security functionality required for conferencing, and developed a complete architecture that will be implemented for the Mbone world. This architecture has not been developed by the MERCI project in isolation; it is consistent with, and developed in partnership with, the IETF community. In order to describe the architecture, it has been necessary to define a number of mechanisms which more properly belong to other Work-packages like media tools (WP3), interworking (WP5) and Management & Control (WP8); it will have ramifications also for other work-packages like Servers (WP7) and Conference Rooms (WP8). This report has, of course, particular relevance to User Interfaces and Usability (WP4). It is with reference to this last that we must consider the implementations.
We have also described the secure architecture defined by the ITU world for conferencing, which is also being implemented for a set of workstations by one of our partners. Finally, we have considered how these two worlds can be inter-connected. We have shown that some functionality is achievable in any case; however, it may be difficult to achieve some of the functionality desired by each of the two worlds separately when they are combined. One example is strong access control; this is desired by the ITU community, but does not really exist in the Mbone one. There it is replaced by ensuring that the conference would be unintelligible to unauthorised participants. It would be possible to translate some of the procedures for strong authentication across the boundary between the worlds; but the mechanisms would break down if the operation of rogue workstations were deliberately falsified.
We are confident that the architecture presented here can and will work in the two worlds separately; we will endeavour to provide it to our users in a user-friendly way.

Return to Table of Content

REFERENCES

[des] National Bureau of Standards: "Data Encryption Standard" FIPS 46, Government Printing Office, Washington, 1977.

[etsi-xxx] Draft ETSI Standard prETS 300 xxx "Service Access Control and Synchronisation for Audio-visual Services", Sept. 1995.

[gss] Linn J.: "Generic Security Service Application Program Interface", RFC 1508, Sept. 1993.

[handley1] Handley, M.: "The use of Plain text keys for multimedia conferences", RN-95-19, Dept of Computer Science, UCL, March 1995. http://www.cs.ucl.ac.uk/research/rns/RN9519.ps

[icetel] http://www.darmstadt.gmd.de/ice-tel

[ipsec-arch] Atkinson, R.: "Security architecture for the Internet Protocol", draft-ietf-ipsec.arch-sec-00.txt, Cisco, June 1996

[ipsec-auth] Atkinson, R.: "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995.

[ipsec-esp] Metzger, P., P. Karn and WA Simpson: "The ESP DES-CBC Transform", draft-ietf-ipsec.esp-ses-cbc-04.txt, Cisco, June 1996

[itu-g711] ITU-T Recommendation G.711: Pulse Code Modulation (PCM) for Voice Frequencies; Aug. 1992

[itu-h221] ITU-T Recommendation H.221: Frame Structure for a 64 to 1920 Kbps channel in audio-visual teleservices; March 1993

[itu-h230] ITU-T Recommendation H.230: Frame Synchronous Control and Indication Signals for Audio-visual Systems; March 1993

[itu-h233] ITU-T Recommendation H.233: Confidentiality System for Audiovisual Services; July 1995

[itu-h234] ITU-T Recommendation H.234: Encryption Key Management and Authentication System for Audiovisual Services; Nov. 1994

[itu-h261] ITU-T Recommendation H.261: Video Codec for Audiovisual Connferences at p x 64 kbit/s; March 1993

[itu-h310] Draft ITU-T Recommendation H.310: Broadband Audiovisual Communication Systems and Terminals, June 1996

[itu-h320] ITU-T Recommendation H.320: Narrow-Band Visual Telephone Systems and Terminal Equipment; March 1993

[itu-h323] Draft ITU-T Recommendation H.323: Visual Telephone Systems and Terminal Equipment for Local Area Networks which provide a Non-Guaranteed Quality of Service; May 1996

[itu-h324] Draft ITU-T Recommendation H.324: Terminal for Low Bitrate Multimedia Communication, June 1996

[itu-t120] Draft ITU-T Recommendation T.120: Data Protocols for Multimedia Conferencing; Nov. 1995

[itu-t124] ITU-T Draft Recommendation T.124: Generic Conference Control for Audiovisual Terminals and Multi-point Control Units; August 1995

[itu-t126] ITU-T Recommendation T.126: Multi-point Still Image and Annotation Protocol; August 1995

[ivs] Turletti, T.: The INRIA Videoconferencing System (IVS), ConneXions - The Interoperability Report, Vol. 8, No 10, October 1994, pp. 20-24.

[mbone] Eriksson, H.: "The Multicast BackBone", Comm. ACM, August 1994, 37, 8, 54-60.

[md5] Rivest, R.: "The MD5 Message-Digest Algorithm", RFC 1321, MIT, April 1992.

[mime1] Borenstein, N., and N. Freed: "MIME (Multipurpose Internet Mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, September 1993.

[mime2] Galvin, J., Murphy, S., Crocker, S., and N. Freed: "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, TIS, September 1995.

[moss] Galvin, J and S. Murphy: MIME Object Security Services, RFC 1848, TIS, October 1995

[nte] Handley, M.: "Network Text Editor", URL:http://www.cs.ucl.ac.uk/mice/mice_home.html

[ntp] Mills, D.: "Network Time Protocol Version 3", RFC 1305, UDEL, March 1992.

[pem1] Linn, J.: "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.

[pem2] Kent, S.: "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, BBN, February 1993.

[pem3] Balenson, D.: "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, TIS, February 1993.

[pem4] Kaliski, B.: "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, RSA, February 1993.

[password] Kirstein, P and P Williams: "Piloting authentication and security services in the PASSWORD project", Computer Communications, 17, 7, 519-531, 1994.

[pgp] http://www.ifi.uio.no/pgp

[rat] Hardman, V.J., M.A. Sasse, A. Watson and M. Handley: "Reliable Audio for Use over the Internet", Proc INET'95, Internet Society, July 1995.

[rfcprop] Schulzrinne, H: RTP Profile for audio and video with minimal control, RFC1890, January 1996

[rtpprot] Schulzrinne, H., S. Casner and R. Fredrick: RTP: A Transport Protocol for Real-Time Applications, RFC1889, January 1996.

[sd] Jacobson, V. : "SD README file", LBL, March, 1993.

[sap] Handley, M.: "SAP: Session Announcement Protocol, draft-ietf-mmusic-sap-00.ps, UCL, June 1996

[sccp] Bormann, C., J. Ott, Ch. Reichert: Simple Conference Control Protocol. draft-ietf-mmusic-sccp-00.txt, June 1996.

[scua] Hinsch, E., A. Jaegemann, L. Wang: Experience with the Secure Conferencing User Agent: A Tool to Provide Secure Conferencing with Mbone Multimedia Conferencing Applications, Proc JENC7, Budapest, May 1996.

[sdp] Handley, M., V. Jacobson: "SDP: Session Description Protocol, draft-ietf-mmusic-sdp-02.ps, UCL, February 1996.

[sdr] Handley, M.: "Session Description Rendez-vous",

URL: ftp://cs.ucl.ac.uk/mice/videoconference/sdr/README

[sendm] Allman, E.: "SENDMAIL - An Internetwork Mail Router", U of California, Berkeley, 1993.

[shttp] Rescorla, E., A Schiffman: "The Secure Hypertext Transfer Protocol", ftp://nic.nordu.net/ internet-drafts/draft-ietf-wts-shttp-03.txt, July 1996.

[sip] Handley, M., E. Schooler: "SIP: Session Invitation Protocol", draft-ietf-mmusic-sip-01.ps, UCL, June 1996.

[smime] http://www.rsa.com/rsa/S-MIME/home.html

[ssl] Freier, A.O., P. Karlton and P.C. Kocher: "The SSL Protocol Version 3.0", draft-freier-ssl-version3-01-txt, Netscape, March 1996

[vat] Jacobson, V.: "VAT Manual Page", LBL, February 1992;

[vic] McCanne, S and V. Jacobson : VIC: A flexible framework for packet video, Proc. ACM Multimedia '95, November 1995.

[wb] Jacobson, V. : "WB README file", LBL, August, 1993.

Return to Table of Content