4.1 Standards

4.1.1 Mobile Agent System Interoperability Facilities (MASIF)

Da MASA ein zur MASIF-Spezifikation ([OMG 98-03-09]) konformes Agentensystem darstellt, sollen nun die dort gestellten Bedingungen an eine Sicherheitsarchitektur aufgezeigt werden.

Die in der MASIF-Spezifikation durchgeführte allgemeine Analyse der Situation, der Gefahren und die daraus resultierenden generellen Anforderungen werden im wesentlichen bereits durch Kap. 2.1 abgedeckt und wird hier nicht wiederholt.

4.1.1.1 Authentisierung

Zur Authentisierung werden in der Spezifikation nur sehr generische Aussagen getroffen: MASIF postuliert einen Algorithmus, den sog. ``Authenticator'', mit dem es möglich ist Agenten zu authentisieren. Nähere Angaben, wie solch ein Authenticator die Authentisierung durchzuführen hat, werden nicht gemacht.

4.1.1.2 Autorisierung

Anforderungen an die Autorisierung in SmA werden in MASIF ebenso allgemein beschrieben, wie das für Authentisierung der Fall ist. Im wesentlichen werden dabei folgende Aussagen gemacht, die als Empfehlungen und nicht als Vorschriften formuliert sind:

• Ein Menge von Regeln wird erstellt und als ``Security Policy'' definiert.

• Sowohl Agenten als auch Agentensysteme können eine oder mehrere Security Policies haben.

• Die Entscheidung welche Security Policy anzuwenden ist, kann von verschiedenen Faktoren abhängen, die aber nicht konkret festgelegt werden.

• Eine Security Policy enthält u.a. Regeln zur Erteilung bzw. Einschränkung der Möglichkeiten von Agenten, Limitierung des Ressourcenverbrauchs, Erteilung bzw. Verweigerung von Zugriffen.

• Für die Durchsetzung einer Security Policy ist ein ``Security Service'' verantwortlich.

4.1.1.3 Anforderungen an ein sicheres Agentensystem

Explizite Forderungen der Spezifikation an den Security Service sind im Abschnitt ``Security Service Requirements'' verzeichnet.

Der Begriff ``Credentials'' bezeichnet dabei allgemein alle sicherheitsrelevanten Attribute eines Objekts, wie z.B. die Identität oder Berechtigungen für die Ausführung bestimmter Aktionen.

Die gestellten Forderungen lauten konkret:

1. Authentisierung von Clients bei der entfernten Erzeugung von Agenten
   1. Der Security Service muß Clients authentisieren.

   2. Basierend auf der Identität des Clients werden die Credentials des neu erzeugten Agenten gesetzt.

   3. Die Credentials des Clients bestimmen, welche Security Policy anzuwenden ist.

2. Authentisierung von Agentensystemen
   1. Agentensysteme müssen sich wechselseitig authentisieren können.

   2. Der Authentisierungsvorgang muß ohne Interaktion eines Benutzers erfolgen können.

3. Authentisierung von Agenten und Delegation
   1. Migriert ein Agent, so muß dieser seine Credentials mit sich führen.

   2. Credentials können am Ziel-Agentensystem verändert werden, abhängig vom Ergebnis der Authentisierung.

   3. Wenn ein Agent einen entfernten Methoden-Aufruf durchführt, müssen die Credentials dieses Aufrufs jene des Agenten sein.

4. Security Policies von Agenten und Agentensystemen
   1. Ein Agent sollte den Zugriff auf seine Methoden kontrollieren können.

   2. Der Agent oder sein Agentensystem muß Zugriffskontrollmechanismen einrichten und ihre Einhaltung durchsetzten.

   3. Werden Zugriffskontrollmechanismen von einem Agenten oder einem Agentensystem selbst definiert und selbst durchgesetzt, so müssen die Credentials eines entfernten Agenten dem Ziel Agentensystem bekannt sein.

   4. Alternativ kann die Durchsetzung der Zugriffskontrollmechanismen von der Kommunikations-Infrastruktur übernommen werden.

5. Integrität, Vertraulichkeit, Replay Detection und Authentisierung
   1. Der Initiator eines Kommunikationsvorgangs muß die Möglichkeit haben Anforderungen an Integrität, Vertraulichkeit und Art der Authentisierung zu spezifizieren.

   2. Die Kommunikations-Infrastruktur muß diese Anforderungen beachten, oder, falls die Anforderungen nicht erfüllt werden können, einen Fehler melden.

4.1.1.4 CORBA als Kommunikationsplattform

Da MASA CORBA als Kommunikationsplattform nutzt, ist weiterhin das Kapitel ``Security Service'' (2.4) der MASIF-Spezifikation zu beachten. Dort wird detailliert beschrieben, wie durch Nutzung von CORBA als Kommunikationsplattform die geforderten Security Service Requirements realisiert werden können.

Hierzu werden zunächst die aktuell verfügbaren CORBA-Implementierungen in drei Kategorien eingeteilt:

• Keine Sicherheits-Dienste (Kategorie 1): Es sind weder proprietäre noch standardisierte Sicherheits-Dienste implementiert.

• Proprietäre Sicherheits-Dienste (Kategorie 2): Produktspezifische Mechanismen zur Authentisierung und Zugriffskontrolle sind vorhanden, umfassen jedoch nicht den ORB selbst.

• Standardisierte Sicherheits-Dienste (Kategorie 3): Es ist ein ORB implementiert, der konform zur CORBA Security Services Specification (vgl. Abschnitt 4.1.2) ist.

Anschließend wird erörtert, wie die vorher an den Security Service gestellten Anforderungen im Rahmen der CORBA Security Services Specification erfüllt werden können. Faßt man die Diskussion zusammen, wird festgestellt, daß eine MASIF-konforme Implementierung für die Erfüllung der Security Service Requirements unter Nutzung von CORBA als Kommunikationsplattform, zwingend auf einen ORB mit ``Security Functionality Level 2'' (vgl. Abschnitt 4.1.2) angewiesen ist.

MASIF weist jedoch darauf hin, daß selbst dies nicht ausreichend ist, um alle gestellten Anforderungen zu erfüllen (aus [OMG 98-03-09]):

``Although CORBA security does not currently meet all the needs of mobile agent technology, the MAF implementation must use available CORBA security to satisfy its security needs. Future versions of CORBA security should address these issues.''

4.1.2 CORBA Security Service Specification

Die CORBA Security Service Specification ([OMG 98-12-17]) ist ein CORBA-Basisservice, der Sicherheitsfunktionen beschreibt und Schnittstellendefinitionen enthält, die ein CORBA Security-konformer ORB implementieren muß.

Wegen des großen Umfangs der Spezifikation und weil zum jetzigen Zeitpunkt kein Produkt erhältlich ist, daß die CORBA Security Service Specification auch nur annähernd vollständig in Java implementiert, wird an dieser Stelle nur ein sehr knappes Resümee gegeben.

Aufbauend auf einem sehr abstraktem Sicherheitsmodell, definiert die Spezifikation Schnittstellen

• die ein ORB für die Implementierung von Anwendungen bereitstellen muß. Dabei wird generell zwischen Anwendungen, die aktiv selbst keine Sicherheitsmaßnahme ergreifen oder nutzen (``security unaware'') und solchen, die eigene Sicherheitsmaßnahmen implementieren und nutzen (``security aware''), unterschieden;

• für die Administration der Sicherheitseigenschaften eines ORB;

• für die Implementierung eines sicheren ORB.

Im weiteren wird beschrieben, wie existierende Protokolle (z.B. Kerberos oder SSL) für die Implementierung eines sicheren ORB eingesetzt werden können.

Generell muß ein ORB aber nicht alle in der Spezifikation geforderten Eigenschaften besitzen. Die prinzipielle Konformität wird in zwei Kategorien eingeteilt:

Security Functionality Level 1:

Umfaßt nur Funktionalität, mit der im wesentlichen Anwendungen implementiert werden können, die selbst ``security unaware'' sind.

Security Functionality Level 2:

Umschließt auch Funktionalität und Schnittstellen, die die Erstellung von Anwendungen erlauben, die ``security aware'' sind.

Ein SmA muß eigene, individuelle Schutzmaßnahmen ergreifen, weil die CORBA Security Service Specification dessen Anforderungen nicht erfüllen kann (vgl. Anschnitt 4.1.1). Deshalb ist ein SmA eine Anwendung, die ``security aware'' ist. Demnach muß, für die Realisierung, ein ORB die Security Functionality Level 2 erfüllen, um die Sicherheitsanforderungen im Rahmen der CORBA Security Service Specification erfüllen zu können.