Notes from European Middleware Workshop (EMW2000)

19-20 June, 2000
Leiden, Netherlands

Draft Version 0.2 (RTF format)

Editors

Henk Eertink (Telematica Instituut)
Yuri Demchenko (TERENA)
EMW2000 Programme - http://www.terena.nl/middleware/emw2000/emw2000-prog.html

EMW2000 Participants - http://www.terena.nl/middleware/emw2000/participants.html

1. Introduction

The European Middleware Workshop (EWC2000) was the 2nd meeting devoted to working out the concept of middleware. The workshop was held on 19-20 June, 2000 in Leiden, Netherlands and attended by 43 participants (see list). It was organised by TERENA and the Telematica Instituut. Presentations, the list of attendees and other related information can be found at the EMW webpage at TERENA.

The EMW Programme covered the main topic of middleware research activity:

Panel at the workshop was devoted to discussion of the Middleware Research Agenda for building Middleware enabled networking infrastructure. Current notes are mostly based on the discussion during/on the EMW Panel.

2. Defining middleware and developing middleware enabled network concept

Notwithstanding the importance of definition middleware as emerging component of modern networking and following the experience of the first Middleware Workshop in December 1998, it was decided not to focus at the workshop on middleware definition but rather rise this question in after-workshop discussion.

However it appeared in some presentations and talks that middleware should be treated/regarded as intermediate component between network applications and network itself with its resources of different types (in context of application and content driven/enabled networks). Middleware provides integrated and differentiated (network) services for applications (application-to-application communication).

Middleware is often viewed as a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment. Recently published RFC2768 provides functional taxonomy of the middleware, some exemplary components of middleware are analyzed which however don't cover all possible middleware appearance.

Hence, middleware can be viewed as a set of resource-related functions (management, allocation, resolution, access management, etc.) that together form network infrastructure on which distributed applications can be realised. This is illustrated by middleware enabled communication model.

<Picture to be included.>

Middleware includes three main groups of generic services related to upper layer routing, resolution and management:

From the application point of view middleware is the networking components (resources and services) used by API to access networking resources and services. (Conceptually Middleware services in the network must be available on demand and in any combination.)
 

3. Building Middleware enabled networks - EMW Panel discussion

Workshop Panel discussion was focused on current main research areas related to (building) middleware enabled network infrastructure. The main topics of the discussion were:

3.1. Directories and PKI

The main topics related the Directories and PKI discussed:

PKI and Certificates are becoming important in building communities of interest. First such example takes place in US where certificates are very popular among medical community, in some cases they are treated as legal credentials. In connection with this two questions arise: a) Certificate profiles

There is a common interest in establishing common Certificate profile format and developing Certificate exchange framework. There are interesting works in Internet2 PKI Initiative and other projects:

It appeared in discussion that almost 75% of Dutch universities have adopted a common CP that based on RFC 2527 format. Many Universities in Germany have a common CP and there is a CP up for Spanish universities. However all these national realisations are described in different languages.

Therefore, it was decided to make the existing certification statements available, as well as the definitions of certificate profiles in different formats. Location and maintenance of the page to be decided later on.

There was also agreement that some type of open CA software would be most welcome. There was a general sense that we should seek consensus on a package and then enhance it as needed, but the process for deciding on a platform and the resources for enhancement were not clear.

The question arose whether do we need strong certification policy. There is not yet a common understanding of the level of trust that is required for specific types of certificates. However it was suggested that in case of Europe European level the Certificate policy should be weaker than at the country level to avoid substitution of national CA by European level CA.

b) Legal issues in respect to PKI deployment

Dispute resolution issues are quite important in building consistent PKI and CA. The main issue here in trying to resolve dispute before going to court. Given the dispute resolution is part of the overall problem it should be the part of contractual arrangement of the CA service. There was general consensus that it would be a good principle to state in the various policies that problems should be solved via a third-party arbiter, instead of brought to court.

In this prospect, the existing legal situations and government involvement in different countries with regard to CA and Certificate policy should be investigated.

c) Certificate chain discovery

There are a number of ways to build a public key infrastructure. It is commonly recognized that there will be no single hierarchical structure for public keys. Hence, cross-certification and bridged certificate authorities will become common practice. This issue has been discussed extensively at the workshop, because cross-certification could lead to problems with assurance (trust is not a transitive property!).

There is an interest in pursuing trust relationships between universities in different countries as a pilot implementation of the global PKI. Particular problem here is building trust chains (certificate discovery chains) between universities. It was pointed that validation of certificate path is more complex than validation of trust. The paradigm/problem is described as a Root CA vs Bridge CA. Already suggested CP comparison may be the first step.

Certificate path discovery should be cross-boarder and serve actual people mobility, e.g. in case of employment mobility.

d) PKI deployment and LDAP/Directory

EuroPKI at University in Torino is creating pilot European PKI service and attempting to be a root CA for NRN in Europe. It was suggested that it is essential for Europe to avoid unnecessary competition in providing European Root CA service. TERENA can help in advertising EuroPKI service.

It appeared that Directory infrastructure is very important for deployment of the PKI. The exemplary service should allow students of one University to send SMIME message to students of another university. Current implementations include saving person's certificate in LDAP directory (European practice), or using KERBEROS (authentication) trusted certificate services which is popular among US Universities.

It was announced that the main Directory related in PKI/CA deployment will be addressed in the new TERENA Task Force on LDAP Deployment (LDAP-D) issues which next meeting will be held on September 20, 2000 at TERENA offices in Amsterdam. Information about the first BoF meeting on LDAP-D on May 12, 2000 will be posted to the middleware list.

It was recommended that the next LDAP-D meeting should address some discussed common issues for LDAP and PKI:

However, such specific for PKI issue as CA cross-certification remains to be tackled separately.

e) Directory of directories and global name resolution - X.500 vs DC-naming

Early directories were based on the X.500 naming scheme. However, there is no infrastructure in place that can map a hierarchical X.500 name to an LDAP server that is able to resolve lookups for that name. For that purpose, the DC- naming scheme is currently being deployed, in which X.500 compatible names are matched onto DNS names. This allows implementers to re-use the DNS infrastructure for LDAP server lookup and to ensure uniqueness of directory names. Another benefit of DC-naming will be in easier CP path discovery.

In the US, most directories contain hard-coded references but move to dc-naming is everywhere. In Europe, NameFlow directory-service run by DANTE provides mapping of X.500 addresses to hostnames that serve these X.500 domains and provides LDIF files for the National LDAP services. This service can be used to build integrated solutions.

Current research issue here is the integration of X.500 Directories with DC-based directories.

It was also mentioned that LDAP-based Active Directory server in Windows 2000 has already default global DC naming what may create another important driving force in adopting dc-naming scheme.

Agreed action was to set up conference call between Ken Klingenstein of Internet2, Peter Valkenburg, NL and Peter Gietz, DE to discuss their views and interoperability issues. Suggested time is second week of August.

In the US a directory of directories is being established within Internet2, based on a single object class (EduPerson). Similar initiatives have also taken place in Europe, but failed due to cultural differences (no agreement on attributes has been reached).

During discussion it became clear that US developed EduPerson obviously will have different names for similar attributes and some different attributes as well However, it would appear that mapping between attributes should be tractable as long as the number of attributes and countries remains relatively small. This is also may be affected by strict EU privacy regulation.

Standardisation is a very important issue in establishing directories interoperability. One more step in LDAP/Directories interoperability is publishing new version of Internet Draft on LDAPv3 referrals by Roland Hedberg of Catalogix. Information about this draft to be sent to the middleware list, some other possible actions will be agreed later on.
 

3.2. Resource discovery, allocation and control

This discussion was focused on the generic problems of resource identification, discovery, allocation and authentication and access. Particular topics for discussion:

Resource discovery, allocation and control together with authentication, authorisation, accounting (AAA) are important issues from the application and user point of view.

Particular problems in resource discovery and access to be targeted:

Internationally, the developments of accounting and access control are being governed in the IETF AAA group, and the IRTF AAA-ARCH group (for more information see AAA-ARCH website). Both chairs (John Vollenbrecht of Merit and Cees De Laat of U. Utrecht) of the IRTF AAA group were present at the meeting. They pointed on the lack of academic research in AAA, and the focus of current IETF AAA work mostly on only mobile computing.

Currently developing AAA Architecture provides information about network resource access attributes including authentication attributes. However, it was noted that resource discovery is not the part of current AAAArch.

Current practice in building real access management system for library access demands instantaneous revocation of authentication process/procedure on request. Practical experience shows that current system may take up to 5 minutes for giving user access authorisation. In this respect, some principal changes to current access management system must be found. As a solution LDAP was proposed for storing attributes information.

Important implementation issue for general AAAArch is related to session identification in general and session ID granting/handling. Exemplary case is authentication in Portal access session. The question is whether Portal should push user ID/IP/private information downstream or not. The same problem is identified when AAA server needs to be changed.

John Vollenbrecht of Merit informed that there is a lot of talk what is the session in context of AAAArch. It is important how authorisation/authentication happens for further exchange of this information.

Common conclusion was to look further on session identification issues, some new ideas will be welcome.
 

3.3. Active networks

Active networking is a paradigm in which not only the data are exchanged between end-systems, but also an instruction on how the data must be manipulated, routed, or transcoded in intermediate systems, such as routers, or processed in destination systems.

Active networking is currently not deployed, except for laboratory situations. The resource management issues and security problems have not been completely understood yet.

Active network currently explore concept of trusted application/software environment like one used in workstation OS. There are some similarities but obviously active network components demand more strict security architecture. It was mentioned that there are many common problems in active network and computing grids.

People agreed that ongoing Internet evolution leads to development of the active network(ing) concept. Active networks need higher performance from networking components but this nether was an issues for long-term development. Application and resource oriented network control/management is going deeper into networking infrastructure. This is what we call middleware which lays between applications and transport network.

Example of such changes are new features of the recent version of Cisco IOS which is capable of per-packet switching.

New development at IETF on Blocks eXtensible Protocol Framework which creates generic application protocol framework for connection-oriented, asynchronous request/response interactions. The framework permits multiplexing of independent request/response streams over a single transport connection.

Active network is expected to be one of the main driving forces in focused development of the middleware concept. There is an intention to look into these problems in AAAArch IRTF WG.

The question was addressed to workshop audience whether CORBA is suitable protocol for Active Networks. The comment received explained that active network communication concept/model (can) use CORBA. (IETF also use CORBA concept in Policy framework, for negotiation attributes -???). CORBA features/components may be used in AAA API. CORBA is apparently suitable for GRID computing middleware.
 

4. Other topics discussed at the workshop

A number of other topics were discussed at the workshop in line with presentations and during breaks and personal meeting. Most of them are focussed on developing components of the middleware network infrastructure related to resource description and discovery, upper layer routing and active network management/control. Particular problems are listed below:

1) Resource description and discovery

Common framework for resource description is an important component of building information infrastructure. The foundation of this work is presented in the Resource Description Framework (RDF) which components are Metadata (common and specific) and DOM/XML (Document Object Model) which are being developed by W3C and related work of IETF.

Apparently, content oriented network needs support of specific services based on common middleware services: Directory, PKI, AAA, content negotiation, etc.

Issues presented at the workshop were related to the description of the multimedia information in the MPEG-7 and MPEG-21 framework. Discussion here was related to the compatibility of these formats with widely developed and gradually developed XML/RDF framework and other metadata formats like Dublin Core (DC).

2) Architecture for computational grids

Computational grid is a new application/realisation of the distributed networking computing. It actually needs support of the distributed network infrastructure for managing access and use of the computing resources. Part of these functions also can be given to generic middleware services.

Mentioned at the workshop projects are Globus introduces a set of middleware functions that together manage a grid of computing resources. Their primary objective is to support computations that involve massive amounts of data or computing resources. It is a cooperative effort of (mainly US) university researchers. See also the website of the Grid-forum, and the European Grid forum.

One of the main component of the distributed computing model is a CORBA which is also can be referred as a middleware component. Usage of CORBA is extending with developing general middleware concept.

CORBA apparently finds its implementation in dynamic brokerage of the resources for the QoS infrastructure and other policy based network architectures.

Given QoS management is a particular form of resource management, it means that the AAA-architectures can be reused in this domain.

3) Content delivery infrastructure

Content delivery infrastructure has wide implementation/deployment in current Internet infrastructure and apparently can be treated as middleware network component. It includes such traditional technologies as caching and replication and newer technologies like multicast and streaming which need some specific services to be inbound into network.

Multicast and streaming applications that currently are widely used need special infrastructure support to improve scalability, quality of service and bandwidth usage. Presented at the workshop VRVS global videoconferencing system uses distributed reflector system that helps solving scalability system.

Still remaining problem in streaming content delivery is in local replication/caching with relation to needed quality of services.
 

5. Workshop conclusion and agreed actions

Action EMW-001. To produce document on Research Agenda in middleware area to catalyse Academic community in starting researches in specific areas.

Action EMW-002. To produce list of active research groups and expression of interest in cooperation.

Action EMW-003. To establish special mailing list for after-workshop discussions (currently middleware@terena.nl).

Action EMW-004. To establish Middleware webpage at TERENA website with informational contribution from workshop participants (currently http://www.terena.nl/middleware/).

Action EMW-005. Information about BoF meeting on LDAP Deployment issues held at TERENA offices on May 12, 2000 in form of minutes to be posted by Peter.

Action EMW-006. Telephone conference between Ken Klingenstein and Peter Valkenburg with participation of other interesting parties on issues related to coordination between US and Europe in Directory/PKI and Certificate exchange format to be set up in early August.