{"content":[{"text":"2. APPLICATIONS AND SECURITY","bbox":{"left":0.119042,"top":0.112535,"width":0.39157200000000003,"height":0.023027999999999993}},{"text":"MIDAS is concerned with providing management facilities for distributed applications and \n services. Such applications may, in fact, operate across several networks run by several \n administrations; this could be the case, for example, in a geographically-spread X.400 network \n operating across a mixture of public and private networks. In general, we must assume that \n such underlying networks are insecure; that management information may be destroyed or \n stolen, that malicious third-parties may be able to gain access to the networks and disrupt \n management activities in a variety of ways. In such cases, the management and security \n facilities we require must be placed in the parts of the system we can trust - in the \n applications themselves. \n Secure management is especially important for MIDAS since we are keen to demonstrate \n control of applications and services through the use of the OSI Common Management \n Information Service (CMIS)[1] and not simply the monitoring of activity which characterises \n most SNMP-based management. The applications we wish to control often have native \n security facilities; for example X.400 offers a range of services including confidentiality, non- \n repudiation etc. If such an application is to be controlled remotely then there is a danger that \n these security services may be undermined by a third party through subversion of the \n management exchange. In the particular case of X.400 for example, subversion of this control \n could allow a third-party to cause mail for one user to be delivered to another. In fact, the \n native security services will be only as strong as the security services that are provided for \n management. \n MIDAS, like most ESPRIT projects, is keen to develop technology which can be deployed \n commercially in the short to medium term. Consequently we have sought security solutions \n which can readily be introduced into today’s OSI environment.","bbox":{"left":0.119041,"top":0.148806,"width":0.762402,"height":0.38456900000000005}},{"text":"3. BACKGROUND WORK","bbox":{"left":0.119051,"top":0.546929,"width":0.283049,"height":0.02302800000000005}},{"text":"Issues of security in distributed applications have been studied extensively and a number \n of aspects have now reached the stage of standardisation by various bodies. Given our contexts \n of Open Systems and Management we have drawn heavily on the following;","bbox":{"left":0.119052,"top":0.583057,"width":0.7623509999999999,"height":0.052219000000000015}},{"text":"• ISO/ITU work on authentication through the use of public key encryption and trusted \n \"certification authorities\" [2]. This approach to security has been adopted by several OSI \n applications so there is a strong motivation to use it for management. \n • ISO/ITU work on access control both in general [3] and specifically in the case of \n management [4]. \n • Internet work on security in SNMPv2 [5]. \n • The US \"OSI Implementors Workshop\" (OIW) \"Stable Agreements\" which attempt to \n make workable selections from amongst the efforts of the standards bodies [6]. \n • The OMNIPoint/NM Forum security work [7] which draws heavily on the OIW work.","bbox":{"left":0.130546,"top":0.64947,"width":0.750998,"height":0.15183900000000006}},{"text":"Unfortunately, at the present time, none of this work completely satisfies our requirements. \n This is especially true when one comes to the detail of implementation where one frequently \n discovers gaps in specification or unresolved inconsistencies. When this has occurred we have \n had to make our own choices. Many of the problems we have encountered will be resolved","bbox":{"left":0.119051,"top":0.815503,"width":0.762392,"height":0.06889400000000001}}],"images_bbox":[],"images_bbox_not_text_overlap":[]}