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
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.
multimedia conferencing, security, MBONE, multicast, video, audio, shared workspace, RTP/2
Table of Content:
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
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.
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.
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:
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.
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.
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.
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
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.
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
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.
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.
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
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.
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.
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
Return to Table of Content
|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
|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)|
|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)|
|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)|
|the sender of this message responds to an authentication initiation and sends information needed for the authentication procedure.|
|Authentication Complete (RSA.P3)|
|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)|
|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
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:
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.
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:
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
Return to Table of Content
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.
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
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.
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
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:
While the formats for SAP and SIP without security are well defined
in the current Internet Drafts, those with security are still
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.
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 | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
This gives the IP address of the original source of the message.
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
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.
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.
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
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.
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 184.108.40.206 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.
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
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 220.127.116.11. 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
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
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
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.
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.
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
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.
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
The following tables summarise the security features in the ITU-
and the Mbone world.
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.
|Encryption Concepts||Link Encryption,|
End-to-end with prETS300xxx
|Supported Encryption Algorithms||FEAL,|
B-CRYPT (ISO/IEC 9979)
|DES (RAT, VAT, VIC)
(Others could be used)
|Key Exchange before session start||pre-arranged||Pre-arranged, during Session Announcement or Session Invitation|
|Key exchange within sessions||ISO 8732,|
|Can just change from a cache of keys, and try the next one|
|Protocols for Key Exchange||H.233 / H.234 / prETS300xxx||SAP, SIP|
Figure 5: Algorithms and Protocols for Confidentiality
|Key Size||not defined||Not defined, probably 1024|
|Authentication Protocol||H.234 (based on X.509)||-|
|Certification Hierarchy||3 levels:|
AVSE (Audio Visual Service Ent.)
CCA (Country Certification Auth.)
GCA (General Certification Auth.)
|Not defined; will use ICE-TEL|
|Certificate Format||H.234||X.509v3 / PGP|
|Access to Certification Authority||not defined||not defined, various will be tried|
Figure 6: Algorithms and Protocols for Authentication
C) Access Control
|Protected Entity||T.120 Conferences||-|
|Access Control Mechanisms||Password|
(One-way hash, Authentication)
|Through secured distribution of session key, and encrypted announcements|
|Access Control Protocols||T.124||-|
Figure 7: Algorithms and Protocols for Access Control
D) Data Integrity
|Protected Data||-||Session Announcements|
Figure 8: Algorithms and Protocols for Data Integrity
Not provided for ITU Terminals or Mbone Tools.
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
The following approaches to the development of the gateway are thus conceivable:
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.
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
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
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
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
[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
[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.
[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",
[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.
[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