PROJECT PROGRAMME

ICE-TEL - Interworking Public Key Certification Infrastructure for Europe
Project reference number 1005 (Research sector)

Commencement date: Dec 1st, 1995

TELEMATICS APPLICATIONS Programme		October 1st, 1995
	
	OVERVIEW OF ICE-TEL PROJECT
	
	Summary Information on the Project 

Project Number - Acronym - Title	
RE1005  -  ICE-TEL  -  Interworking Public Key Certification Infrastructure for Europe	
Lead sector 	Other sectors	Start	End 	Project Duration	
Research		Dec 1st, 1995	Nov 30th, 1997	24 months	

Total Cost (ECU)	EU - Contribution (ECU)	
3.261.500	1.699.500	

Project Objectives, Summary description and anticipated results:

The aim of the ICE-TEL project is to offer solutions to the problem of security on the Internet as used by industrial and academic research. This will be achieved by support for the usage of secured applications where users need to be certified, by providing a large scale public key certification infrastructure in a number of European countries and by providing all the necessary technology components which allow the deployment . In particular, the project will:
·	develop and deploy the necessary tools for both the provision of the security infrastructure and the support of users of the infrastructure for a variety of platforms (Unix, PC, Macintosh),
·	develop and deploy security toolkits which allow to integrate public key based security services into virtually any application, and which make use of the security infrastructure,
·	develop and deploy security enabled user services which immediately allow to use the certification infrastructure without further application integration, 
·	support the integration of security services into applications, and provide secure testbeds for applications.
Main validation of the applicability and usability of the tools will be in three selected applications as part of the project, and in other TELEMATICS APPLICATIONS-, ACTS- and ESPRIT-projects. The three selected applications are:
1.	Secure communication between administrations and electronic request and delivery of documents in the region of Torino, coordinated within the EU-sponsored “Information Society Network”,
2.	Secure communication between national Computer Emergency Response Teams (CERTs) and other distributed network support groups,
3.	Provision of a security enabled electronic Directory service for a large British research agency.
The project will take it's basis from existing security developments from earlier EU projects and with background technology from project partners and set up an initial certification infrastructure at the beginning of the project.

Major Validation sites:

Institution/
Organisations	City/Town
+ Postal Code	Region 2 . 	Country 3 . 	
Certification Authority-Providers and Users	DFN, (DE)
UKERNA, (UK) 		DE, UK and many European national research networks	
Computer Emergency Response Teams CERTs	DFN, (DE)
UKERNA, (UK) 		DE, UK and many European national research networks	
Regional Administrations	Torino, Barcelona	IT11, ES51	IT,ES	
DRA	Malvern (UK)	UK55	UK	

Other Characteristics of the Project:

	Users involved: Researchers, research students, communal and regional administration employees and clients, technical professionals.
	
	Technologies and/or approach used: Public key cryptography, symmetric cryptography, smartcard technology, broad spectrum of network technology, Internet and OSI communication technology (WWW, X.500 Directories, E-Mail).
	
	Expected benefits for the citizen: Unlimited information exchange, electronic transactions and telecooperation over open networks will impact everyone’s life in the future. Security technology to protect their assets and their privacy is vital.
	
	Expected benefits for the users of the application: Increased usage of telematics due to increased protection of electronic communication, privacy protection, protection of corporate networks and computers, secured communication in an open environment
	
	Expected benefits for the European Industries: There should be benefits from the User industries, in improving their productivity by use of the techniques pioneered in ICE-TEL;  it is also vital that the supplier industry get a better feel for the impact of the technology on their products. Finally, it is vital that the European industry develop their own standard security technology and products to avoid dependencies from  prevalent export regulations, particularly in the US.
	
	Contribution to EU-policies: It is the policy of the EU to promote the Information Society and adequate security and privacy protection is an important pre-requisite for this. 	

Coordinator:

Name of Institution/Organisation	City
+ Postal Code	Region	Country	Number of Employees on 1/1/1995	Turnover in 1994 (KECU)	
GMD - Forschungszentrum Informationstechnik GmbH
	Darmstadt,
64293	DE71	DE	1300	90.900	

Contact person from the Coordinating Contractor: 

Title, First Name, Name	Wolfgang Schneider	Address:	Dolivostr. 15, 64293 Darmstadt, DE	
Tel: 	+49 6151 869 700	Fax: 	+49 6151 869 785	
E-mail 1: 	schneider@gmd.de	E-mail 2:		

Other Contractors:

Participants Code3 	Name of Institution/Organisation	City
+ Postal Code	Region	Country	Number of Employees on 1/1/1995	Turnover in 1994 (KECU)	
C 2	University College London	London
WC1E 6BT	UK55	GB	5000	229.000	
C 3	ISODE Consortium Ltd.	London
TW9 1DT	UK55	GB	20	930	
C 4	Computer Security Technologies CST AB	Stockholm
16428	SE01	SE	4	150	
C 5	Software and Systems Engineering Ltd	Dublin	IE002	IE	80	5.800	
C 6	Intrasoft SA	Athens, 11525	GR3	GR	520	43.105	
C 7	IAIK,
Technische Universitaet Graz	Graz
8010	AT22	AT	12		
C 8	Politecnico di Torino	Torino
10129	IT11	IT	1000		
C 9	University of Salford	Salford
M5 4WT	UK82	GB	1500	130.000	
C 10	Danish Computing Centre for Research and Education	Copenhagen
2100	DK002	DK	130	14.000	
C 11	Uninett A/S	Trondheim
7002	n.a.	NO	12	5.000	
C 12	Instituto de Engenharia de Sistemas e Computadores	Lisboa
1000	PT13	PT	642	38.800	
C 13	Fundacao para o Desenvolvimento Dos Meios Nacionais de Calculo Cientifico	Lisboa
1799	PT13	PT	14	1.981	
C 14	Fundacio Catalana per a la Recerca	Barcelona
8010	ES51	ES	24	8.600	
C 15	Universitat Politecnica de Catalunya	Barcelona
8071	ES51	ES	3124	145.000	
C 16	Josef Stefan Insitute, University of Ljubljana	Ljubljana
61000	n.a.	SI	800	18.000	
C 17	Institute of Cybernetics	Tallinn
EE0026	n.a.	EE	120		

1.1.1	
1	RATIONALE OF THE PROJECT					

1.1	User needs to be addressed

It is obvious that many Telematics applications require security services based on public key encryption schemes. This can be clearly seen throughout the work programmes of all 4th framework programmes. Typical users who require security services in open networks are commercial companies and their clients who want to make business over open networks, administrations, public medical and social services for whom it is vital that only approved groups are able to participate in their operations, organisations for their external and internal network communication, and the European research community which is using intensively open communication networks and which needs secured e-mail, secured Directory access and secured file transfer. The rapidly growing use of the Internet for commercial purposes creates an evident need for secured versions of the World Wide Web.

There are also strong requirements for the protection of privacy, even for informal communication. Moreover, the identity of people who meet on the net is not obvious in that the people are only visible by names which may or may not be consistent with the real persons. It is a trivial studentsÕ exercise to forge userids.

The basic security requirements are 
·	mechanisms which prove the authenticity of communicating partners, 
·	mechanisms which protect the integrity of communication data, 
·	mechanisms which protect communication data from unauthorised access. 
	
Another essential security requirement for reliable business communication is non-repudiation of the origin and receipt of information, which can be derived from authentication and integrity mechanisms. Also availability of services relies on the responsibility of authentic persons.	
In an open network environment, security functions on the basis of public-key encryption and signature schemes are useless without operation of a widely distributed infrastructure of public key certification. This does not exist now.
ICE-TEL will build up a prototype network of certification authorities ("CA"). These CAs are interrelated by mutual certificates of their public-keys. The duty of a CA is to check the real binding of persons, their names, and their public keys. A CA certifies public-keys of their clients on the basis of the examination of these bindings. A client of any of these CAs will be able to securely communicate with any other client of any of these CAs, in that both communication partners can trust in the certified binding of their names and related pubic keys. There is no need to check public keys on another communication path (like the exchange of finger prints over the telephone or by exchange of business cards) before the secure communication act itself. This way, users can meet securely on the network before they have met elsewhere. This is needed for spontaneous cooperation in an open marketplace.
Moreover, ICE-TEL will equip the users with mail and Directory user agents with integrated security functions for digital signature and encryption of their communication data. ICE-TEL will also develop and distribute easy-to-use tools for users which allow them to communicate with their certification authorities. With these tools, users can easily maintain their encryption keys and related information, e.g., to retrieve certificates, certification paths, black lists, and all information needed to verify the public keys of other users. ICE-TEL will also equip certification authorities with management tools which allow them to maintain their information bases, to safely communicate with their clients and other certification authorities, and to exchange all information necessary for a responsible key management.
The most rapid growth of the Internet is coming from the use of the World Wide Web (WWW).  No exploration of the deployment of security technology could be considered credible if it did not also examine the requirements of the WWW.  In some ways WWW has been designed for complete openness rather than security;  there is, for example, no need for any log-in.  Nevertheless, it has become clear that several forms of security are required.  Amongst these are the following:
a)	The need to restrict access to specific WWW pages;
b)	The need to authenticate users who desire to make commercial transactions or access data on the WWW
c)	The need to bind commercial terms from one source (e.g. a supplier) to a user - and have the resulting transaction be confidential, all parties authenticated, and the resulting transaction be non-repudiable.
d)	The need to have non-repudiable pages from the WWW available to clients.
e)	The need to have the above facilities fully available in source form, to ensure that the security implications, and the strength of the algorithms used, can be verified.  It is unlikely that this criterion can be met from any US software or hardware.
One can further observe that the establishment of a worldwide public directory is progressing very slowly, if ever. The reason is that organisations are hesitant to connect their organisational directories to global directory infrastructures due to privacy concerns. Therefore, this project aims to develop a product named a Guardian DSA which will enable organisations which are concerned with privacy to connect to public directory infrastructures.  The Guardian DSA will provide a secure gateway to such public structures while supporting secure (confidential and authenticated) communications for users inside the organisation.
Security functions will be integrated into some important applications like communal administration, secure Directories for organisational administration, and computer emergency response teams (CERTs). These secure applications will be developed, deployed, and tested.

1.2	Market situation and prospects

The open networks are widely used, and the usage is even still increasing. However, there are no established security services such that privacy is not supported by existing communication services.
This keeps many communication forms from the network which require confidentiality such as contract discussion, professional consultancy, future organisational planning, etc.
Commercial business application is growing on the public networks, too.  However, due to the lack of established security services, business today is either restricted to closed, password-protected client groups, or abstinent from the network.
US industries have deployed some RSA-based applications on the Internet. This is even visible in the World Wide Web, such as “Secure Netscape” in cooperation with RSA Inc. However, this technology underlies the strictest US export restriction. As a result, only harmless sub-versions of these programs are available outside of the US, e.g. with key-lengths less than 40 bits for symmetric encryption.
Therefore, European implementations of security mechanisms and their integration in user tools and application environments is highly necessary if the European market wants to participate in the advantages of security services for open networks.
There is no technical global support for privacy, authentication, or integrity on our networks, which keeps serious parts of public and commercial communication from using the networks. There is no way to simply import US technology, whereby there is no established security infrastructure in the US, either.
With ICE-TEL technology, Europe has the chance to establish a global support for privacy, authentication, and integrity on our networks. This will draw serious communication including commercial applications on the networks in Europe.
There are currently several international development projects in the area of certification system and generalised security infrastructure. Most of them are in the USA and some in Europe. However, to the best of our knowledge, there is no fully operational and commercial certification infrastructure established yet in any part of the world.
Two important market actors in this area in the USA are companies RSA Data Security Inc. and Trusted Information Systems (TIS). RSA claims  that  they  are providing commercial certification system, based on  a  hardware  box called  SafeKeeper  (produced by BBN), but  there are no operational users of that systems yet. TIS, within its PEM project, has also produced the certification system, which is not running commercially, but it  is available for installation in the USA.
Both companies have issued their Low Assurance Certification Policies, and the offered  services, presumably, support these policies. Recently, US Post has also expressed the interest and plans to provide certification services in the USA.
In  Europe, several network operators (France Telecom, Telia in Sweden, etc.) declared at various occasions that they  are planning  to offer the commercial certification system in their respective countries.  To the best of our knowledge no such system is fully operational yet.
This all shows that  the plans and ambitions of the ICE-TEL consortium are aligned with current trends and  plans  in many countries. Further, COST is already running the commercial certification system, and has also published  its certification security policy.
Another important component of the certification system, especially for the higher level assurance certification policies, are digital signature smart cards. They must be used by certification authorities to sign certificates and also by users to sign electronic documents. The only three international smart cards manufacturers today are European companies (Philips, Siemens and BULL) and COST has already developed smart card drivers and  smart cards applications based on these technologies.
1.3	Knowledge of Sector and technologies to be used

Many of the technology pieces used in ICE-TEL are already available as a result of the European PASSWORD project. The SecuDE security toolkit, which includes integrated and secured X.500 Directory access, various tools for key management and certification provision, and a RFC 142x PEM implementation, will be made available at no cost to the participants and users of the project. This includes the availability of smartcard technology integrated into SecuDE. We will include the FORTEZZA card in our work - its availability could be constrained by relevant government regulations
OSISEC and any other tools produced by UCL will be made available at no charge to any collaborators in the ICE-TEL project - and to any CEC projects linked to this project.
The ISODE Consortium is a supplier of source technology for open Messaging, Directory and Security Services. All of this release, including security toolkits, is being made available to the project as background software. The toolkits will be used in various parts of the project, and other components such as the X.400 MTA will be used in the project piloting.
We may use commercial products (like C-WAIS) if the functionality is in considerable advance of the PD versions.  We have to consider the availability of such software on a case by case basis with the supplier.  We will endeavour to have the software made available on very reasonable terms if this occurs.  We will try to ensure that there is a PD version - albeit with less functionality - if this can be achieved with reasonable effort.
The 1988 Directory standard [1-9] provided an authentication framework that utilised both weak (i.e.: password based) and strong (i.e.: digital signature based) authentication mechanisms. As products and research projects start to use these mechanisms, and as different commercial sectors such as banking and airlines seek to apply X.509 strong authentication mechanisms in their sector, enhancements to the basic scheme are being designed. Consequently, current work inside the joint ISO/ITU-T Directory Standardisation Group is focusing on extensions to the security aspects of the Directory, so that function-specific extensions to the basic mechanisms can be applied in a standard conforming way.
Existing strong authentication toolkits e.g. SecuDE and OSISEC are based on the 1988 X.509 standard [8]. It is expected that the ICE-TEL project will incorporate some of these new extensions into the toolkits and into the Guardian DSA.  In parallel with this, consortium members are already independently implementing the 1993 list-based access control scheme. Members of the consortium currently participate in relevant ISO/ITU-T committees, and this project will enable some of that work to continue.
The World Wide Web (WWW) is a distributed hypermedia system that has been gaining acceptance most rapidly of all internet-services so far. Currently, the amount of data transferred via HTTP, the protocol used for transferring data in the WWW, exceeds the amount transferred by file-transfer, the ãleaderÒ so far. The ease of use has resulted in a widespread interest as a basis for client-server-type applications. Many of these applications require the possibility of confidential data-transfer between mutually authenticated clients and servers. Examples are warehouse-type ordering systems or information distribution on a subscription basis. Current HTTP-Software has no or only rudimentary support for security.
Two approaches to enhance the security of WWW have been discussed: Secure Socket Layer (SSL) and Secure HyperText Transfer Protocol (SHTTP). SSL provides for a protocol-independent means to securely exchange information between two applications. That means that an application can use protocols like Telnet, Ftp or HTTP in a secure way but more or less transparent to the application. 
SHTTP provides for secure communication mechanisms between a HTTP client-server-pair in order to enable spontaneous commercial transactions for a wide range of applications (drawing on the approaches and philosophies of PEM and MIME efforts). The design intent is to provide a flexible protocol that supports multiple operation modes, key management mechanisms, trust models, cryptographic algorithms and encapsulation formats.
Both SSL and SHTTP are currently defined in draft documents; there is a good chance that they will become internet standards soon. 
Application Programmer Interfaces (APIs) are currently being developed for various levels of security functionality in the IETF and ISO. Most important in the context of ICE-TEL are the high level GSSAPI (Generic Security Service API) which defines an interface to authentication and confidentiality functions, PKCS-11 which defines an interface to cryptographic functionality, and ISO SC17 which defines smartcard commands and access protocols. For GSSAPI, detailed specifications are under way for Kerberos-like and Public Key security mechanisms.

1.4	Technical aspects of the Demonstrator

The demonstrator to be developed within ICE-TEL will consists of a number of components both for the provision of the public key infrastructure and for its users. It is vital to have the security infrastructure itself in place, and to provide the tools for users which enable them to use this infrastructure.
The demonstrator will incorporate the relevant internet technology (WorldWideWeb, secure HTTP, Privacy Enhanced Mail (PEM) and secured MIME (MOSS, S/MIME), PKCS) and OSI technology (X.500), and will make use of established cryptography (RSA, DSS, DES, IDEA). The demonstrator will be available for Unix, PC (Windows95, Windows-NT, OS/2) and MacIntosh Platforms. Not necessarily will all components be available on all platforms, but it is anticipated that for each type of functionality at least one component is available for each platform. The demonstrator will consist of
1.	Security toolkits which allow to integrate public key based security services into virtually all applications. The toolkits will allow to use specialised hardware, e.g. smartcards, to securely store and process the sensitive security information objects, e.g. private keys, trusted public keys of communication partners and top-level public verification keys. The toolkits will provide standardised security APIs on various levels, as for example GSSAPI on the level of authentication and confidentiality functions and ISO SC17 standards on the level of smartcard access, in order to achieve a maximum  portability of components and interworking capabilties between components. We intend to have most of the functionality of the toolkits available on various Unix-, PC and MacIntosh platforms. In particular, the OSISEC toolkit will be available on Unix platforms; the SecuDE toolkit will be available on Unix, PC (Windows95, Windows-NT, OS/2) and MacIntosh platforms; the SESAME toolkit will be available on Unix and PC (Windows 3.1, Windows95, Windows-NT) platforms; the security toolkit of IC will be available on Unix platforms, and the availability for PC platforms is anticipated; the COST security toolkit will be available on PC platforms (Windows 3.1, Windows95, Windows-NT).
2.	Tools for the provision of certification authorities which will allow users to link to the global certification structure. These tools will include smartcard management systems. These tools will be available on Unix and PC platforms, depending on the underlying security toolkit.
3.	Tools for secured document exchange on the basis of PEM, MOSS and X.400 Security, integrated into various mail UAs. These tools will be available on Unix, PC and MacIntosh platforms, depending on the underlying security toolkit.
4.	Tools for the secure provision of directory services. Directory services are both part of the security infrastructure and users of the security infrastructure (for the protection of the directory information base and the directory communications). This will be available for Unix platforms.
5.	A so called Guardian DSA which will allow organisations to firewall their private directory domain when linking to the global directory system. The Guardian DSA will be available on Unix platforms.
6.	HTTP a S-HTTP capable client and a S-HTTP capable server software. This will be conformant to the HTTP and S-HTTP-Standards respectively. In detail, it will support handling of  HTML messages according to the de-facto-standards imposed by current HTML-viewers, signing messages, encrypting messages, mutual authentication of servers and clients, and ensuring freshness of information. The S-HTTP capable client and server software will be available for Unix platforms. We will investigate the possibility of having an S-HTTP capable client for PC platforms.
An important aspect of the demonstrator will be that all its components from all industrial partners and UCL and GMD will be able to interwork on the basis of the common security infrastructure.
2	
OVERALL DESCRIPTION OF THE PROJECT
	
2.1	Objectives of the Project
The aim of the ICE-TEL project is to provide a large scale public key certification infrastructure in a number of European countries for the use of public key based security services, and to provide all technology components which allow the deployment of user tools and applications with a common integrated public key security technology. In particular, we will
•	develop and deploy the necessary tools for both the provision of the infrastructure and the support of users of the infrastructure on the basis of existing tools (for instance through the VALUE II PASSWORD project) for a variety of platforms (Unix, PC, Mac), for instance the necessary CA tools, tools for the secured X.500 Directory infrastructure and secured WWW tools,
•	develop and deploy security toolkits which allow to integrate public key based security services into virtually any application, and which make use of the security infrastructure,
•	develop and deploy user tools (secured e-mail, secured WWW clients, secured X.500 DUAs) which immediately allow to use the certification infrastructure without further application integration, 
•	to provide public key certification services in a number of countries and to provide national security support centres in a number of countries, 
•	support the integration of security services into applications, and provide secure testbeds for applications.
Main validation of the applicability and usability of the tools will be in three selected applications as part of the project, and in other Telematics-, ACTS- and ESPRIT-projects, such as E2S, SEMPER, DESIRE, MERCI, DEDICA and WEB4GROUPS. The three selected applications are:
1.	Secure communication between administrations and electronic request and delivery of documents in the region of Torino, coordinated within the EU-sponsored “Regional Information Society Initiative”,
2.	Secure communication between national Computer Emergency Response Teams (CERTs) and other distributed network support groups,
3.	Provision of a firewalled X.500 Directory service for a large British research agency.
We will start with existing security technology from earlier EU projects (PASSWORD, SESAME) and with background technology from project partners and set up an initial PK certification infrastructure at the begin of the project.

2.2	Methodology of the Project

2.2.1	Overall Approach
The project will not start from zero. The components will be largely derived from the results of  the previous VALUE PASSWORD project and the RACE SESAME project, and from background technology provided by IC and COST. The security technology in IC R3 is partly derived from previous OSISEC and SecuDE software.
The main improvements being made over the available tools are the following:
•	Better integration into user agents, and therefore more easily used by untrained users;
•	better security through integration of smartcard and PCMCIA technology;
•	better functionality for the operation of CAs and for a  serious provision of certification services,
•	Provision of WWW-components with integrated Public Key based security;
•	Provision of security for MIME which is a basis for multi-media communication in the internet;
•	Provision of improved X.500 directory components based on the most recent standard;
•	Multiple-platform support for UNIX workstations, PCs and MACs;

The project is broadly divided into 
•	specification (WP3), 
•	development of technical components (foreground technology) on the basis of the existing background technology (WP4 - WP10)
•	validation of the results (WP11 - WP13).
An exception from the scheme above is WP7 (Guardian DSA development) which comprises both the building of the technical demonstrator and validation.
There will be validation activities pursued both inside the project and outside in other EU projects:
•	Provision of certification services in a number of European countries for the R&D sector within WP11;
•	Support of various CERTs (Computer Emergency Response Teams) with secured components for their communication in WP12;
•	Security support for the application of internet technology in the public administration of the region of Piemonte within the EU-sponsored “Regional Information Society Initiative” in WP13;
•	Validation of the Guardian DSA component at the British Defense Research Agency (DRA) in Halstead.
•	Use by MERCI, E2S, SEMPER, DESIRE, WEB4GROUPS and DEDICA.
	
2.2.2	Operational Steps
1.	We will start with a very early delivery of the components available from the background technology of the partners. We will deliver these components to the partners of WP11 (Certification Services Provision) and WP12 (Security support of the CERTs) not later than month 3 of the project. This will allow most of the validation work to be done over almost the entire  project lifetime.
2.	From the beginning of the project, we will continously develop the additional functionality in WP4 - WP10 for MIME security, database security, X.500 components, WWW components, CA tools and multiplatform support. We plan to have three major deliverables of ICE-TEL S/W packages, each combining the results of the technical work packages WP4 - WP10 and input of all development partners into a single deliverable. The major ICE-TEL software deliverables will be ICE-TEL S/W I in month 9, ICE-TEL S/W II in month 15, and ICE-TEL S/W III in month 21.
3.	From month 6 on, integration of ICE-TEL tools for the use within the Torino initiative will be done (WP13), and validation of this part of the software will start in month 9.
4.	Following our major software deliverables, we will produce user feedback reports in the validation work packages which then feed back into the development process. In addition, requirements from other EU projects as result from WP2 will feed back into the development process.
5.	We will have a final software deliverable ICE-TEL S/W IV in month 24 which will not provide any new functional features over ICE-TEL S/W III. This will only integrate the latest user feedback.

2.3	Phases of the Project
This work previous to this project spans already spans all phases:  Analysis of user requirements (Phase 1), Definition of functional phases (Phase 2), Building of a demonstrator (Phase 3), Validation - including some verification - Phase 4a, but not really demonstration in the way used by the EU (Phase 4b). Analysis of user requirements has been done already by all of the partners in ICE-TEL who are providing technology to the project, for instance in the PASSWORD project where some of the partners already collaborated. Nevertheless, under ICE-TEL we will do some work again in all phases. Some of the component development in the project will start in phase 2 (definition of functional specifications), other will start in phase 3 (building of a demonstrator). By far the largest portion of the project will be phase 3 and 4. The purpose of the ICE-TEL project is to help development the tools so that they are available to other applications;  a major activity after the present proposals have been awarded will be to assess the real needs of such projects, which have stated that they want to use ICE-TEL tools, to see what they really need.  Inside this project, we will only go to Phase 4a over the two years proposed - though we expect also to go to Phase 5 of exploitation.  The reason is that we regard that our main Demonstrators will be other projects which capitalise on the facilities being developed in ICE-TEL.  However to retain a clear assessment of the success of the technology, we have put in the three verification activities of WP11-WP13.
2.4	Dependencies
Some project partners are already involved with other projects related to the ICE-TEL technology;  some are national in scope, some are European, some transatlantic. GMD is involved in the E2S (ESPRIT), MERCI (TELEMATICS), SEMPER (ACTS) and DEDICA(TELEMATICS) projects projects. UCL is leading the MERCI project. UPC is involved in the DEDICA project. In all these projects security technology is needed and expected to come from ICE-TEL. At the national level, GMD is involved in the establishment of a German national certification infrastructure for R&D which is funded by DFN. We expect to collaborate fully with other related technology projects, and to make our tools available to their applications. We welcome the concertation mechanism being proposed for the Telematics programme, and will collaborate fully with it and with the SCIMITAR project.  We hope that an early meeting of all such projects will work out methods of co-operation - to avoid any  risk of non-interworking of the resulting tools. The consortium agrees to co-operate with other projects in the TELEMATICS APPLICATIONS Programme within reasonable use of resources and to exchange non-confidential information with these projects. Especially the consortia agree to co-operate actively with Support Actions Projects contracted to arrange concertation and dissemination activities and to provide information requested by Support Action Projects contracted to perform social and economic impact studies.
There will be other dependencies, for instance with the IETF process and the ITU process. Many of the technical features we plan to provide for MIME security, WWW security and X.500 improvements are still under discussion in the IETF and ITU or have a draft status. In the area of APIs, a new version of GSSAPI is currently being drafted in the IETF. In general, security API issues for different levels of functionality are heavily being discussed at various places, e.g. in the IETF, X/OPEN, PKCS, and the European/North American project ICE (International Cryptographic Initiative). In the course of the project, we will have to consider carefully all these activities and to participate in these processes where necessary and possible. The MOSS specification for integration of security into MIME has been put on the internet standards track recently. Yet we cannot say that this specification is stable. The functionality of X.509v3 certificates is being heavily discussed in the moment. We will have to see which functionality of these emerges as fairly stable during the course of the project. In the field of WWW security, drafts for S-HTTP and Secure Socket Layer (SSL) are on the table, and we will need intensive discussion with relevant groups, for instance the WWW Consortium, to proceed in WP9. Trusted hardware integration (smartcards) is another area where standards are needed which are being produced right now (ISO SC17). 

2.5	Expected Results/ Exploitation of Results Plan
Academic research networks in Germany (DFN), UK (Ukerna) and the Netherlands (Surfnet) have committed or expressed their intention to provide a public key certification infrastructure on a long term regular basis. They also started to establish Computer Emergency Response Teams (CERTs). All of them are expecting to use technology available from the ICE-TEL project.
In Germany, the TeleTrusT Association of industrial companies working in the area of security technology, and the German Telekom, have started projects which aim at the provision of Trust Centres on a commercial basis. GMD is project leader of the TeleTrusT project. Technology developed in ICE-TEL will be a core of these trust centres. Another project in Germany aims at the introduction of professional health smartcards with signature functions on the basis of RSA chips. GMD is involved here, too, and expects to use ICE-TEL technology here.
GMD is a member of the European Consortium of Informatics and Mathematics (ERCIM), which has partners in 13 European countries, including Scandinavia and Central/Eastern Europe.  Most are independent Research and Development laboratories, with strong links to local industry.  ERCIM partners have generated over 100 spin-off companies and do joint developments with SMEs.  GMD can use its ERCIM partners to establish exploitation paths in those countries not directly covered by the Project partners.
The SSE dissemination strategy for the ICE-TEL project is straightforward. Technology which is developed  under the auspices of the ICE-TEL project will be incorporating into existing products or will form the basis of new product developments. Use in existing products will help to maintain and expand market position both in Europe and further afield. SSE have a long history of levering research technology in product development and have developed a strategy to optimise the engineering effort in this area. 
Evolution of ICE-TEL technologies on users' desktops is a complex procedure. Product suppliers such as SSE must also be able to supply the support services to client organisations which will enable them to deploy and exploit the supplied products to an optimal level. Projects such as ICE-TEL develop expertise in this area and co-operation amongst partners in technology deployment serve as excellent training grounds for the commercial arena.
SSE specialises in developing and marketing products and offering  consultancy services in areas such as Open Systems, Networking, Telecommunications, Security and Multimedia.  Open System products include Office Systems, Remote Database Access, Electronic Mail, Directory Services and Electronic Data Interchange among others.  As part of the RACE SESAME project, SSE played a major role in the development of the Security tools.  The EMMA Multimedia Mail service was produced as a result of work undertaken in the RACE EuroBridge project.  Commercial versions of these results are now under development.  
As in the past, SSE will endeavour to commercially exploit the work they undertake within ICE-TEL.  It is anticipated that participation in the ICE-TEL project will allow us to strengthen our knowledge and understanding of evolving secure messaging technologies and certification  issues and techniques.  In so doing, it will allow us to explore new business opportunities in these areas.  It is essential that technology companies like ourselves keep abreast of technological developments and adopt and apply standards where they are appropriate.  Furthermore, we will endeavour to contribute to the establishment of standards by submitting results, where they are appropriate, to the relevant standards committees.
COST is planning within this project to utilise the results of previous development and to improve these results with new features and capabilities. All these results are already today operational products and COST is planning  to establish the full, functional, flexible and fully commercial certification and smart cards international infrastructure.  
There will be three types of certification  systems, distinguished by the level of  assurance  offered:   low assurance  certification  will  be offered to residential users, anonymous users, as well as to  organisational  users who want to run their security-enhanced applications on that level of trust.  Medium level assurance will be offered only to organisational users (companies and business organisations), with  lower  fees and operational rates. Finally, the high level assurance certification system will also be offered for high value transactions and operations.
Following the model from the USA, where certification hierarchy is envisaged as the commercial network value added service, COST will establish two top level PCAs  for each level of assurance: one PCA for Europe and one for the USA for low, medium and high assurance policies. They will all be  linked to the IPRA. In addition, in each European country COST is planning to provide support to the National Security (Certification) Support Centres, by supplying software and guidelines for establishing and running national certification servers.
Below National Certification Centres there will be regional or urban CAs and they will certify top level corporation CAs (internal CAs in the companies). For all of them COST is also planning to provide technologies and guidelines.
In each country, under the national Certification Centre, COST is planning to run one (or more) CAs for residential users,  in  cooperation with national authorities (post, police, registration, tax office, etc.).
Finally, in situations and for users where necessary, COST is also planning  to offer Trusted Third Parties (TTPs) services with the functionality extended  from  simple certification services.
All functions, software modules, services, operations, assistance and support is planned as the fully commercial system. 
The ISODE Consortium is a technology transfer organisation, working in the area of messaging, directory and security.  The ISODE Consortium supplies source technology to all of its members.  There are currently 83 members and 50 licensees (Universities that have access to the ISODE Consortium technology at zero cost).  The ISODE Consortium Membership falls into two broad categories.
1.	Organisations that have an internal requirement for the ISODE Consortium source technology.  These include research organisations, government organisations, and commercial service providers.
2.	OEMs, who are commercial organisations basing products on the ISODE Consortium technology.  There are 22 such organisation, eleven of which advertise products based on ISODE Consortium technology in the ISODE Consortium Member Product Catalogue.  These products are the primary means of getting the ISODE Consortium technology to market.
The original ISODE Consortium technology was developed in the research community.  In particular, the original QUIPU DSA was developed under Esprit project INCA.  The ISODE Consortium was formed as a technology transfer organisation in order to bring this technology to market.  Products based on its technology are deployed world-wide, and are clear evidence of the success of the ISODE Consortium’s approach.  A key feature of the ISODE Consortium approach is that it makes its technology available in source form to the research community in three ways:
1.	Low cost membership for research organisations and research projects.
2.	Zero cost licensing for universities.
3.	Participation in projects such as ICE-TEL.
By making the technology available in source form, the ISODE Consortium facilitates research based on its technology, in a much more powerful manner than would be possible for binary only distribution.  This research linkage also enables the ISODE Consortium’s role in the ongoing transfer of research technology. 
In the ICE-TEL project, the ISODE Consortium will add developments that it makes to its core release,  on the basis of results of the field trials.  It may add other technology developed by other project partners.  In particular, the Guardian DSA work from DRA will be incorporated.
	
2.6	European Added Value
Open communication networks are not restricted to regions or nations, but they span the whole world and Europe in particular. National solutions for public-key based security functions would isolate countries from one another unless the functions are interworkable. Therefore international cooperation is essential. The VALUE-project PASSWORD has helped to make three different security toolkits from France, Germany, and the UK interworkable. However, the further development of CAs and their interrelation in one European-wide infrastructure of public-key certification requires further cooperation across the boundaries of  regions or countries.
ICE-TEL will make sure, that a user in Spain can verify a digital signature produced in Norway, and that a message encrypted in the Netherlands can be decrypted in Greece while both functions are unforgeable and verifiable all over Europe. There is no Gateway solution possible for this kind of security in open networks.
Without ICE-TEL, there will be only local certification networks isolating regions fro one another. There would be no secure communication except within one region. With ICE-TEL, secure communication will work all over Europe. Moreover, interoperability with the U.S. can more easily be guaranteed by one strong European initiative rather than many different (and possibly concurrent) activities.
Some RSA-based applications are already visible on the Internet, for example “Secure Netscape” in cooperation with RSA Inc.  However, this technology was implemented in the US and is strictly restricted for export outside of US. Europe is in the bad position to be directly affected by this US export restriction.  If Europe wants to enjoy the same (or even a better) level of network security, it is forced to do it on its own initiative.
Without a self-reliant European technology of IT security including mechanisms, tools, and services, the US will quickly be in an unacceptable lead of using the Internet for cheap, secure, and reliable commercial, public, and private communication.  With a self-reliant European technology of IT security, Europe will enjoy the same benefits of cheap, secure, and reliable commercial, public, and private communication on open networks.  It is also essential (and easily feasible, too) to keep up interworking implementations and developments in the US and Europe. 
2.7	Economic and Social Impact
The growth rate of Internet usage is greater in Europe than in the US. This is especially true for the demand of European business to seek their way into using the Internet or other interregional and public networks.
However, due to the lack of established security services, business today is either restricted to closed, password-protected client groups, or abstinent from the network.
As a result, the main bulk of commercial communication is based on traditional technology like yellow mail, telephone or telefax. With the help of established global security services on the public networks, this will certainly change.
Communication will become cheaper and thus increase.  If privacy, authenticity and integrity of communication is protected , the business will use open networks for their serious and formal communication, too. Organisations will more easily become distributed across regions and nations as long as they stay within the same security infrastructure. A European security infrastructure will encourage more cooperation between organisations and between organisation departments across national borders in Europe. And, of course, growing amounts of inter-organisational communication, such as commerce, cooperation, and even the settlement of conflicts, will also be handled by modern communication network technology.
US security technology is not freely available in Europe. A self-reliant European security technology and related security services infrastructure will strengthen the European market on information and communication technology as well as their market applications.
Every single user of the open communication networks (like the Internet) can become a client of a certification authority, provided that the CA infrastructure is distributed widely enough. With the help of encryption and digital signature functions in his (or her) hand, he can protect himself from security risks of his communication. Every user can choose his level of security. This will improve self-reliance of user communication with respect to integrity, originality, and confidentiality. Communication over the networks strengthens the civil rights of people, if they can protect their security. ICE-TEL technology will guarantee end-user security even over insecure networks, because it is the users themselves who encrypt and digitally sign their data, and who decrypt encrypted data and verify digital signatures.
Also, by ICE-TEL technology network providers will be able to implement security functions for network operation. This will allow them to provide more secure networks and thus invite their users to trust the communication networks. Trustworthy communication networks are an important basis for a healthy and vital society.
However, security functions must not be introduced in the public without thorough investigation of their usability. Therefore, it is essential to run a strong CA pilot which develops its own technology and which is connected to real users and greater CA operation (like the TERENA CA initiative). During the pilot, user experience will be used to validate the results. In development cycles, the technology developed will be adapted to the real user needs. This way, the ICE-TEL technology of CAs and related secure applications will be fairly stable both with respect to technical and social issues.
Security has the fame of being expensive and reducing smooth functionality in the same time. However, with ICE-TEL security technology, more functionality is added to the networks, while cost is fairly moderate.
Users can decide whether they want to use security mechanisms in order to fulfil certain security requirements and then pay for, or whether they want to communicate informally and unprotectedly on cheap rates. Every user owns his (or her) own pair of a public and private key and can use it on his free choice.
There is a network of public-key certification authorities under steady operation which may be integrated into other existing services like directories, name authorities, or computer emergency response.
On the other hand, the existence of security services enables business to use the networks. Business will become quicker, cheaper, and more integrated in international European-wide cooperation. Information exchanged over the network may have very high values such as money or other contractual bindings. Damage or leakage can destroy high values.  In comparison, the encryption of the related data is simple and cheap.
Summarising this argument, ICE-TEL security technology allows huge new applications to be performed on the networks like confidential private communication, contractual administration communication, or committed high-value commercial communication. This is, ICE-TEL is able to bring these applications on the networks, while without security, these applications will simply stay outside of the networks and remain with their traditional communication forms.
2.8	
List of relevant reference material:

[1]  	The Directory (1993)   CCITT Recommendations X.500-X.525 (ISO/IEC 9594)
[2]  	The Directory - Proposed Draft Amendment on Extensions to Certificate Definitions for Parts 2, 6, 7 and 8 of The Directory, ISO/IEC JTC1/SC21/WG4 & ITU-T Q15/7, N9214, Dec 1994
[3]  	ISO 7498-2(E): Information processing systems Ð Open Systems Interconnection Ð Basic Reference Model Ð Part 2: Security Architecture. First Ed. 1989-02-15.
[4]  	ISO 10181-1 Information Technology, Security Frameworks for Open Systems - Part 1: Overview
[5]  	ISO 10021 / CCITT X.400: MOTIS / MHS. Message Handling Systems. 1988.
[6]  	Generic Security Service Application Program Interface (GSSAPI), Version 2,06/22/1995, <draft-ietf-cat-gssv2-03.txt>
[7]  	Generic Security Service API Version 2 : C-bindings,07/07/1995, <draft-ietf-cat-gssv2-cbind-01.txt>
[8]  	The Simple Public-Key GSS-API Mechanism (SPKM),05/31/1995, <draft-ietf-cat-spkmgss-04.txt>
[9]  	The Photuris Session Key Management Protocol,09/26/1995, <draft-ietf-ipsec-photuris-03.txt>
[10]  	The Secure HyperText Transfer Protocol (S-HTTP),07/07/1995, <draft-ietf-wts-shttp-00.txt>
[11]  	Privacy Enhancement for Internet Electronic Mail (PEM): Part I - IV, Internet Proposed Standard, RFC-1421 - 1424, 1993
[12]  	MIME Object Security Services (MOSS), Internet standards track protocol, RFC 1848, Oct 95
[13]  	Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, Internet standards track protocol, RFC 1847, Oct 95 
[14]  	UNINETT PCA Policy Statements,09/26/1995, <draft-uninett-pca-policy-00.txt>
[15]  	RSA Data Security, Inc., Public Key Cryptography Standards #1-9, June 3, 1991.
[16]  	PASSWORD Project Deliverable R2.5 'Certification Authority Requirements', Micheal Roe, Cambridge University Computer Lab, Version 1, Nov 1992. Also available by anonymous FTP from UCL, London (file r25.ps in the directory password)
[17]  	Kirstein, P. Williams: Piloting authentication and security services within OSI applications for RTD information (PASSWORD). 3rd Joint European Networking Conference, Innsbruck, Austria, 11-14 May 1992. In: Computer Networks and ISDN Systems, Vol. 25, Numbers 4-5, Nov 1992. Elsevier Science Publishers B.V. (North-Holland), pp.483-489.
[18]  	Schneider (Ed.): SecuDE. Ð Overview.  Arbeitspapiere der GMD 775. Bonn: GMD, September 1993. Also: Vol.2: Security Commands, Functions and Interfaces, Sep 93, available by ftp from darmstadt.gmd.de.
[19]  	Grimm, J. LŸhe, W. Schneider: Towards Trustworthy Communication Systems Ð Experiences with the Security Toolkit SecuDE.  In: Proceedings of the IFIP TC6/WG6.5 International Conference on Upper Layer Protocols, Architectures and Applications (ULPAA'94), Barcelona, 1.-3. Juni 1994, pp. 103-116. IFIP Transactions, Elsevier Science Publishers B.V. (North-Holland), 1994.
[20]  	Introduction to ISODE Consortium Products and Services, Release 3.0, London, 1995. Available in hard copy form from the IC, or in electronic form via FTP or FTAM from well known arcive sites (e.g. ftp.isode.com), or via WWW from http://www.isode.com
[21]  	D W Chadwick, "Understanding X.500 (The Directory)", Chapman and Hall, to be published 1Q 1994, ISBN 0-412-43020-7
[22]  	Interdomain Guardians in a Distributed Directory Service, D W Chadwick and N Pope, INDC 94 Conference, Funchal, Madeira Island, Portugal, April, 1994 
[23]  	Revised Working Document on Enhancement of Directory Operational Security, ISO/IEC JTC1/SC21/WG4 & ITU-T Q15/7, N9215, Dec 1994
[24]  	Diffie, M.E. Hellman: New Directions in Cryptography. IEEE Transactions on Information Theory. Vol.IT-22, 644-654, 1976.
[25]  	Rivest, A. Shamir, L. Adleman: A Method  for Obtaining Digital Signatures and Public Key Cryptosystems. Com ACM, Vol 21 No 2, 120-126, Feb 1978.
[26]  	ElGamal: A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms. IEEE Transactions on IT, Vol.IT-31, 469-472, 1985.
[27]  	ECMA TR/46: Security in Open Systems Ð A Security Framework. Edited by the European Computer Manufacturers Association (ECMA), July 1988, 71 pages.
[28]  	Information Technology Security Evaluation Criteria (ITSEC): Provisional Harmonised Criteria. Luxembourg: Office for Official Publications of the European Communities. 1991, VIII, 163 Seiten.
[29]  	Schneier, Bruce: Applied Cryptography. Protocols, Algorithms, and Source Code in C. John Wiley & Sons, Inc., New York 1994, 618 pages.
[30]  	Zimmermann, Ph.: Pretty Good Privacy Ð Public Key Encryption for the Masses. PGP User's Guide. Vol 1&2. PGP Version 2.6.1, 30. August 1994.

3	
DETAILED DESCRIPTION OF THE PROJECT

3.1	List of Workpackages

WP1	Management	(Responsible: C1)
This work-package deals with all aspects of the management of the project.  It is entirely the responsibility of the Coordinating Partner. Both the Project Director and the Project Manager will be heavily involved.

WP2	Activity with External Groups	(Responsible: C1)
This work-package is concerned with all aspects of relationships with other groups.  This includes concertation activities like the SCIMITAR project and anything else set up by the Commission.  It also includes the five other groups with whom we expect to have a particularly close relationship:  E2S, SEMPER, DESIRE, WEB4GROUPS, DEDICA and MERCI. It will be necessary to ensure common interface specifications between the projects, co-ordinate deliveries of software between the projects, feed back one assessment of the quality of the deliverables, and ensure that the feedback is properly progressed inside the projects.  Other activities will be the interface between the project and other communities such as the relevant Standardisation bodies like the Internet Engineering Task Force (IETF), the ITU standardisation bodies etc.  Yet a third sector will be the various user groups in other programmes with similar needs.

WP3   Architecture and General Specifications of the Public Key Infrastructure	(Responsible: C4)
The objective of this workpackage is to define an overall architecture of the public key infrastructure and to specify related tools, applications, and services within this architecture. Key issues of this architecture are a trust model, security policies, CA operation modes and guidelines, and interfaces to the CA service accessible by both clients and service providers.

WP4  Security Toolkit Maintenance and Development	(Responsible: C1)
The objective of this workpackage is to make available to the applications writers a set of toolkits which will allow them to write their applications without having to worry about the underlying security infrastructure. Both to ensure a more generic set of facilities, and to ensure later ease in interworking with other implementations, we wish to provide more than one such toolkit.  Moreover, we would like to allow an easy migration between toolkits and different applications.  In this workpackage we wish to explore also the different algorithms and certificate structures to extend the toolkits where this is required.

WP5  CA Tool Development	(Responsible: C5)
The objective of this workpackage is to implement interfaces, services and information objects between CAs and the users of an open communication environment. Trust models and cooperation interfaces are specified in workpackage 3. This workpackage 5 on CA tools will deliver a set of software and hardware-based tools that are used by CAs in order to perform their operation.

WP6  Secured Document Tools	(Responsible: C2)
Security services must be user-friendly, otherwise they will not be used properly or they will even not be used at all. The most important thing is that security service tools must be integrated in the normal user environment. For example, security for message handling must be integrated in the every-day mail user agents of the users. The objective of this work package is to deliver a set of secured message handling-oriented and database access oriented user tools.

WP7   X.500 Guardian DSA development	(Responsible: C9)
The Guardian DSA WP aims to develop an X.500 directory component which will act as a ‘firewall’ or ‘gateway’ between an organisational directory and a public directory.  The Guardian DSA will provide a secure gateway to public structures while supporting secure (confidential and authenticated) communications for users inside an organisation. Many commercial and government organisations would benefit from connecting to public directories but are unwilling to do so because of privacy concerns.  For example: they are unwilling to disclose structural information about their organisation and some attributes of personnel.  There is currently no product on the market which would provide such functions.  The Guardian DSA WP aims to design, implement, and commercially exploit such products.

WP8  Secure DSA	(Responsible: C3)
There is a close relationship between directory technology and X.509 security, and it is desirable to have a secure X.500(93) DSA as a part of the ICE-TEL infrastructure.  ISODE Consortium will supply such a DSA.   This WP will undertake work to facilitate use of this directory within ICE-TEL piloting.

WP9  Secure WorldWideWeb	(Responsible: C7)
The most rapid growth of the Internet is coming from the use of the World Wide Web (WWW).  No exploration of the deployment of security technology could be considered credible if it did not also examine the requirements of the WWW.  In some ways WWW has been designed for complete openness rather than security;  there is, for example, no need for any log-in.  Nevertheless, it has become clear that several forms of security are required.  Amongst these are the following:
•	The need to restrict access to specific WWW pages;
•	The need to authenticate users who desire to make commercial transactions or access data on the WWW
•	The need to bind commercial terms from one source (e.g. a supplier) to a user - and have the resulting transaction be confidential, all parties authenticated, and the resulting transaction be non-repudiable.
•	The need to have non-repudiable pages from the WWW available to clients.
•	The need to have the above facilities fully available in source form, to ensure that the security implications, and the strength of the algorithms used, can be verified.  It is unlikely that this criterion can be met from any US software or hardware.
It is the aim of this workpackage to develop mechanisms for providing these facilities.

WP10  Multiple Platform Support	(Responsible: C6)
Today, the most popular toolkits SecuDE and OSISEC are available on UNIX platforms. However, there are many users out there who use their MS-DOS/Windows PC or their MacIntosh for access to open communication services (such as electronic mail in the Internet). These users may even become the majority in a very near future. Increasingly, applications are designed as client-server architectures with the clients and user tools being used on PC and MacIntosh platforms. In order to support these users, and to be able to integrate the security functionality offered by the toolkits into a broad range of applications, this work package will port the existing security toolkits SecuDE and OSISEC to a PC and Mac Platform. In addition, it will also provide some of the secured user tools for electronic mail and database access, which will be developed in WP6, on PC and Mac platforms under various operating systems.

WP11  CA Service Provision and security support	(Responsible: C10)
The objective of WP 10 is the operation of the interworking European certification infrastructure in as many countries as possible, under a European top level CA, and the assistance of users to use and of developers to develop new secured applications based on the ICE-TEL technology.

WP12  Secure Communication of the CERTs	(Responsible: C11)
The Computer Emergency Response Teams (CERT) and their clients are one of the applicants of ICE-TEL technology. They need both integrity and confidentiality services in order to maintain a basis of trust for their consultancy. For example, the computer centre of a bank will never communicate security risks with a CERT if it must be aware of eavesdropping of this highly confidential communication. Also, it would not accept advice or software support from a CERT if the source is potentially masqueraded or if the information is possibly faked. This work package provides the CERTs and their users with the user tools which allows them to communicate at an appropriate level of security. Also, some CERTs may want to operate as a CA to their users. In this case, this work package will provide them with the necessary CA tools and integrate them into the CA infrastructure just as any other CA. These CERTs will have to learn to operate both as a CA and a CERT. This workpackage will give support for CERT and CA integration, too. Finally, the interworking between CERTs and national security competence centres will also be supported by this workpackage. An important result of this workpackage is a set of reports of the CERTs about their experience in the usage of ICE-TEL technology. These reports are part of the ICE-TEL validation process.

WP13  Security Support for the Torino Initiative   	(Responsible: C8)
The region of Piemonte is one of those participating in the EU-sponsored Regional Information Society Initiative, which fosters the application of information technology and telematics in the everyday life of citizens of the various regions in the project. Also, the capital of Piemonte, Torino, is one of those belonging to the EuroCities association of major towns not being a nation’s capital; this association too encourages its members to develop applications of information technology to solve common problems (e.g. automatic traffic control systems). In spite of many efforts, privacy and security remain a major drawback in all the attempts made by both associations to solve the problem of telematic communication between the public administration and the citizens. However the local administration is firmly decided to proceed in this direction. In fact, all the offices are being wired by a TCP/IP network, and a bid for the supply of 3,000 UNIX workstations has just been completed. Moreover, several low-cost Internet providers have recently started to appear in the region, with the consequence of greatly increasing the number of Internet users among the citizens.
The objective of this workpackage is to provide security support to different projects already under way in the public administration of the region of Piemonte. 

3.2	Timing of the work

Acti-
vity	
Subject	Y1
Q1	
Q2	
Q3	
Q4	Y2
Q1	
Q2	
Q3	
Q4	
1	Project Management									
2	Act. with ext. groups									
3.1	Supp. Trust models									
3.2	Sec Policies									
3.3	CA op. modes/interf.									
3.4	Firewall Technologies									
3.5	Nat. Sec. regulations									
4.1	Security APIs									
4.2	Trust models from 3									
4.3	Trusted HW integr.									
4.4	X.509v3 certificates									
4.5	Ext. Algorithm supp.									
5.1	Supp. Trust Models									
5.2	Supp. Various interf.									
5.3	Medium Ass. CA tools									
5.4	High Ass. CA tools									
5.5	SC Managmnt. syst.									
6.1	Secured X.400 MUAs									
6.2	MUAs Classic PEM									
6.3	MUAs for MOSS									
6.4	Secured WAIS									
7.1	Guardian design									
7.2	Guardian impl									
7.3	Guardian user trials									
8.1	X.500(93) Acc Contr.									
8.2	XDS API extensions									
9.1	Spec. WWW sec.									
9.2	Impl. Server side									
9.3	Impl. Client side									
10.1	Toolkits on PC, MAC									
10.2	User Ag. Integr. PC									
10.3	User Ag. Intergr. Mac									
11.1	Cert Serv. Prov.									
11.2	Europ. Top Level CA									
11.3	Nat. Sec. Comp. Cent									
12.1	User func. For CERTs									
12.2	CA func. For Certs									
12.3	Evaluat. Of CERT exp									
13.1	Select. Of Appl.									
13.2	Integr. Sec. Tools									
13.3	Field trials									

Major Deliverables	             
 Initial Software           ICE-TEL S/W I          ICE-TEL S/W II         ICE-TEL S/W III
                                   User Feedb. I            User Feedb. II           User Feedb. III
                  Infrastr. Spec.       WWW and Guardian Spec.	

3.3	Structure of the work
The different technical work-packages are largely independent, feeding into the major software deliverables in months 9, 15, 21 and 24.  Portions of these deliverables will then be the basis for further upgrades of the facilities.  In section 3.2 we have provided a GANTT chart showing the timing of the various activities.  These charts really can be used also to show the dependencies between the different work-packages.

3.4	Description of Work-Packages

The project will be performed in 13 work packages. The first work package is the overall project management. The second work package describes the activities concerned with external groups. The third work package is devoted to general specifications of the public key infrastructure. 

Work packages 4 to 10 are building the various components of the technical demonstrator.

Work packages 11 to 13 are application integration and validation  in three selected application areas. 

WP7 (Guardian DSA) is an exception from this structure in so far as it contains both the building of the technical demonstrator and the validation of the result.

3.4.1	WP1 Management

Objectives
The Objective of the Management work-package is to ensure that there is an adequate management structure and appropriate management activity to ensure that the Consortium members, the Project Management, the Commission, and External Bodies interacting with the project have the relevant information on the financial and technical progress to plan and develop their relations with the project.
Description of the Management Activity
The detailed management structure and way of working are discussed in Section 4.  The activity under this workpackage are principally to ensure that each party is aware of those aspects of  the technical and financial progress of  the project that they can take the actions needed for their part of the interaction.  The parties who must be considered are the following: The Partners of the Consortium, The Project Management, the Commission, User Groups inside the project and any external parties relying on the results of  the project for their work.  In order for this to be accomplished, all the parties concerned must  communicate adequately with each other, and take action if there are slippage or defects by themselves or another party.  
To achieve this, the following must be done:
•	The Project Management and Technical Committees must clearly state what each member is supposed to be accomplishing - and must be informed on how the work is progressing; in sufficient detail that remedial action can be organised.
•	The Project Members must inform the Project Management and each other of their technical progress, the financial consumption of resource in a timely manner - with due regard to the needs for internal control and external reporting.
•	If progress shortcomings are identified, Project Partners must be prepared to take action to remedy them.
•	The Project Manager must arrange for IPR agreements between the partners, Collaboration agreements between the partners, the timely provision of progress reports to the Commission, the timely submission of financial claims to the Commission, the timely distribution of funds received from the Commission to the partners, appropriate attendance at Concertation Meetings, and the timely provision of Deliverables to the Commission.
•	The Project Manager must organise regular Project Management meetings, organising their minutes.
•	The Project Manager must be aware of who is responsible for Deliverables, and how they are progressing.  If there are problems in there preparation, he must first inform the Project Management and Technical Committees; if problems are likely to persist, then they must be reported in the Progress Reports to the Commission.
•	The Project Manager must liase with external groups on the products being provided to, or being received from, other projects.  He most organise Collaboration Agreements when these are required.  He must inform such projects which depend on results of the ICE-TEL project of the progress, and any shortfalls in expected functionality or late delivery;
•	The Project Manager must ensure that there is an adequate external awareness of the project by distribution information on meetings and relevant calls in journals, organising presentations at conferences, keeping collections of publicity material and project publications.

Deliverables
Progress management reports (PMR), financial management reports (FMR), Annual Review Reports (ARR), Final Report (FR),  IPR agreements, collaboration agreements, deliverables, payments to partners  as per the contract.

3.4.2	WP2 Activity with External Groups
Objectives
The Objective of this work-package is to ensure that all activities concerned with external groups are adequately staffed, carried out and funded.  
Description 
There are a number of separate external interactions of the Project with the outside world.  Under this work-package we include the following: concertation activities, interaction with user groups, annual reviews, dissemination activities, production of information activities, and collaboration with other projects;  each will be considered below.
It is planned that the SCIMITAR project act in a co-ordinating role;  this will include concertation meetings, at which the project partners will be represented.  We are organising particularly strong ties with the E2S, SEMPER, DESIRE, WEB4GROUPS, DEDICA and MERCI projects.  For these will ensure that there are joint meetings with these projects - probably organised around the concertation meetings.  The Project Manager of SCIMITAR will be invited also to attend these joint project meetings.  It is intended to have a joint in-depth study of what each project has to offer to the others.  We will then provide documents between the projects detailing what products each expects to provide to the others.  In the joint meetings we will review progress in these promised products - flagging any potential delay or shortfall in specifications.  After delivery of the products to other projects,  we will expect feedback from them;  it is under this work-package that we remedy defects or make improvements in the products we have provided externally. Of course we will provide the relevant material, and participate in, the annual reviews - whether they are organised directly by the Commission or via the SCIMITAR project..
The interaction of the project partners with the User Groups within the project will be an integral part of WP11, WP12 and WP13.  However, we expect considerable interaction with other User Groups who also will wish access to the ICE-TEL products.  We will organise publicity material, documentation, and limited information and training meetings with such groups.  While the initial responsible for documentation is with the component provider, the production of appropriate external technical documentation will be carried out under this work-package.
We will strive to present our results at the relevant meetings organised by the Telematics Programme or the SCIMITAR project;  we expect also to participate in important other events such as the Joint European Network Conferences, the Internet Society Conferences, and other relevant Technical Conferences and Exhibitions.  Finally, while presentations at  conferences provide substantial short-term exposure, it does not replace publication in the learned  journals;  we expect to provide material for conferences to such a standard that the organisers will wish it to be reproduced in the journals which often publish the best conference papers, and will also submit papers independently to the relevant journal editors.
It is relatively straightforward to develop products and services to meet specific narrow needs;  it is much more complex to develop them in a way that interworks with products developed in other projects or by other vendors.  In the original proposal, there was a special work-package developed to participation in Standards activities.  We have chosen to remove this work-package in this Technical Annex - though the technical work-packages retain their intention to use such Standards where feasible, and often mention participation with relevant groups - particularly the IETF.  We expect, through this work-package, to retain our participation with the relevant co-ordination and standardisation groups.
Deliverables
Publications, publicity material as requested by the Commission or required for conferences, annual reviews, documentation for user groups and other projects, coordinated presentations at JENC7 and JENC8.

3.4.3	WP3   Architecture and General Specifications of the Public Key Infrastructure
Objectives
The objective of this workpackage is to define an overall architecture of the public key infrastructure and to specify related tools, applications, and services within this architecture. Key issues of this architecture are trust models, security policies, CA operation modes and guidelines, and interfaces to the CA service accessible by both clients and service providers. Related issues like firewall technogies and national security policies and their impact on the use and dissemination of security technogy in the different European countries and the US are addressed, too.

Description
1. Supported Trust Models
Certification of public keys means that some trusted third party assures the binding of a public key and a related person (identified by a unique name). This task identifies all possibilities of how the required trust can be realised by a network of third-parties. For example, PGP ("pretty good privacy") relies on a completely bilateral end-user-to-end-user certification in that it trusts only in bilateral assurance. In contrast, PEM ("privacy enhanced mail") suggests a set of certification authorities which are committed to certain security policies and operation modes. These certification authorities receive their trust from a broad user community due to their commitment to their certification behaviour and public control. This task will investigate different possibilities for trustworthy certification and will identify at least one prefered trust model.
2. Security Policies
The usage of public-key-based security services depends on a common set of rules that determine the security behaviour of all participants. This is especially important for the relationship between the users and trusted third parties. In the frame of a trust model this task defines and specifies security policies which govern the behaviour of certification authorities and the communication rules between the CAs and their clients, and the characteristics of the security services between the users.
3. CA operation modes and guidelines
In the frame of security policies  this task defines and specifies CA operation modes to which CAs are committed, and on which their clients and other CAs can firmly trust upon. This task will also formulate guidelines both for the support of CAs in order to perform their duties and operation, and for the clients in order to support their communication with Cas. The guidelines will include three major aspects: planning and installation guidelines, usage guidelines, and CA system management guidelines.
4. Interfaces to CA Infrastructure
In the frame of CA operation modes this task specifies services and information objects of the interfaces between a CA infrastructure and the users. CA interfaces will be based on different application environments such as mail, client/server interoperation, and WWW. The services and information objects will be both implemented within user tools, and clearly explained to the users within guidelines for users and CAs. User certificates, certificate paths, revocation lists, and public key lists are only a few examples of information objects defined in this task. Creation, update, and deletion of certificates, exchange of cross-certificates, publication of certificates or finger prints, are only a few examples of services defined in this task.
5. Firewall Technologies
In the absence of ubiquitous security mechanisms for the networks, firewall technologies have been widespread emerged in recent years and used by organisations which need to protect their systems and corporate networks when connecting them to open unsecured networks like the internet. While most of them impose simple filter mechanisms on various communication protocol levels in a non-cryptographic fashion and therefore can provide only limited protection against the serious attacker, there is a danger that increasing use of firewalls counters the openess of the global network more than necessary and obstructs the unlimited connectivity and information exchange. We will address these problems and compile a survey on firewall technologies.
6. National security regulations and the use of cryptography for trans-border communication
The use and dissemination of cryptographic security technology is considered a national policy issue and regulated in many countries in different ways. How this affects the ICE-TEL project is not clear yet. Trans-border communication with cryptographic means is another open issue. We will address these problems in a separate report.

Deliverables
A report on trust models for a network of trusted CAs, Specification of security policies which determine the characteristics and requirements of different levels of security services for low level assurance, medium level assurance and high level assurance, Specification of CA operation modes, guidelines for the CAs, and guidelines for the users, Specification of mail-based, client/server-based and WWW-based interfaces to CAs. Specification of services and information objects available for cooperation among CAs and between CAs and their clients, related to different CA interfaces. Development of developer’s APIs specifications. Report on firewall technologies. Report on national security regulations and the use of cryptography for trans-border communication.

3.4.4	WP4  Security Toolkit Maintenance and Development
Objectives
The objective of this workpackage is to make available to the applications writers a set of toolkits which will allow them to write their applications without having to worry about the underlying security infrastructure. Both to ensure a more generic set of facilities, and to ensure later ease in interworking with other implementations, we wish to provide more than one such toolkit.  Moreover, we would like to allow an easy migration between toolkits and different applications.  In this workpackage we wish to explore also the different algorithms and certificate structures to extend the toolkits where this is required.

Description
While there are already many toolkits - e.g. SESAME, Entrust, SECUDE, OSISEC, COST technology and the security toolkit supplied as part of IC R3 - they have different properties and facilities.  Some of these toolkits are proprietary, and the source code will not be revealed. SESAME, SECUDE and OSISEC will be made available free for non-commercial use. IC R3, including security toolkits, will be made available to the project as background software by the ISODE Consortium. The project will concentrate on the toolkits which are being made available to the project -  SECUDE from GMD, OSISEC from UCL, IC R3 from IC, SESAME and COST - and provide for some common basic set of functionality.  This workpackage will contain several activities to update these toolkits in line both with recent external initiatives and with the internal desires of the ICE-TEL (and other) application developers.  We discuss here five activities:  definition and provision of Application Programming Interfaces (APIs), support for different Trust Models, integration  of specialised hardware, support for newer certificate formats, and extended algorithm support;  each is considered below.

1. Security APIs (e.g. GSSAPI, PKCS 11)

There have been many studies on APIs, and many APIs have been defined.  The general industrial view is that there are already enough candidates, and no new one should be addressed.  In fact there are many levels of API in this area;  at the lower level there are APIs to the cryptographic routines or to the certificate processing modules;  at the higher level they are directly the interfaces to the applications developers.  A recent study (still unpublished) identified  many such APIs in common use:  

•	To the cryptographic routines - e.g. Spyros MOSAIC, NIST, X-Open CSF,
•	To the applications programmes - e.g. the IETF GSS-API,  the Entrust extension to GSS-API, the IBM CAPI, and the X-Open DCF.

We expect to decide early in the project  which APIs we would adopt for ICE-TEL purposes.  It is up to the toolkit provider how interfaces are provided between the lower cryptographic interfaces and the rest of the toolkit;  however it is relevant to the applications provider what API is required for the applications.  It would be highly desirable that a common API is adopted.

2. Support for Trust Models identified in WP 3

In the early days of PEM, a very rigid, hierarchical  trust model was adopted.  Each CA had to ensure that it certified only certificates subordinate to it in the name space.  The resulting tree structure had only one root - that of the Internet Society;  there was also a rigid policy root - the Policy CA (PCA) with publicly available certification policies.  By contrast, in PGP there is no real trust model;  each certificate is self-certified, and is distributed with some personal assurance of validity.  In PASSWORD an intermediate model was assumed;  the PCA concept was retained, but there were national Top-Level CAs which would cross-certify each other;  below this there was a reasonably rigid hierarchy.  In all the above, the user could determine his own secret key;  by contrast, in the FORTEZZA approach the private keys are set by the site security officer, and are rigidly registered.  This matter is being addressed in WP3, and various trust models will be recommended for different ICE-TEL purposes.  In this workpackage we will provide technical support for the trust models in the toolkits.

3. Trusted Hardware Integration (e.g. Smartcards, PCMCIA)

In the PASSWORD and SESAME projects, the security facilities deployed have relied entirely on specific software in the client machines (though SECUDE, used in PASSWORD, provides some support for smart cards).  By contrast in the US DMS and related projects, they rely entirely on specialised hardware - the FORTEZZA card;  in DMS this determines the security operations through the Local Authority Workstation (LAW);  OSISEC provides support for early versions of the FORTEZZA card.  The PEM project initially mandated that at least high assurance CAs should use a hardware signing unit;  while this was later relaxed, it is a possible approach.  In this workpackage we will first specify which specialised hardware to support in the ICE-TEL project;  this will be determined in part from discussion with the validation sites.  The provision of support for such specialised hardware in the toolkits is the subject of this workpackage;  at least support for some specific smart cards, and some specific workstation interfaces like PCMCIA will be provided.

4. Support for X.509v3 Certificates

In the early PEM and X.500 work, a specific certificate structure was proposed;  all the early work was directed to this format.  Already in the later PEM and PASSWORD activities certain deficiencies were recognised in the format.  In the recent X.500 93, ISO addressed these deficiencies, and a new X.509v3 format has been defined;  this provides important new features like the ability to specify the security algorithms being used.  In this workpackage the functionality of the toolkits will be extended to include the X.509v3 certificate formats. SESAME already supports X.509v3 certificates to some extent. This functionality will be required to operate with the upgraded X.500 Directory services which will be emerging during the next couple of years, and appears to be vital for various security models currently under consideration for the WWW-Technology.

5. Extended Algorithm Support (DSS, Triple-DES, IDEA)

The versions of the OSISEC and SECUDE toolkits used in PASSWORD both supported a number of algorithms used in cryptographic functions including MD2 and MD5, RSA and DES.  The individual toolkits also supported some other algorithms (e.g. DSS).  In this workpackage we will extend the range of algorithms supported - certainly to include the faster IDEA encryption routines, the more secure triple DES, and the DSS signing used with the FORTEZZA card.  The range of algorithms to be supported will be determined mainly by those considered desirable in the validation workpackages.

Deliverables
Demonstration of the support for the agreed APIs and different trust models, Demonstration of support for agreed smart cards in both SECUDE and OSISEC, and support for at least the FORTEZZA card and one hardware signing unit in one toolkit, Demonstration of support for X.509 v3 and the extended algorithms in the toolkits, interworking with an X.500 (93) implementation.

3.4.5	WP5  CA Tool Development
Objectives
The objective of this workpackage is to implement interfaces, services and information objects between CAs and the users of an open communication environment. Trust models and cooperation interfaces are specified in workpackage 3. This workpackage 5 on CA tools will deliver a set of software and hardware-based tools that are used by CAs in order to perform their operation.
Descriptions
1: Support for Trust Models identified in WP 3
A variety of trust models will be supported by implemented tools which are used by the CAs in order to operate with regard to the trust models. For example, bilateral exchange of certificates will be supported by public key lists and cross certification services in the hand of users which can be communicated or even initiated by CAs. For another example, CAs will regularly disseminate user information such as certification paths, CA cross certificates, the public key of a root-CA, revocation lists, etc. This task will deliver the respective CA tools.
2: Support for a variety of interfaces to CAs, e.g., mail-based, client/server-based, WWW based.
In addition to general CA tools mentioned above, there will be a set of corresponding tools for CAs and users which allow for cooperation between CAs and users, for inter-CA communication, and for key changing/update including update of CA keys. There will be three specific types of interfaces, based on electronic mail, based on client/server operation, and based on WWW communication. Any of these communication interfaces will be supported by a set of tools that support the corresponding communication services.
3: Medium Security Assurance CA tools using software only
The overall security for communication in an open environment (such as the Internet, for example), depends on a high security level of the local sites. Due to the current state-of-the-art, this is accomplished by smartcards, integrated in a local hardware environment of smartcard readers and workstations. However, if one trusts in the security of his local work station, the smartcard can be emulated by software on the local workstation. The security level in the communication network would be the same, anyway, but the local solution would be considerably cheaper. For this reason, in order to distribute the security tools more easily among a broad user community, this task will deliver a set of software solutions for the emulation of smartcards and their integration into the local workstation environment.
4. High Security Assurance CA tools using specialised hardware
In this task, smartcards will be integrated in a local hardware environment of smartcard readers and workstations. The security services used by the CAs such as digital signature and encryption mechanisms will automatically access the data stored on the smartcards through the smartcard interfaces integrated in the local workstations of the CAs. The security level of this solution is the same as the security level achieved by the medium level CA, as far as the protection of the communication data in the open network is concerned. However, as far as the protection of the local sensitive data (such as private keys) is concerned, this hardware solution is much higher than a software-emulated local protection.
5. Smartcard management systems
The smartcard-based protection of local sensitive data (such as private keys) which is achieved by smartcards, requires a specific management system. In addition to the maintenance of keys and certificates and related information, the smartcards themselves must be created, shipped and delivered. Also, the loss of smartcards requires specific management actions. This task provides a smartcard management including services, tools, and cooperation protocols between smartcard management centres and their clients. CAs are good candidates to provide the smartcard management, as well.

Deliverables
Tools for CAs in order to operate with regard to different trust models, tools for CAs and their clients which allow them to cooperate in the frame of different interfaces to the CA service, Software which performs smartcard functionality for CAs, Smartcards and smartcard readers hardware integrated in the local security environments of Cas, tools for a smartcard management system available for both smartcard maintenance centres and their clients.

3.4.6	WP6  Secured Document Tools
Objectives
Security services must be user-friendly, otherwise they will not be used properly or they will even not be used at all. The most important thing is that security service tools must be integrated in the normal user environment. For example, security for message handling must be integrated in the every-day mail user agents of the users. The objective of this work package is to deliver a set of secured message handling-oriented and database access oriented user tools.

Description
1: Secured X.400 MUAs
X.400 (1988/1992) is the OSI-based solution for message handling which includes a broad range of security specifications. This task will implement a set of security services due to the X.400 specifications and connect them to the CA infrastructure established by this ICE-TEL project. Security services include content integrity and confidentiality as well as proof of submission and delivery of a message. This task will demonstrate that X.400-based security will operate safely in connection with the ICE-TEL CA infrastructure.
2. MUAs supporting Classic PEM (RFC 142x)
Internet RFCs 1421-1424 specify a set of formats and protocols for the some e-mail security services which are transparent to the mail protocol suite, i.e. which can be used both for X.400-MHS and Internet-SMTP (and all other e-mail systems, as well). During the PASSWORD project user tools with a direct file-access were implemented. This task will integrate these tools into popular MUAs such as for Open Windows, Motif, MS-Windows/NT, Windows 95 and MacIntosh. The cross-platform aspects of these activities, as far as Windows/NT, Windows 95 and MacIntosh are concerned, will be part of WP10.
3. MUAs supporting MOSS (MIME Object Security Services)
The MOSS specification is significantly different from "Classic PEM". It is undecided which of the two specification suites will become dominating, however, the need for authentication and privacy functionality for MIME-structured information is evident. In order to help users to use both, MIME and PEM within one MUA, this task will integrate the security services specified by the MOSS approach into popular MUAs such as for Open Windows and Motif. A competitive approach is the S/MIME specification from RSA Inc. While the importance and acceptance of this approach is not clear yet, we will carefully examine and observe this technology.

4. Secure WAIS Database Access
It is a key requirement of secure applications to provide access to a database in a securable form.  In this activity we will provide secured access to a database system.  By this we mean that it will require strong authentication to access the database;  it will be possible to request that the database sign data items Thai t it returns to the user;  it will be possible to send data items encrypted so that only the authorised recipient can access the data.  Finally, we will provide an audit trail so that the database usage is non-repudiable.  The database will not be a general one;  we will base it on the WAIS database technology, which has searching of arbitrary text strings.  There is a Public Domain version of the WAIS technology (PD-WAIS) which is freely distributable;  this will be one of the vehicles used.  We will also work with the Commercial version (C-WAIS), which has both field search and WWW access, but cannot guarantee at this time on what terms that can be distributed inside the project.

Deliverables
X.400 MUAs with X.400-defined security services, MUAs with "Classic PEM"-defined security services, MUAs with integrated MOSS and PEM functionality, demonstration of a working database with PD-WAIS and  C-WAIS.

3.4.7	WP7   X.500 Guardian DSA development
Objectives

The Guardian DSA WP aims to develop an X.500 directory component which will act as a ‘firewall’ or ‘gateway’ between an organisational directory and a public directory.  The Guardian DSA will provide a secure gateway to public structures while supporting secure (confidential and authenticated) communications for users inside an organisation.  There already exists a public directory on the Internet which holds several million entries from several thousand (mainly academic) organisations.  Many commercial and government organisations would benefit from connecting to this system but are unwilling to do so because of privacy concerns.  For example: they are unwilling to disclose structural information about their organisation and some attributes of personnel.  There is currently no product on the market which would provide such functions.  The Guardian DSA WP aims to design, implement, and commercially exploit such products.
Description

Whilst the Guardian DSA will not actually contain any corporate directory data, it will give the impression to the external (public) domain that it actually contains all of it.  Thus the exact locations, distribution and composition of the private domain will be withheld from the external domain, whilst authorised requests will still be able to flow between the domains in an uninterrupted manner, fully conformant with the open systems standards.
The functionality that is required of the Guardian DSA is:
-	to DSAs in the external domains it appears to hold the entire set of naming contexts held by the DSAs of the local security domain (and any encapsulated higher security domains);
-	to the DSAs of the local security domain, it handles requests for the remainder of the DIT that is not held in the local domain;
-	it holds little, if any, directory information itself, but merely contains knowledge references to some or all of the DSAs in the local security domain, as well as to some DSAs in the external domain;
-	all Directory operations between the external domain and the local security domain must flow via the Guardian DSA;
-	it ensures that knowledge references to DSAs in the local security domain are not transmitted to DSAs in the external domain - referrals generated by DSAs in the local security domain are always massaged by the Guardian DSA to point to itself, before being sent to DSAs in the untrustworthy external domain;
-	it provides a trusted gateway between different security mechanisms within and outside the security domain (for example, password based authentication may be used within the domain, whilst external domain  authentication may be provided using digital signatures; the Guardian DSA would therefore refuse any external requests that were not digitally signed);
-	it maps security policy information from external domains onto internal policies, so determining the level of trust to award to external requests.
The WP will be carried out in the following steps:

1. Detailed design of the Guardian DSA
This task is to produce a detailed design for the software required for the Guardian DSA.  The work will be based on the user requirements as understood by DRA.  It will be based on the existing design produced for DRA in 1993.  It will be guided by knowledge of the product on which the development will be based (IC R3), and by the deliverables of WP8.

2.  Guardian DSA - implementation 
The implementation will be based on the IC R3 software and on the results of WP8.

3.  User trials (validation stage)
This task will be carried out at DRA Fort Halstead. The DRA has a large internal unclassified network which is used for general business communication, and for unclassified work.  This large user base will have access to the data in the DRA directories via the Guardian DSAs, as will external users via the Paradise directory service.

Deliverables
Detailed design documentation for Guardian DSA, Guardian DSA implementation, validation, user trial.

3.4.8	WP8  Secure DSA
Objectives
The key element for this work package is an X.500(93) DSA, and associated DUA libraries and infrastrucutre.   This DSA provides the X.500(1993) access controls and makes use of the X.509 infrastructure. It will therefore be, in its own right an application that will be used as a part of the piloting infrastructure.
In the context of X.509 based security, the X.500 has a larger role than just being a user of the security services.  A key reason for use of X.509 CA based authentication is that it is scalable to provide manageable authentication services in a large scale distributed environment.  Altough X.509 is independent of X.500 and can be used standalone for small scale operations, it is designed to be used in the contex of an X.500 directory for large scale operations.   In order to pilot security services effectively on a European scale, it will be necessary to use an X.500 infrastructure to support the piloting.   For this reason, it is important to bring a key component of that infrastructure within the ICE-TEL project to facilitate that use and integration.
This task provides some extensions to the X.500 infrastructure, to facilitate its use as a part of the security infrastructure.

Description
We will provide X.500(93) DSA Access Control Tools.  An implementation of X.500 Basic Access Control (BAC) will be provided as background.  Because of the complexity of the access controls, there is a need for a management interfaces to abstract these controls in a manner which makes them usable.  This task will investigate this problem in the context of X.500 deployment.
We will provide API extensions.  The XDS X/Open API is the industry standard for DUA access.   This API does not support security features.  This task is to extend the XDS API to provide support for security features.  This will enable DUAs to access X.500 security features.

Deliverables
Demonstrator tools with X.500(93) Access Control functionality, Specification of XDS extensions, Implementation of the XDS extensions.

3.4.9	WP9  Secure WorldWideWeb
Objectives
The most rapid growth of the Internet is coming from the use of the World Wide Web (WWW).  No exploration of the deployment of security technology could be considered credible if it did not also examine the requirements of the WWW.  In some ways WWW has been designed for complete openness rather than security;  there is, for example, no need for any log-in.  Nevertheless, it has become clear that several forms of security are required.  Amongst these are the following:
•	The need to restrict access to specific WWW pages;
•	The need to authenticate users who desire to make commercial transactions or access data on the WWW
•	The need to bind commercial terms from one source (e.g. a supplier) to a user - and have the resulting transaction be confidential, all parties authenticated, and the resulting transaction be non-repudiable.
•	The need to have non-repudiable pages from the WWW available to clients.
•	The need to have the above facilities fully available in source form, to ensure that the security implications, and the strength of the algorithms used, can be verified.  It is unlikely that this criterion can be met from any US software or hardware.
It is the aim of this workpackage to explore mechanisms for providing these facilities.
Description
It is possible to provide many sorts of mechanisms to meet the needs described above - but an arbitrary choice would be relatively valueless.  We would like to provide mechanisms which meet the following criteria:
a)	They are compatible with any existing Standards - de facto or international..  At present at least two suppliers, NETSCAPE and EIT, have developed proprietary solutions - e.g. for Commercenet..  However, it is essential that we follow a mechanism that has the acceptance of the community.
b)	They can interwork with non-secured versions..  It is very important that a Secured WWW Server can continue to operate with non-secured clients - with more limited facilities, and that a Secured Client can be use with non-secured Servers.
c)	Interoperability with secured versions. If possible, we would like an ICE-TEL server to interoperate with one or more secured clients  available commercially.  We would also like an ICE-TEL Client to interwork with one or more commercial secured Servers.
d)	Common Security Infrastructure..  It is to be hoped that the same security and key exchange infrastructure can be used for WWW purposes as for the rest of the ICE-TEL activities.
The above constraints mean that we will have to follow deeply the current activities in the WWW Consortium and in the IETF.  There is a large effort here in securing WWW environments, and we will ensure that the ICE-TEL activities take this work into full account.
Some of the ICE-TEL partners have already provided a secured server and clients using the toolkits being provided for ICE-TEL. The same principles apply to a WWW server and client. The only real difference is the information which is being served, though the WWW case needs to support a much wider variety of clients and (maybe) protocol versions.  Secure ftp and secure http are likely to be very similar indeed. The basic mechanism for these (as well as for secure WAIS, secure X.500 etc) is
  client binds to server           	[anonymous, simple or strong]
  client issues read request	[possibly signed or encrypted]
  server issues response          	[possibly signed or encrypted]
For WWW/http, the initial bind is currently always anonymous. In a secured WWW, it could be strong. However, for any protocol using the bind/request/response model, the strong bind seems to merely ensure that signed operations will work.  The server would apply authentication and access control based on the signature on a signed read request
Therefore, a secure WWW could continue to use anonymous binds (thereby improving interoperability with the existing WWW infrastructure), though the bind mechanism would have to somehow negotiate an acceptable/achievable level of security.  HTTP read requests (which looks like FTP "get" commands) would be signed by the user operating the browser to allow access control, audit and integrity, and possibly encrypted to allow confidentiality.  The server's response (which looks like a MIME email message) would be signed by the server to allow authentication and integrity, and possible encrypted to allow confidentiality.
The following issues are worth to be noted:
1.	The WWW server would have a PSE, so it could determine which users it   trusted. However, mechanisms for specifying the access control for each web page would be necessary. The mechanisms need to grant or deny access to individuals, departments, organisations and countries.
2.	Just as chaining raises issues for secure X.500, so caching raises issues for secure WWW
3.	The WWW Consortium has been working on specifying a secure protocol. The current NetScape release contains proprietary security code which NetScape has apparently offered to the WWWC as a candidate for the standard. We would find it advantageous for ICE-TEL to follow NetScape or the WWWC closely if not exactly.
There is a bunch of work already in progress on this subject. Any ICE-TEL activity must first reconcile the current work, which would be done at the beginning of the project.  The current industry approach is to provide the Client software free, but to charge heavily for the Servers.  We would look very carefully at what is available in commercial client software, and ensure that matching Server software was provided by under the project.  In this way we would expect to form close links both with the WWW Consortium and companies like  Sun Microsystems, whose recent public domain JAVA project might also provide a good set of introductory tools.  Clearly ICE-TEL will be addressing an interesting and useful problem with a range of achievable solutions.  Our approach will be to ensure that the solutions we adopt are compatible not only with the rest of the WWW community, but also with our security infrastructures.
The global situation in the WWW-area is changing very rapidly.. The first phase of this WP therefore has to look carefully at the work that already has been done by others and from this define the scope of this WP.  This includes the following:
•	Define a set of features the Secure WWW-Software will need to comply with, based on the needs of the demonstrator and other potential users. This includes to define the level of compatibility to current and forseeable future standards (HTML, HTTP) the software has to comply with. Extensions to the standards that are becoming a defacto-standard and new developments (like Java) and their implications on security and this project must also be considered.
•	Currently there are no formally standardized protocols for secure WWW. It is yet unclear if one of the current two main “competitor” protocols, Netscape’s SSL and EIT’s SHTTP, will dominate or if some new proposal will become the standard in the future. Most probably though, there will be more than one protocol in practical use. For ICE-TEL, this means that it is necessary to select the protocols to be considered.. Furthermore, these protocols typically leave implementation details, like the set of cryptographical algorithms, to the implementor. This makes it necessary to define which of these optional services or mechanisms will be supported.
•	Success and relevance of this WP are highly dependent on international activities. Things are changing rapidly and it is very important to keep in close contact to and cooperation with international organizations. Most importantly we will need to closely cooperate with and seek input from the WWW-Consortium and actively participate in relevant bodies, like IETF-WG’s.
•	It will also be necessary to observe new developments in the WWW-environment closely.. Emerging protocols, like electronic payment protocols, could have important impact on this WP.
There is no intention to write a new Web-Server and Web-Browser from scratch. This makes it necessary to evaluate existing Web-software, not restricted to software provided by partners, for suitability to ICE-TEL and conformance to the feature-set defined above. Possible candidates should be available free of charge, at least for academic use, for the most common platforms (UNIX, PC, MAC).
Based on these results, modules for handling the WWW-security-protocols are specified. The relevant parts of the security toolkit (WP 4) necessary to handle the required protocols and mechanisms are identified. Using these modules, new modules for the WWW-security-protocols will be developed.
The security services and mechanisms necessary for implementing WWW-security will be integrated into the chosen Web-Server and Web-Browser-Software. This will be done in a way to make it as easy as possible to do the same for any other  Server or Browser.
Deliverables
As a result of this workpackage, we would expect to provide at least one WWW Server, which should be integratable with both the GMD and the UCL security tools and compatible with the emerging IETF/WWWC practices. We also expect to provide at least one suitable Client - though the concept for this Client must await further detailed study and discussion with the WWWC and other organisations to determine a suitable unsecured base. The deliverables will consist of
•	A report discussing the users view of  Security in relation to the WWW, the solutions available and applicable for certain categories and their relation to international standards. It will also specify the security services, protocols and mechanims to be implemented.
•	A software-library that contains all necessary functions, protocols and mechanisms to provide secure WWW. Using this library, we will provide at least one WWW Server, which should be integratable with both the GMD and the UCL security tools and compatible with emerging IETF/WWWC practises.  We will also provide at least one suitable Client -- though the concept for this client must await further detailed study and discussion with the WWWC and other organizations to determine a suitable unsecured base.

3.4.10	WP10  Multiple Platform Support
Objectives
The need for end-user security functionality on PC and MacIntosh platforms is evident. While the SESAME toolkit is already available on Windows, SecuDE and OSISEC have been developed on Unix platforms and are available in their entire functionality UNIX platforms only. However, there are many users out there who use their MS-DOS/Windows PC or their MacIntosh for access to open communication services (such as electronic mail in the Internet). These users may even become the majority in a very near future. Increasingly, applications are designed as client-server architectures with the clients and user tools being used on PC and MacIntosh platforms. In order to support these users, and to be able to integrate the security functionality offered by the toolkits into a broad range of applications, this work package will provide security toolkits on PC and Mac platforms. In addition, it will also provide some of the secured user tools for electronic mail and database access which will be developed in WP6, on PC and Mac platforms under various operating systems.

Description
1. Provision of Security Toolkits on PC and MacIntosh platforms
This task will provide some of the security toolkits from WP4 for MS-DOS/Windows PC and MacIntosh platforms.
2. MUAs from WP 6 implemented on PC and MacIntosh
This task will port the MUAs developed by WP6 and which are popular in the PC or MacIntosh world as well to the PC and Macintosh platform, respectively.
3. Integration of "Classic PEM" and MOSS functionality into standard MUAs (e.g., Microsoft Mail API)
This task addresses the cross-platform aspects which arise when providing standard PC and Mac MUAs with "Classic PEM" and MOSS functionality. The overall aim of this work package and of this task in particular is to provide the PC and MacIntosh users with the same mail and security functionality as the UNIX users.

Deliverables
Security toolkits toolkits implemented on PC and MacIntosh, MUAs from WP6 implemented on PC and MacIntosh, Standard MUAs (such as Microsoft Mail API) upgraded with "Classic PEM" and MOSS functionality.

3.4.11	WP11  CA Service Provision and security support
Objectives
The objective of WP 10 is the operation of an interworking European certification infrastructure in as many countries as possible, and the assistance of users and developers in the use and development of new secured applications based on the ICE-TEL technology. This will serve as a major validation of the ICE-TEL technology. The certification infrastructure should be flexible to a high degree to be able to serve for different trust models developed by WP3. There is no such infrastructure in place at the time being. We will operate a European top-level CA for the purpose of the project. It is anticipated that the ICE-TEL certification infrastructure will be the seed for a general purpose European certification infrastructure, not only for the research sector.

Description
1. Certification Service Provision in Various Countries
Within this task, several countries will bring CAs in operation. The CAs will be equipped with software, hardware, and tools developed in the other workpackages of this project ICE-TEL. The CAs will be running, operating, and serving a broad community of users. All services will be demonstrated to be interworking between clients communities of different CAs. We will put in place the certification infrastructure at the very beginning of the project on the basis of the existing background technology of the project partners, for instance from the PASSWORD project, and continue to upgrade the technology and the services as the result of the outcome of the development work packages WP4 to WP9.
2. European Top-Level CA Provision.
In order to facilitate the interworking of different trust domains, a particular CA will be created to operate as a top-level CA. In principle, this CA would operate like all the other CAs, i.e. serve a clients community and interoperate with other CAs, e.g. with the US Internet top-level CA. However, a particular duty of this CA is to serve other CAs and to maintain a particularly stable and public service. For example, the public key of the top-level CA must be known to all other CAs and to every user in Europe who participates in this CA infrastructure. There will also be a special protocol for changing keys of the top-level CA. This will be investigated during this task as well.
3. National Security Competence Centres in Various Countries
The European certifiaction infrastructure will be operated in a highly decentralized fashion. A considerable part of it will be provided by the users themselves, in that they operate their own certification sub-structures by means of the ICE-TEL technology. Within this task, several countries will bring national security competence and support centres in place. These centres collect competence in the usage of software, hardware, services, and tools developed in the project ICE-TEL. They will support users and CAs in installing, integrating and using the ICE-TEL security systems. They will disseminate the knowledge about the new ICE-TEL technology.

Deliverables
Certification service provision in various countries. The CAs will be running, operating, and serving a broad community of users. All services will be demonstrated to be interworking. European top-level CA provision. National security competence and support centres operating in various countries. Report on user feedback.

3.4.12	WP12  Secure Communication of the CERTs
Objectives
The Computer Emergency Response Teams (CERT) and their clients are one of the applicants of ICE-TEL technology. They need both integrity and confidentiality services in order to maintain a basis of trust for their consultancy. For example, the computer centre of a bank will never communicate security risks with a CERT if it must be aware of eavesdropping of this highly confidential communication. Also, it would not accept advice or software support from a CERT if the source is potentially masqueraded or if the information is possibly faked. This work package provides the CERTs and their users with the user tools which allows them to communicate at an appropriate level of security. Also, some CERTs may want to operate as a CA to their users. In this case, this work package will provide them with the necessary CA tools and integrate them into the CA infrastructure just as any other CA. These CERTs will have to learn to operate both as a CA and a CERT. This workpackage will give support for CERT and CA integration, too. Finally, the interworking between CERTs and national security competence centres will also be supported by this workpackage. An important result of this workpackage is a set of reports of the CERTs about their experience in the usage of ICE-TEL technology. These reports are part of the ICE-TEL validation process.

Descriptions
1. ICE-TEL user functionality is integrated into CERT functions.
CERTs and their users are equipped with the ICE-TEL user tools. In particular, the ICE-TEL user tools are integrated into the application functionality of the CERTs. This is partly done by ICE-TEL developers, and partly by the CERT staff. The secure CERT service is performed by CERT staff only. CERTs and their users will demonstrate that ICE-TEL technology satisfies their security requirements.
2: ICE-TEL CA functionality is integrated into CERT functions.
CERTs are equipped with the CA tools of ICE-TEL. In particular, the CA tools are integrated into the application functionality of the CERTs. This is partly done by ICE-TEL developers, and partly by the CERT staff. The CA service of the CERTs is provided by CERT staff only, in that they will run both CA and CERT service in parallel. This way, CERTs operate as CAs and demonstrate that CERT and CA service go together well within one organisation.
3. Evaluation of the experience of CERTs with ICE-TEL technology.
This task will deliver a set of reports by the CERTs on their experience with ICE-TEL technology including their experience as CA users, CA providers, and as clients of the national security competence centres.

Deliverables
ICE-TEL user functionality is integrated into CERT functions. CERTs and their users, equipped with the ICE-TEL user tools, demonstrate that ICE-TEL technology satisfies their security requirements.
CA functionality is integrated into CERT functions. CERTs operate as CAs and demonstrate that CERT and CA service go together well within one organisation.
Reports of CERTs on their experience with ICE-TEL technology including their experience as CA users, CA providers, and as clients of the national security competence centres.

3.4.13	WP13  Security Support for the Torino Initiative
Objectives
The region of Piemonte is one of those participating in the EU-sponsored Regional Information Society Initiative, which fosters the application of information technology and telematics in the everyday life of citizens of the various regions in the project. Also, the capital of Piemonte, Torino, is one of those belonging to the EuroCities association of major towns not being a nation’s capital; this association too encourages its members to develop applications of information technology to solve common problems (e.g. automatic traffic control systems). In spite of many efforts, privacy and security remain a major drawback in all the attempts made by both associations to solve the problem of telematic communication between the public administration and the citizens. However the local administration is firmly decided to proceed in this direction. In fact, all the offices are being wired by a TCP/IP network, and a bid for the supply of 3,000 UNIX workstations has just been completed. Moreover, several low-cost Internet providers have recently started to appear in the region, with the consequence of greatly increasing the number of Internet users among the citizens.
The objective of this workpackage is to provide security support to different projects already under way in the public administration of the region of Piemonte. 
Description
A demonstrator would be set up in the form of a modified application (incorporating security aspects), tested on a small set of users (for gross tuning), and then fine-tuned on a larger basis. Finally, the application would be deployed in the whole region of Piemonte, and proposed for exploitation by the other members of the consortia mentioned above.
There are three main applications which will be considered to receive support in the frame of the ICE-TEL project:
1.	workflow management of complex documents between different offices of the same administration
	Many administrations are geographically distributed on a large area. The flow of documents needing authorisations from different sites would be greatly accelerated if it could be done electronically.
	However, prerequisites are the handling of multimedia documents (at least formatted text and graphics) and their secure handling. In turn, this requires security certificates to be set up for all the employees of the administration.
2.	workflow management of the process to request and get building licenses
	The process of requesting a license to build anything is quite a lengthy one, because several kind of documents need to be supplied by the requestor and approved by different public offices. The project aims to drastically reduce this time by allowing for electronic submission of both the schematic and the documents (e.g. via Internet between the technician who designed the building and the public office).
	Obviously, there is a strong need to authenticate the submission, to preserve the documents from illegal modifications, and to verify the approvals. This application requires security certificates to be set up for the public officers and for a selected number of technical professionals.
3.	electronic request and delivery of documents between the students and the University administration
	For example, this includes enrolment, delivery of various kind of certificates, and textbooks rental from the University library. Everything should be done directly from home via an Internet connection, with no need to reach the campus.
	To accomplish these tasks in a safe way, security certificates need to be established for all the students and the employees of the University.
	
The work will be carried out in the following steps:

1. Selection of the application(s) to be supported
Based on a careful analysis of the users’ needs, their operating environment, and the tools available from the other ICE-TEL workpackages, one (or possibly more, if funding permits) of the above mentioned applications will be selected.

2. Integration of security tools into the application
The selected application will receive a security boost by substituting some modules with security-aware ones. Of special interests are multimedia MUAs with authentication and privacy. To simplify the access to non-technical users and to give a common look-and-feel across various platforms, a WWW interface will be provided. This will result  in the set up of a demonstrator

3. Field trial
The demonstrator built in the previous task will be initially verified with a small user group, to perform a thorough on-field bug checking and to listen to their suggestions for user-interface improvement from everyday use. To this aim a mixed steering group will be organised, composed of both developers and users. It will have the task to decide between contrasting proposals, as well as to decide when to move from the verification to the demonstration phase (as a rough idea, we would move to this phase when for three months there have been no major change to the demonstrator).
In the demonstration phase, the application will be deployed on a large scale (e.g. a whole administration) to evaluate its cost-effectiveness and user-friendliness. This evaluation will be done both by surveying user satisfaction and by comparing the number of documents managed by the new and the old systems.
Deliverables
Analysis of the users’ needs and on the requirements of the candidate applications, installation of the demonstrators for the selected applications, final report on the field trials

3.4.14	
Deliverables List

Project ref.	Sector	Date	Sheet	
1005	Research	October 1, 1995	1  of  1	

Deliverable
ID
(a)	Title	Delivery 
date
(b)	Nature

(c)	Dis-semination
Level
(d)	Type
PD or X
(e)	Work-Package
ID
(f)	
D0	Initial Software Deliv.	3	TO	RP	PD	WP4, WP5, WP6	
D1	ICE-TEL Certification Infrastructure Specification	6	SP	PU	PD	WP3	
D2	Report on Firewalls	6	RE	PU	PD	WP3	
D3	Report on National Security Regulations	6	RE	PU	PD	WP3	
D4	ICE-TEL S/W Deliv - I	9	TO	LI	PD	WP2, WP3, WP4, WP5, WP6, WP8, WP10	
D5	User Feedback I	9	RE	LI	X	WP11	
D6	Specification of the Guardian DSA	12	SP	PU	PD	WP7	
D7	Report and Specification on WWW Security	12	RE	PU	PD	WP2, WP9	
D8	ICE-TEL S/W Deliv -II	15	TO	PU	PD	WP2, WP3, WP4, WP5, WP6, WP7, WP8, WP9, WP10	
D9	User Feedback - II	15	RE	LI	X	WP2, WP11, WP12, WP13	
D10	ICE-TEL S/W Deliv -III	21	TO	PU	PD	WP2, WP3, WP5, WP7, WP8, WP9, WP10	
D11	User Feedback - III	21	RE	LI	X	WP2, WP11, WP12, WP13	
D12	ICE-TEL S/W Deliv -IV	24	TO	PU	PD	WP2, WP3, WP5, WP6, WP7, WP8, WP9, WP10	
D13	User Feedback - IV	24	RE	LI	X	WP2, WP11, WP12, WP13	

Notes
(a) 	ID of the form 'Dn.m' where n = n in 'WPn' : n = number of the work package and m = deliverable number for that work package i.e.  m = 1 - <total number of deliverables in WPn> - in chronological order down the page
(b) 	of the form:  'n' where n = 01 - ~ 36 i.e. project not calendar months
(c) 	PR = Prototype (Demonstrator) : RE = Report : SP = Specification : TO = Tool : OT = Other.
	PR, TO & OT will have an associated document for contractual purposes.  All deliverables will be accompanied by a 'peer' review report
(d)	PU = Public Usage of the result : LI = limited to programme participants : RP = restricted to project participants (Public documents shall be of a professional standard in a form suitable for publication)
(e) 	PD = A 'Project deliverable' as defined in Article 4 of the contract : X = Submitted on request deliverables where appropriate available for review or dissemination purposes limited to participants of the TELEMATICS APPLICATIONS Programme
(f) ID of the form: 'WPn' where n = 01- ~10