2 TAPI 2.1 - Hochschule Mittweida

Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Hochschule Mittweida, Gruppe Telecom, Statusbericht Mai’98:
TAPI
- TAPI 2.1 – Konzept und Sicherheitsmechanismen
- Vergabe von arbeitsplatzbezogenen Berechtigungen in einer TAPIUmgebung
- Ausblick zu TAPI 3.0
Statusbericht Mai‘98, Teil: TAPI
2
Inhaltsverzeichnis
Inhaltsverzeichnis
1
Überblick................................................................................................................ 5
2
TAPI 2.1 ................................................................................................................ 5
2.1
2.2
2.3
Einleitung .................................................................................................................. 5
Neuerungen bei TAPI 2.0 und TAPI 2.1 .................................................................... 5
Client-Server-Architektur von TAPI 2.1 ...................................................................... 6
2.3.1
2.3.2
2.4
Anwendungsgebiete von TAPI 2.1............................................................................. 8
2.4.1
2.4.2
2.4.3
2.4.4
2.5
3
Funktionsweise .................................................................................................................11
Client Management API ....................................................................................................12
TAPI Administaion Tool [TAPI Admin] ..............................................................................12
User Interface (UI) ................................................................................................... 14
Remote Procedure Call (RPC ) ............................................................................... 16
2.7.1
2.7.2
2.7.3
2.7.4
2.7.5
2.8
TAPI 2.1 auf Windows 95 und NT Client Workstations (ohne Server) ...............................8
TAPI 2.1 in einem Windows NT Netzwerk ..........................................................................9
Einfügen von TAPI 2.1 in eine NetWare-Umgebung ..........................................................9
TAPI 2.1 und JTAPI ..........................................................................................................10
TAPI Client Management [TAPI ClMgmt] ................................................................ 10
2.5.1
2.5.2
2.5.3
2.6
2.7
Komponenten der Client-Seite ............................................................................................6
Komponenten der Server-Seite (Telefonieserver) ..............................................................7
Standardisierung ...............................................................................................................16
Funktionsweise .................................................................................................................16
Sicherheitsoptionen von RPC unter Windows ..................................................................18
Verwendetes RPC-Transportprotokoll für TAPI 2.1 ..........................................................18
Verwendete RPC-Sicherheitsmechanismen bei TAPI 2.1 ................................................19
Zusammenfassung zu TAPI 2.1 .............................................................................. 20
Arbeitsplatzbezogene Berechtigungen ................................................................ 20
3.1
Bereits vorgestellte Sicherheitsmechanismen ......................................................... 20
3.1.1
3.1.2
3.1.3
3.2
3.3
3.4
Einleitung / Problemstellung .................................................................................... 21
Lösungsansatz ........................................................................................................ 22
Anwendbarkeit für TAPI und TSAPI ........................................................................ 23
3.4.1
3.4.2
3.4.3
3.5
Verwendete APIs (Funktionen) .........................................................................................31
Mapping der Funktionalität ................................................................................................31
Weitere Sicherheitsprobleme .................................................................................. 32
3.7.1
3.7.2
3.8
Gliederung ........................................................................................................................25
Grundlagen zum Sicherheitsmechanismus ......................................................................25
Einleitung des Sicherheitsmechanismus ..........................................................................25
Validierung der Absenderadresse (IP-Adresse) ...............................................................26
Überprüfung der Computer-Telefon-Bindung (Variante 1) ...............................................27
Überprüfung der Computer-Telefon-Bindung (Variante 2) ...............................................29
Rechnerauthentikation bei den folgenden Sessions .........................................................30
Realisierung für TAPI 2.1 ........................................................................................ 31
3.6.1
3.6.2
3.7
TAPI 1.0 bis TAPI 2.0 .......................................................................................................23
TAPI 2.1 ............................................................................................................................24
Anwendbarkeit für TSAPI..................................................................................................24
Spezifikation des Sicherheitsmechanismus ............................................................. 25
3.5.1
3.5.2
3.5.3
3.5.4
3.5.5
3.5.6
3.5.7
3.6
Geheimhaltung von Nutzerdaten [Stat 12/96] ...................................................................21
Authentikation von Anwendungsprogrammen ..................................................................21
Nutzerauthentikation .........................................................................................................21
DHCP (Dynamic Host Configuration Protocol) .................................................................32
Sicherheitsmaßnahmen beim Monitoring von fremden Endgeräten: ...............................32
Zusammenfassung .................................................................................................. 33
Statusbericht Mai‘98, Teil: TAPI
Inhaltsverzeichnis Error! Use the Home tab to apply Überschrift 1 to the text that you want to
appear here.
3
4
TAPI 3.0 .............................................................................................................. 34
4.1
4.2
Einleitung ................................................................................................................ 34
Architektur von TAPI 3.0.......................................................................................... 34
4.2.1
4.2.2
4.2.3
4.2.4
4.3
IP-Telefonie nach H.323 .......................................................................................... 36
4.3.1
4.3.2
4.4
4.5
4.6
4.7
4.8
5
TAPI 3.0 COM API ............................................................................................................35
TAPI Server ......................................................................................................................36
Telephony Service Provider ..............................................................................................36
Media Stream Provider .....................................................................................................36
Was ist H.323? .................................................................................................................36
H.323 Service Provider für TAPI 3.0 .................................................................................37
IP-Multicast Conferencing ....................................................................................... 38
Gatekeeper / Windows NT 5.0 Active Directory ....................................................... 39
Quality of Service (QoS) .......................................................................................... 40
Einsatz von IP-Telefonie in einem Unternehmen ..................................................... 40
Zusammenfassung .................................................................................................. 41
Zusammenfassung und Weiterführung des Themas .......................................... 41
5.1
5.2
5.3
5.4
TAPI 2.1 .................................................................................................................. 41
Arbeitsplatzbezogene Berechtigungen .................................................................... 41
TAPI 3.0 .................................................................................................................. 42
Themen für weitere Forschungsarbeiten ................................................................. 42
Anhang A:
Anhang B:
Anhang C:
wichtige RPC-Parameter ..................................................................... 43
RPC - Authentication Levels ................................................................ 44
Sicherheitsrelevante RPC-Funktionen ................................................. 45
Abbildungs- und Tabellenverzeichnis ........................................................................ 46
Quellenverzeichnis .................................................................................................... 47
Statusbericht Mai‘98, Teil: TAPI
4
Abkürzungsverzeichnis
Abkürzungsverzeichnis
ACL
API
CSTA
CTI
DCE
DGV
DLL
ECMA
FAQ
IDL
ILS
IP
ITU-T
JTAPI
LDAP
MCU
NTS
OSF
PaCT
PDU
PBX
RPC
RTP
RTCP
SDK
SNMP
SP
TAPI
TCM-API
TCMAPP
TSAPI
TSP
UDP
WWW
Application Connectivity Link
Application Programming Interface
Computer-Supported Telecommunication Applications
Computer Telephony Integration
Distributed Computing Enviroment (defined by OSF)
DVA-gesteuerter Verbindungsaufbau
Dynamic Link Library (Windows)
European Computer Manufacturers Association
Frequently Asked Questions
Interface Description Language
Internet Locator Service
Internet Protocol
International Telecommunication Union (Sector Telecommunication)
Java Telephony API
Lightweight Directory Access Protocol
Multipoint Control Unit
Novell Telephony Server
Open Software Foundation
PBX and Computer Teaming
Protocol Data Unit
Private Branche Exchange
Remote Procedure Call
Real-Time Transport Protocol
RTP Control Protocol
Software Development Kit
Simple Network Management Protocol
Service Provider
Telephony Application Programming Interface
TAPI Client Management API
TAPI Client Management Application (Administration Tool)
Telephony Services API
Telephony Service Provider
User Datagram Protocol
World Wide Web
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
5
1 Überblick
Gegenstand dieses Forschungsberichtes ist die Darlegung des Entwicklungsstandes von TAPI, wobei
auf die aktuelle TAPI-Versionen 2.1 und die zukünftige Version 3.0 eingegangen wird. Der Schwerpunkt bei den Betrachtungen zu TAPI 2.1 liegt auf den Sicherheitsmechanismen und wie diese in einer
Client-Server-Umgebung ausgebaut werden können.
Das Kapitel 1 gibt eine Einführung in die aktuelle TAPI-Version 2.1, die eine Client-Server-Archtitekur,
vergleichbar dem Novell Telephony Server, bereitstellt. Die wesentlichen Änderungen zu TAPI 2.0
werden beschrieben. Anschließend wird auf die Funktion der einzelnen Komponenten eingegangen
und deren Sicherheitsmechanismen bewertet.
Im Kapitel 2 wird ein Sicherheitsmechanismus zur Vergabe von arbeitsplatzbezogenen Berechtigungen
vorgestellt und untersucht, wie er sich in unterschiedlichen TAPI-Umgebungen realisieren läßt. Der
Sicherheitsmechanismus kann die sonst übliche Nutzerauthentikation ersetzen.
Das 3. Kapitel zeigt die aktuelle Entwicklung von TAPI in Richtung IP-Telefonie. Mit Windows NT 5.0
wird die neue TAPI-Version 3.0 ausgeliefert, die eine einheitliche Schnittstelle für die klassische
Telefonie und IP-Telefonie über IP-basierte Netzwerke (LAN) anbietet. TAPI 3.0 stellt somit eine
Plattform bereit, die in Konkurrenz zur klassischen Nebenstellentechnik steht.
2 TAPI 2.1
2.1 Einleitung
Nach den TAPI Spezifikation 1.3 bis 2.0 hat Microsoft Mitte letzen Jahres die TAPI 2.1 Spezifikation
veröffentlicht. Mit der Version 2.1 unterstützt TAPI erstmalig Telefoniedienste in einer Client-ServerUmgebung, vergleichbar mit denen des Novell Telephony Servers. Bisher war TAPI speziell für FirstParty-Anwendungen ausgelegt, wobei der Hersteller eines Service Providers trotzdem die Möglichkeit
hatte, seine Dienste über eine Third-Party-Umgebung (Client + Telefonieserver + PBX) zu realisieren.
Dies erforderte vom Hersteller aber einen relativ hohen Aufwand für die Implementierung eines
Telefonieservers und der erforderlichen Client-Server-Kommunikation. Dieser Aufwand entfällt mit dem
Einsatz von TAPI 2.1, da die genannten Komponenten dort bereits enthalten sind.
In diesem Kapitel sollen die Neuerungen in TAPI 2.1 kurz vorgestellt werden. Da TAPI 2.1 auf den
Erweiterungen von TAPI 2.0 aufbaut, wird auch auf diese mit eingegangen. Als Schwerpunkt wird
anschließend das Sicherheitskonzept von TAPI 2.1 näher betrachtet.
2.2 Neuerungen bei TAPI 2.0 und TAPI 2.1
TAPI 2.0 wurde 1996 veröffentlicht und mit Windows NT Server/Workstation 4.0 ausgeliefert. Einige
Erweiterungen, die bei TAPI 2.0 vorgenommen wurden können erst mit den Client-ServerKomponenten von TAPI 2.1 sinnvoll genutzt werden. Zu den TAPI 2.0 Erweiterungen, die auf TAPI 2.1
abzielten, zählen speziell:
 Zusätzliche Funktionen für die Unterstützung von Call Center Anwendungen.
 ACD Queues (ACD = Automatic Call Distribution),
 Verwaltung von Agents,
 Predictive Dialing, Call Routing, Call Data, Call Treatment.
 Zusätzliche Funktionen zur Trennung von Service Provider und User Interface (Dialoge), z.B. die
Funktion TUISPI_lineConfigDialog. Auf das User Interface Konzept wird später noch eingegangen.
TAPI 2.1 bietet als wesentliche Neuerungen:
Statusbericht Mai‘98, Teil: TAPI
6
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
 Mit TAPI 2.1 wird erstmalig Windows 95, Windows NT Workstation 4.0 und Windows NT Server 4.0
durch eine einheitliche Version (TAPI 2.1) unterstützt. Bisher wurde unter Windows 95 TAPI 1.4
und unter Windows NT TAPI 2.0 verwendet.
 Mit TAPI 2.1 wird eine Telefonieunterstützung in einer Client-Server-Umgebung angeboten.
Microsoft stellt dafür folgende Komponenten bereit:
 Einen Remote Service Provider für die Client-Seite. Dieser realisiert über das Netzwerk
die Verbindung zum TAPI-Server auf einem Windows NT Server.
 Der TAPI Server bietet ein Client Management API an, über das zusätzliche Funktionen
eingebunden werden können, unabhängig von einem Service Provider. Mögliche Funktionen sind z.B.: Logging und Monitoring oder auch ein erweiterter Zugriffsschutz auf
Endgeräte.
 Über einen TAPI Client Manager werden grundlegende Funktionen für die Verwaltung von
TAPI-Nutzern angeboten. Bekannten Nutzern einer Windows NT Server Domain können
mit dem TAPI Client Manager Berechtigungen für Endgeräte zugewiesen werden.
2.3 Client-Server-Architektur von TAPI 2.1
Als eine wesentliche Erweiterung von TAPI 2.1 soll hier deren Client-Server-Architektur vorgestellt
werden. Die Abbildung 1 zeigt dazu das Zusammenspiel der einzelnen TAPI 2.1 Komponenten, den
Komponenten des Betriebssystems und der Telefonieanbieter.
Client
(Windows 95, NT)
Server
(Windows NT)
PBX
CTI-Link
LAN
TAPI Anw endung
Administration
Tool
TAPI
TAPI32.DLL
TAPISRV.EXE
TSPI
RemoteSP.DLL
TAPISRV.EXE
TCM-API
TSec.DLL
RPC_RT.DLL
RPC_RT.DLL
Transport
Transport
LAN
Telefonieanbieter
Microsoft TAPI 2.1
Microsoft Windows
TSPI
Service
Provider
Client
Management DLLs
PBX
CTI-Link
TAPI
TSPI
TAPISRV
RemoteSP
RPC_RT
TCM-API
= Telephony Application Programming Interface
= Telephony Service Provider Interface
= TAPI Server
= Remote Service Provider
= Remote Procedure Call Run Time
= TAPI Client Management API
Abbildung 1: Client-Server-Architektur bei TAPI 2.1
In den beiden folgenden Abschnitten wird kurz die Funktionalität der einzelnen Komponenten
vorgestellt:
2.3.1 Komponenten der Client-Seite
Die TAPI32.DLL stellt die TAPI-Schnittstelle zur Anwendung bereit, sie erbringt keine spezifische
Client-Server-Funktionalität.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
7
Der TAPISRV(.EXE) = TAPI-Server ist identisch mit dem TAPISRV auf der Server-Seite, erst über das
Setup wird entschieden, das er Client-Funktionalität übernehmen soll. Zur Unterscheidung mit der
Server-Seite wird folgend ClientTAPISRV als Bezeichnung verwendet. Der ClientTAPISRV stellt das
Telephony Service Provider Interface (TSPI) für einen bzw. mehrere Provider bereit. In der Abbildung
wurde nur der mitgelieferte Remote Service Provider dargestellt; es kann aber auch ein anderer
Service Provider (ohne Client-Server-Funktionalität) verwendet werden, der z.B. auf eine lokale ISDNKarte zugreift. Der ClientTAPISRV stellt keine spezifische Client-Server-Funktionalität bereit (diese
erbringt der Remote Service Provider).
Der REMOTESP = Remote Service Provider; verhält sich gegenüber dem ClientTAPISRV wie ein
„normaler“ Service Provider, nur daß er seine Dienste „remote“ über den TAPISRV der Server-Seite
realisiert. Der Remote SP kommuniziert mit dem TAPISRV über Remote Procedure Calls. Auf
Funktionsweise und Sicherheitsmerkmale von RPCs wird folgend noch eingegangen.
Die RPC_RT.DLL (Remote Procedure Call Run Time) erbringt das RPC-Protokoll. Die RPC_RT.DLL
wird ebenfalls von Microsoft geliefert, gehört aber nicht mit zu TAPI 2.1, sondern zum Betriebssystem.
Die RPC_RT.DLL benutzt für den Transport (Client-Server-Kommunikation) einen vorhandenen
Kommunikationsstack (z.B. TCP/IP).
2.3.2 Komponenten der Server-Seite (Telefonieserver)
Der TAPISRV(.EXE) = TAPI-Server stellt die Funktionalität eines Telefonieservers, vergleichbar mit
dem Novell Telephony Server, bereit.
 Mit dem Remote Service Provider des Clients kommuniziert er über Remote Procedure Calls.
 Analog zur Client-Seite stellt er das Telephony Service Provider Interface (TSPI) bereit, das hier
aber von einem „realen“ Service Provider bedient wird.
 Für zusätzliche Management-Funktionen (unabhängig vom Service Provider) stellt der TAPISRV
ein Client Management API (TCM-API1) bereit.
 Er legt das Sicherheitslevel für den Remote Procedure Call fest (z.B. Nutzerauthentikation).
Die RPC-Run-Time erbringt:
 Das RPC-Protokoll,
 Über das RPC-Protokoll wird auch die Nutzerauthentikation realisiert.
Für die Komponenten RPC_RT.DLL und Transport gelten die gleichen Aussagen wie zur Client-Seite.
Der Service Provider erbringt das Mapping vom TSP-Interface auf eine spezielle Telefonie-Hardware
(z.B. HICOM 300). Der Service Provider muß u.a. folgende Fähigkeiten aufweisen:
 Er muß TAPI 2.0 oder TAPI 2.1 – kompatibel sein.
 Er muß gleichzeitig mehrere lines unterstützen.
 Für einen direkten Dialog mit einem Client-User ist das User Interface (UI) zu verwenden; auf das
UI wird in Abschnitt 2.6 eingegangen.
Über eine oder mehrere Client Management DLLs können zusätzliche Management-Funktionen
angeboten werden. Eine Client Management DLL kann vom Hersteller eines Service Providers oder
auch von einem einen anderen Hersteller angeboten werden. Von Microsoft wird eine Client Management DLL (TSEC.DLL) geliefert, die eine Administrierung von Endgeräteberechtigungen zu bekannten
Nutzern erlaubt. Die TSEC.DLL wird über ein Administration Tool (TCMAPP.EXE) konfiguriert.
1
Bezeichnung wurde vom Autor gewählt
Statusbericht Mai‘98, Teil: TAPI
8
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
2.4 Anwendungsgebiete von TAPI 2.1
2.4.1 TAPI 2.1 auf Windows 95 und NT Client Workstations (ohne Server)
Bei diesem Einsatzszenario wird davon ausgegangen, daß die TAPI 2.1 Komponenten nur auf den
Client Workstations installiert werden; die Client-Server Funktionalität von TAPI 2.1 wird dabei nicht
ausgenutzt. Um trotzdem Telefoniedienste in einer PaCT-Umgebung anbieten zu können, ist eine
Konfiguration nach Abbildung 2 erforderlich, die auf einem Telefonieserver eines beliebigen Anbieters
basiert. Das entsprechende Szenario wurde in den vergangenen Statusberichten am Beispiel des
ACL-Servers beschrieben.
Der Einsatz von TAPI 2.1 anstelle von älteren TAPI-Versionen bringt den Vorteil, daß auf Windows 95
und Windows NT Clients eine einheitliche TAPI-Version eingesetzt werden kann. Bisher wurde unter
Windows 95 TAPI 1.4 und unter Windows NT TAPI 2.0 verwendet. Ein Vorteil ergibt sich speziell für
die Hersteller von Service Providern, die jetzt eine einheitliche Version für Windows 95 und Windows
NT anbieten können.  Einsparung von Entwicklungskosten
Da Windows 3.1x nicht durch TAPI 2.1 unterstützt wird, ist für diese Clients weiterhin ein TAPI 1.3
Service Provider bereitzustellen.
Client
(Windows 95, NT)
beliebiger
Telefonieserver
PBX
CTI-Link
LAN
TAPI Anw endung
TAPI
TAPI32.DLL
TAPISRV.EXE
TSPI
Service Provider
Telefonieserver
z.B. TCP/IP
z.B. TCP/IP
PBX
CTI-Treiber
LAN
Telefonieanbieter
Microsoft TAPI 2.1
TAPI
TSPI
= Telephony Application Programming Interface
= Telephony Service Provider Interface
CTI-Link
Betriebssystem
Abbildung 2: Einsatz von TAPI 2.1 mit fremden Telefonieserver
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
9
2.4.2 TAPI 2.1 in einem Windows NT Netzwerk
Um die Client-Server-Funktionalität von TAPI 2.1 zu nutzen, ist ein Windows NT Netzwerk erforderlich.
Folgende Randbedingungen müssen erfüllt sein:

Der TAPI-Server muß zu einer Windows NT Domain gehören.

Die Clients müssen mit einem gültigen NT Domain Account angemeldet sein. Wenn der Client
einen identischen Account am lokalen Rechner und in der Domain besitzt, ist eine Anmeldung am
lokalen Rechner ausreichend; die Überprüfung des Domain Accounts wird dann beim Start von
TAPI vorgenommen.

Die Client-Workstations müssen in der Domain registriert sein. Diese Einstellung erfolgt in
Windows NT über: Eigenschaften der Netzwerkumgebung – Identifikation – Ändern – Domäne und
Administrator-Account angeben.
Im TAPI 2.1 SDK [TAPI 2.1 SDK - 1] enthaltene Aussage, die dieses Thema berühren:
The telephony server must run Windows NT Server 4.0 - Service Pack 3 or later, and must belong to a
domain.
Kommentar: Der TAPI-Server muß einer Windows NT Domain angehören.
Users: must be logged on using a valid domain account.
NT Domain
Domain Server
TAPI 2.1 Server
NT
NT
PBX
administrierte
TAPI 2.1 Clients
NT Domain
Domain Server
Workstations
NT
User Accounts
Abbildung 3: TAPI 2.1 Server in einer Windows NT Domain Umgebung
Wenn bereits ein Windows NT Netzwerk vorliegt, kann ein TAPI 2.1 Server relativ leicht in diese
Umgebung eingefügt werden. Als administrative Aufgabe sind im TAPI 2.1 Server die User Accounts
aus Domänen von Windows NT zu übernehmen und diesen Berechtigungen auf Endgeräte zuzuweisen.
2.4.3 Einfügen von TAPI 2.1 in eine NetWare-Umgebung
In diesem Abschnitt soll geklärt werden, ob NetWare Clients die Dienste eines TAPI 2.1 Servers
(Windows NT) nutzen können. Dieses Leistungsmerkmal hat durch die große Anzahl von bestehenden
Novell Netzwerken eine hohe Bedeutung. Aus Ausgangspunkt soll ein vorhandenes Novell Netzwerk
mit einer Vielzahl von User Accounts angenommen werden, das um einen TAPI 2.1 Server ergänzt
werden soll.
Unter der genannten Bedingung, daß die TAPI Clients (User + Workstation) einer Windows NT
Domain angehören müssen, ist parallel zum Novell Netzwerk ein Windows NT Netzwerk aufzubauen.
Prinzipiell ist es möglich, daß die TAPI Clients gleichzeitig Mitglied einer NetWare Domain und einer
Windows NT Domain sind.
Statusbericht Mai‘98, Teil: TAPI
10
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
NT Domain
neu
NT Domain Server
TAPI 2.1 Server
NT
NT
vorhanden
PBX
NetWare
Domain
administrierte
TAPI 2.1 Clients
NetWare Server
NetWare
Workstation
User Accounts
identische
User Accounts
physischer Loginbereich
Abbildung 4: Einfügen eines TAPI 2.1 Servers in eine Netware-Umgebung
Nachteile:

Der Betreiber muß einen NT-Server (Domain Server) mit einer entsprechenden Anzahl von ClientLizenzen erwerben (Kosten).

Ein Administrator muß dem NT-Server betreuen.
 Die User Accounts müssen auf beiden Systemen administriert werden (Aufwand).
Die genannten Nachteile dürften für die meisten Anwender mit Novell Netzwerk ausreichend sein, um
ein TAPI 2.1 System abzulehnen. Aus diesem Grund soll kurz betrachtet werden, welche Änderungen
an TAPI 2.1 vorzunehmen wären, um eine Einbindung in ein Novell Netzwerk zu vereinfachen. Die
Änderungen müßte Microsoft vornehmen.
Empfohlene Änderungen:

Der TAPI 2.1 Server sollte unabhängig von einer NT Domain (NT Netzwerk) laufen.

Die User Accounts für TAPI Clients sind von einem NetWare Server zu beziehen (Administrierung).

Zur Laufzeit sind die User auf dem NetWare Server zu überprüfen.
2.4.4 TAPI 2.1 und JTAPI
Ein weiterer wichtiger Punkt ist die Unterstützung des Java Telephony API (JTAPI). Mit einer proprietären Client-Server-Lösung, wie sie in [Stat 9/97] anhand des ACL-Servers vorgestellt wurde, ist eine
JTAPI-Untertützung für beliebige Plattformen möglich, indem über TCP/IP ein proprietäres Protokoll
gefahren wird.
In einer TAPI 2.1-Server-Umgebung ist diese Vorgehensweise nicht anwendbar, da hier TAPI als
Client-Schnittstelle vorgegeben wird. Ausgehend von TAPI kann natürlich ein Mapping zu JTAPI
erfolgen, wodurch aber eine Abhängigkeit von Windows als Client-Betriebssystem entsteht und somit
einer der Vorteile von JTAPI verloren geht. Dem Autor ist bisher noch kein Mapper von TAPI nach
JTAPI bekannt.
2.5 TAPI Client Management [TAPI ClMgmt]
In einer Client-Server Umgebung greifen die Clients auf Ressourcen des Servers zu. In den meisten
Anwendungsfällen unterliegt der Zugriff auf Ressourcen bestimmten Sicherheitsbeschränkungen, die
der Betreiber eines Servers festlegt.
Im Falle des TAPI-Servers können mehrere Clients die TAPI-Objekte (Ressourcen) der PBX (line,
phone, und call) steuern und überwachen. Aufgabe des TAPI Client Management ist es, Sicherheitsbeschränkungen für den Zugriff auf die TAPI-Objekte und Managementfunktionen zu ermöglichen.
Das TAPI Client Management ist die Management Architektur von TAPI 2.1, die auf der Definition
einer Schnittstelle beruht.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
11
2.5.1 Funktionsweise
Das TAPI Client Management wurde von Microsoft auf folgende Weise realisiert:




Die Komponente TAPISRV.EXE stellt ein definiertes Client Management API bereit, das von
beliebigen Dienstanbietern genutzt werden kann, indem sie eine Client Management DLL implementieren. Das API wird nur auf der Server-Seite genutzt.
In der Komponente TAPISRV.EXE ist somit keine Management-Funktionalität enthalten. Die
Management-Funktionalität wird nur auf der Server-Seite dazugelinkt (beim Client wird sie nicht
benötigt).
Über die Client Management DLLs lassen sich z.B. folgende Dienste realisieren:
Vergabe von Nutzerberechtigungen für Endgeräte,
Überprüfung von Rufnummern,
Rufnummermodifizierung für Least cost routing,
Logging von Ereignissen (z.B. calls).
Microsoft stellt selber eine Client Management DLL ( TSec.DLL) bereit, die Zugriffe auf Endgeräte
durch nicht berechtigte Nutzer zurückweist. Die Zugriffsrechte werden über die MicrosoftAnwendung TCMAPP.EXE vergeben, auf die im Abschnitt 2.5.3 näher eingegangen wird.
Vorteile der TAPI Client Management Architektur:


Die Funktionalität des Managements kann erweitert werden, ohne Änderungen an der
TAPISRV.EXE vornehmen zu müssen.
Beliebige Anbieter können Management-Dienste anbieten.
TAPI-Server auf einem Window s NT Server
TAPISRV.EXE
1
TCM-API
RPC_RT.DLL
Weg eines TSPIFunktionsaufrufes
(z.B. TSPI_lineMakecall)
TCM-API
2
3
TSec.DLL
optional
TCM-API
TSPI
4 Service
optional
Provider
Transport
Client Management DLLs
PBX
LAN
Telefonieanbieter
Microsoft TAPI 2.1
Microsoft Windows
TSPI
= Telephony Service Provider Interface
TAPISRV
= TAPI Server
RPC_RT
= Remote Procedure Call Run Time
TCM-API
= TAPI Client Management API
CTI-Link
Abbildung 5: Integriertes TAPI Client Management
Funktionsweise:
1. Der TAPI-Server empfängt über RPC einen TSPI-Funktionsaufruf eines Client-Remote-SPs. Der
RPC-Aufruf enthält neben den TSPI-Parametern auch Informationen zur Identität des Clients
(Nutzername, Domainname und Rechnername).
Bevor der TAPI-Server den TSPI-Aufruf an den Service Provider weiterleitet, werden über das
TCM-API alle angemeldeten Client Management DLLs aufgerufen, die anhand der übergebenen
Parameter Management-Operationen ausführen können.
2. Als erstes wird die TSec.DLL aufgerufen, die Endgerätezugriffe von nicht berechtigten Nutzern
zurückweist.
3. Anschließend werden alle angemeldeten Client Management DLLs, in der Reihenfolge ihrer
Anmeldung, aufgerufen. Eine Client Management DLL kann beispielsweise alle ausgeführten
TSPI_lineMakeCall protokollieren oder auch Änderungen an den TSPI-Parametern vornehmen.
4. Der Service Provider erhält den TSPI-Funktionsaufruf und führt diesen mit den Mitteln seiner
Telefoniehardware (PBX) aus.
Statusbericht Mai‘98, Teil: TAPI
12
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
2.5.2 Client Management API
Der Funktionsumfang des Client Management APIs ist im TAPI 2.1-SDK beschrieben. Um einen
Einblick in die prinzipielle Funktionsweise zu geben, werden die Funktionen
TAPICLIENT_ClientInitialize und TAPICLIENT_lineOpen vorgestellt.
TAPICLIENT_ClientInitialize
LONG CLIENTAPI TAPICLIENT_ClientInitialize(
LPCWSTR
pszDomainName,
LPCWSTR
pszUserName,
LPCWSTR
pszMachineName,
LPHMANAGEMENTCLIENT
phmClient );
Diese Funktion wird aufgerufen, wenn der Client eine TAPI-Session eröffnet (mit lineInitialize). Als
Parameter werden die Domain, der Nutzername und der Rechnername des Clients übergeben (als
String).
Die Client Management DLL hat daraufhin die Möglichkeit:

den Aufruf mit einer Fehlermeldung zurückzuweisen (z.B. unbekannter Nutzername) oder

mit OK zu beenden und ein Handle zur späteren Idendifizierung des angegebenen Clients
zurückzuliefern. Dieses Handle wird bei allen folgenden Funktionsaufrufen mit übergeben.
Beispiel: TAPICLIENT_ lineOpen
Diese Funktion wird aufgerufen sobald eine Clientanwendung lineOpen ausführt.
LONG CLIENTAPI TAPICLIENT_LineOpen(
HMANAGEMENTCLIENT
LPTAPIPERMANENTID
DWORD
DWORD
DWORD
DWORD
LPLINECALLPARAMS
LPDWORD
hmClient,
pID,
dwAPIVersion,
dwExtVersion,
dwPrivileges,
dwMediaModes,
lpCallParams,
lpdwSize
);
Der Parameter pID kennzeichnet die line (Endgerät), die der Client (hmClient) öffnen möchte. Die
Client Management DLL kann z.B. die Funktion mit einer Fehlermeldung beenden, wenn der Client
nicht für das gewünschte Endgerät berechtigt ist. Die Berechtigungen können einer Datenbank
entnommen werden.
Die Herkunft des Parameters dwPrivileges ist dem Autor unklar, da dieser bei TSPI_lineOpen nicht mit
an den Remote-SP übertragen wird. Die Parameter dwMediaModes und lpCallParams werden über die
Funktion TSPI_lineConditionalMediaDetection oder TSPI_lineSetDefaultMediaDetection übertragen.
2.5.3 TAPI Administaion Tool [TAPI Admin]
Microsoft liefert zum TAPI 2.1 SDK ein Administration Tool, mit dem registrierten Nutzern einer
Windows NT Domain Endgeräteberechtigungen zugewiesen werden können.
Das Administration Tool bildet mit der TSec.DLL (siehe Abbildung 6) eine funktionale Einheit.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Client
(Windows 95, NT)
Server
(Windows NT)
13
Windows NT
Domain Server
user
accounts
LAN
1
Administration
Tool
2 TAPI
TAPI32.DLL
TAPI Anw endung
TAPI
TAPI32.DLL
TAPISRV.EXE
TSPI
RemoteSP.DLL
TAPISRV.EXE
TCM-API
TSec.DLL
RPC_RT.DLL
RPC_RT.DLL
Transport
Transport
LAN
Telefonieanbieter
Microsoft TAPI 2.1
Microsoft Windows
TSPI
Service
Provider
3
PBX
CTI-Link
Client
Management DLLs
4
TAPI
TSPI
TAPISRV
RemoteSP
RPC_RT
TCM-API
= Telephony Application Programming Interface
= Telephony Service Provider Interface
= TAPI Server
= Remote Service Provider
= Remote Procedure Call Run Time
= TAPI Client Management API
[user, device]
[Max=3, 16739]
[Ute= 3, 23473]
[Fritz=3, 32732]
Datei:
TSec.INI
Abbildung 6: TAPI Administration Tool
Beschreibung:
1. Das Administration Tool (TCMAPP.EXE) liest die user accounts eines oder mehrerer Windows NT
Domain Server aus.
2. Parallel dazu werden über die TAPI-Funktion lineGetDevCaps() die Eigenschaften/Fähigkeiten
aller line-devices abgefragt, auf die der bzw. die lokalen Service Provider Zugriff hat.
3. Den ermittelten Nutzernamen können über eine graphische Oberfläche Berechtigungen für
Endgeräte (devices) zugewiesen werden. Diese Konfiguration wird in der Datei TSec.INI gespeichert. Beispiel-Eintrag in der TSec.INI: [Max=3,16739], (3=ProviderID und 16739=DeviceID). Die
Kombination aus beiden IDs ergibt den permanenten DeviceID.
4. Die TSec.DLL fragt zur Laufzeit die Konfiguration der TSec.INI ab und sperrt anhand dieser Daten
den Zugriff auf Devices durch nicht berechtigte User.
Beachte: Funktionsweise von TSPI_lineGetDevCaps()
Der Service Provider muß bei Aufruf der Funktion TSPI_lineGetDevCaps() die Rufnummer des
abgefragten Devices zurückliefern. Dafür ist der Parameter lineName zu verwenden.
z.B.: „2230 – HICOM set 500“
Anhand von lineName kann der Administrator die verfügbaren lines des Service Providers identifizieren
und diese einzelnen Nutzern zuweisen.
Funktionsumfang des Administration Tool:
Der Funktionsumfang und die Funktionsweise des Administration Tool ist im TAPI 2.1 SDK dokumentiert. Aus der Dokumentation wird ersichtlich, daß es sich noch nicht um eine sehr ausgereifte
Anwendung handelt. Hinsichtlich Funktionsumfang und Bedienerfreundlichkeit kann die Anwendung
noch ausgebaut werden. Laut [TAPI 2.1 SDK - 1]: „Feedback on TCMAPP desired features and
functionality is welcome.“, sind Vorschläge von Anwendern willkommen.
Auch, wenn über weitere Client Management DLLs zusätzliche Managent-Funktionen implementiert
werden können, ist es aus Sicht des Administrators einfacher, nur eine Anwendung zu verwenden, die
alle benötigen Optionen bietet.
Statusbericht Mai‘98, Teil: TAPI
14
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Vorschläge für weitere TCMAPP-Leistungsmerkmale:

Es sollte ein Filter für generell zulässige Client-Rechneradressen angeboten werden. Mit diesem
Filter kann z.B. ein Zugriff eines berechtigten Nutzers von außerhalb der Firma verhindert werden.

Ebenfalls ist eine Verwaltung von Nutzergruppen sinnvoll. Damit kann folgendes Sicherheitsproblem gelöst werden:
Innerhalb einer Nutzergruppe dürfen Monitore auf alle Endgeräte eingerichtet werden.
Eine Steuerung ist aber meist nur für das eigene Endgerät erlaubt.

Das Administration Tool zum TAPI-Server sollte möglichst viele Optionen bieten, um eine zweite
Admin-Oberfläche (von Client Management DLLs) zu vermeiden.

Das Microsoft Administration Tool sollte eine Management-Schnittstelle bereitstellen, die von den
SP-Anbietern bedient werden kann. Auf der Oberfläche sollten zum Nutzer und zum Device jeweils
ein Button „weitere Einstellungen...“ angeboten werden, über die eine SP-DLL einen eigenen Dialog anzeigen kann. Das Problem der Datenhaltung ist zu beachten. Die SP-spezifischen AdminDaten sind auch von den Client Management DLLs zu lesen.
Kann das Administration Tool ersetzt werden?
Microsoft trifft dazu folgende Aussage:
Aus [TAPI 2.1 SDK - 1] - FAQ
====================================================================
Q: Can a third-party replace TCMAPP?
A: No. The functionality of TCMAPP will change as telephony information moves to the Active
Directory. Feedback on TCMAPP desired features and functionality is welcome.
Bemerkung:
Prinzipiell müßte es dennoch möglich sein, die Komponenten TCMAPP.EXE und
TSec.DLL zu ersetzen. Dies kann z.B. von Vorteil sein, wenn die nutzerbezogenen Berechtigungen durch arbeitsplatzbezogenen Berechtigungen ersetzt werden sollen (siehe
dazu Kapitel 3). Dabei wären keine nutzerbezogenen Berechtigungen mehr zu überprüfen.
Da zur Laufzeit nur die TSec.DLL vom TAPI-Server aufgerufen wird, ist diese DLL durch
eine andere (eigene) mit identischen Namen zu ersetzen.
2.6 User Interface (UI)
Mit TAPI 2.0 wurde eine Trennung von Service Provider und User Interface vorgenommen. Unter dem
User Interface sind Dialog-Fenster zu verstehen, die der Service Provider generiert, um mit dem
Nutzer in Dialog zu treten. Neben der Erhöhung der programmtechnischen Sicherheit bei TAPI 2.0,
konnte durch diese Trennung das Client-Server-System vom TAPI 2.1 unterstützt werden.
Da auch bei TAPI 2.1 Nutzerdialoge erforderlich sind, muß beim Client eine Instanz vorhanden sein,
die diese generiert. Ein Nutzer kann z.B. über einen Dialog eine TAPI-line auswählen, die er zum
Aufbau einer Verbindung nutzen möchte.
Die Abbildung 7 zeigt das User-Interface-Konzept bei TAPI 2.1.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
2230
OK
Abr.
Client
(Windows 95, NT)
TAPI Anw endung
TAPI32.DLL
15
Server
(Windows NT)
Aufruf
Dialogaufruf
TAPI
Datentransfer
TSPI
TAPISRV.EXE
TSPI
RemoteSP.DLL
RPC_RT.DLL
Transport
TAPISRV.EXE
UI.DLL
TSPI
RPC_RT.DLL
Prozeßgrenze
zwischen Anwendung
und TAPISRV
Transport
Service
Provider
PBX
CTI-Link
1
Telefonieanbieter
LAN
Microsoft TAPI 2.1
Microsoft Windows
TAPI
TSPI
TAPISRV
RemoteSP
RPC_RT
UI.DLL
= Telephony Application Programming Interface
= Telephony Service Provider Interface
= TAPI Server
= Remote Service Provider
= Remote Procedure Call Run Time
= User Interface DLL
Abbildung 7: User Interface Konzept
Das UI-Konzept bietet folgende Möglichkeiten:
Anzeige eines Dialogs, initiiert durch eine Clientanwendung
Eine Client-Anwendung kann einen Dialog vom Service Provider aufrufen (z.B. lineConfigDialog), wenn
die Komponente UI.DLL aus Abbildung 7 die Funktion TUISPI_lineConfigDialog bereitstellt. Über den
Kommunikationspfad (1) überträgt eine UI.DLL Daten zu ihren Service Provider oder fragt diese ab.
Der Datentransfer wird immer von der UI.DLL eingeleitet; der Service Provider kann keine spontanen
Ausgaben beim User Interface vornehmen (beim nächsten Punkt ist dies aber möglich).
Anzeige eines Dialogs, initiiert durch einen Service Provider
Manchmal ist es auch notwendig, daß der Service Provider spontan einen Dialog beim Client anzeigt,
z.B. zur Aufforderung „Bitte Hörer abnehmen!“ beim Verbindungsaufbau für einen analogen Teilnehmer. Mit den Mitteln von UI kann der Service Provider einen Dialog erzeugen lassen, Daten zum
Dialog senden und diesen auch Schließen. Bei Nutzereingaben oder anderen Ereignissen ist die
UI.DLL in der Lage, auch Daten zum Service Provider zu senden.
Anwendungsbeispiel:
Die Mittel des User Interfaces werden beispielsweise für die Vergabe von arbeitsplatzbezogenen
Berechtigungen benötigt, deren Funktionsweise in Kapitel 3 vorgestellt wird. Zur Überprüfung der
Berechtigungen muß der Service Provider beim Client einen Dialog erzeugen können.
Statusbericht Mai‘98, Teil: TAPI
16
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
2.7 Remote Procedure Call (RPC )
Die Kommunikation zwischen Client und Server erfolgt bei TAPI 2.1 über Remote Procedure Calls.
Als Grundlage für weitere Sicherheitsbetrachtungen bei TAPI 2.1 wird in diesem Abschnitt die
Funktionswiese des Remote Procedure Calls vorgestellt und dabei speziell auf die Sicherheitsmechanismen eingegangen.
2.7.1 Standardisierung
Die Microsoft RPC-Implementierung wurde nach dem RPC-Standard der Open Software Foundation
(OSF) vorgenommen. Der OSF RPC-Standard ist ein Bestandteil der OSF DCE-Standards (Distributed
Computing Environent). Die Microsoft RPC-Implementierung ist kompatibel mit dem OSF-Standard,
bis auf kleine Ausnahmen. [Win32 SDK - 1]
2.7.2 Funktionsweise
Die Abbildung 8 zeigt den erforderlichen Kommunikationsstack für einen Remote Procedure Call
zwischen Client und Server.
Server
Client
Bsp.:
TAPI 2.1 Client
TAPI Anw endung
TAPI32.DLL
Application
IF.IDL
Client Stub
w ird automatisch aus einem
Interface.IDL -File generiert
Application
IF.IDL
Server Stub
TAPISRV
TSPI
RemoteSP
TSPI.IDL
TSPI Client Stub
Client Run-Time
Library
stellt das standardisierte
RPC-Protokoll bereit
Server Run-Time
Library
Client Run-Time
Library
Transport
Transport
Transport
durch ein IDL -File
spezifiziertes Interface
z.B. TCP/IP, NetBIOS, SPX
LAN
Komponenten sind für verschiedene
Platformen verfügbar
für eine spezielle Anwendung
entwickelt bzw. generiert
IDL
IF
RemoteSP
= Interface Description Language
= Interface
= Remote Service Provider
Abbildung 8: Stackaufbau für RPC
Sollen Prozeduren einer Server-Anwendung über RPC zugänglich sein, ist für diese ein IDL-File (Bsp.
Siehe Anhang A) zu erstellen. Aus dem IDL-File läßt sich mit einem Compiler (MIDL.EXE) ein Clientund ein Server-Stub generieren, unter der Programmiersprache C könnten z.B. die Files ClientStub.c,
ServerStub.c und Stub.h generiert werden. Diese Stub-Files sind mit der Anwendung zu kompilieren
und zu linken. Die erforderlichen Run-Time Libraries sind z.B. unter Windows 3.1, 95 und NT
verfügbar. Die RPC-Run-Time Library von Windows kann verschiedene Transportprotokolle nutzen
(Beispiele siehe Anhang A).
RPC-Sequenz mit Client-Authentikation
Um RPC mit Client-Authentikation zu nutzen, teilt der Client seine Sicherheits-Informationen (Nutzername, Domain, Paßwort) der Run-Time Library mit. Diese Sicherheits-Informationen werden als ClientCredentials2 bezeichnet. Die ClientRun-Time Library überträgt diese Credentials zur Server Run-Time
Library, die sie an einen Security Service weiterleitet. Von Microsoft wird derzeit nur ein NT Security
Service bereitgestellt (siehe auch Abbildung 9). [Win32 SDK - 2]
2
Credentials = Papiere, Zeugnisse
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Client
Client-App
17
Server
Client-Stub
RPC-RT
RPC-RT
RpcStringBindingCompose(...)
Server-Stub
Server-App
RpcServerUseProtseqEp(...)
1
RpcBindingFromStringBinding(...)
RpcServerRegisterIfEx(...)
RpcBindingSetAuthInfo(...)
2
RpcServerRegisterAuthInfo (...)
RpcServerListen(...)
3
HelloProc()
NdrClientInitializeNew()
Security Service
Parameter serialisieren
NdrSendReceive(...)
4
RPC-Data
[Credentials,...]
Check
hello_HelloProc(...)
NdrServerInitializeNew(...)
5
Parameter deserialisieren
HelloProc()
return
NdrSendReceive(...)
return
RPC-Data
Prozeduraufruf mit return
Einsprung in eine Prozedur
Rückkehr aus einer Prozedur
hello_HelloProc(...)
return
RPC-RT
HelloProc()
= RPC Run-Time
Abbildung 9: RPC-Sequenz mit Client-Authentikation am Beispiel der Funktion HelloProc()
Beachte: Die Abbildung beruht auf einer Analyse der Diensterbringung beim Client und Server; die
Darstellung des RPC-Protokolls zwischen Client und Server ist stark vereinfacht.
Beschreibung:
Client
1. Initialisierung einer Bindung zum Server,
[ID des Ziel-Interfaces, Transportprotokoll,
Serveradresse, Port] 1
Server
Das Server-Interface (Objekt) bei der RPC RunTime anmelden,
[Transportprotokoll, Port, SecurityDescriptor
(optional)], [Interface-ID] 1
2. Binden der Client-AuthentikationsInformationen,
[ServerName, AuthLevel, AuthService,
AuthIdentity, AuthorizationService] 1
Authentikations-Mechanismus bei der RPC RunTime anmelden,
[ServerName, AuthService, AuthKeyFunction
(optional)] 1
3. Einleitung eines Remote Procedure Calls
Warten auf RPCs
4. RPC-Anforderung wird zum Server gesendet,
[Credentials, ...]
Die Client-Credentials werden durch einen
Security Service überprüft. Microsoft stellt z.B.
einen Windows NT Security Service bereit.
5. Der Prozeduraufruf beim Client wird beendet.
Der Client erhält Rückgabeparameter.
War die Überprüfung erfolgreich, ruft die RPC
Run-Time die Ziel-Funktion im Server-Stub auf.
Tabelle 1 : Beschreibung eines RPC mit Authentikation
1
[Parameter] werden in der folgenden Tabelle beschrieben
Parameterbeschreibung zu Tabelle 1
Parameter
ID des Ziel-Interfaces
Beschreibung, Beispielwerte
Jedem Server-Interface für RPC ist ein UUID (universal unique identifier)
zuzuweisen. Ein UUID wird mit UUIDGEN.EXE generiert.
z.B. "6B29FC40-CA47-1067-B31D-00DD010662DA"
Transportprotokoll
z.B.:
„ncacn_ip_tcp“
TCP over IP
„ncacn_np“
named pipes
„ncacn_spx“
SPX
„ncadg_ip_udp“
UDP over IP
(weitere siehe Anhang A)
Serveradresse
Dieser Parameter hängt vom verwendeten Transportprotokoll ab.
=Adresse des Rechners mit der Server-Anwendung
Statusbericht Mai‘98, Teil: TAPI
18
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
z.B.: „TAPI21-Server.Siemens.de“ (TCP/IP)
Port
Dieser Parameter hängt vom verwendeten Transportprotokoll ab.
z.B.: „1000“ = Portnummer, unter der das Server-Interface zu erreichen ist
ServerName
Dieser Parameter hängt vom verwendeten Authentikations-Service ab.
=Name des Servers, der die Authentikation durchführen soll.
z.B.: Name des NT-User-Domain-Servers oder Netware-Servers
AuthLevel
=Authentication Level
z.B.: RPC_C_AUTHN_LEVEL_CONNECT = Authentikation wird nur dann
durchgeführt, wenn der Client eine Verbindung zu Server aufbaut;
Im Anhang B sind alle möglichen Authentication Level’s aufgeführt.
AuthService
= Authentication Service = Sicherheitsmechanismus
z.B.: RPC_C_AUTHN_WINNT = NT Security Service
(weitere siehe Anhang A)
AuthorizationService
Dieser Parameter wird von der NT-Security nicht genutzt.
AuthIdentity
Dieser Parameter hängt vom verwendeten Authentikations-Service ab.
Der Parameter wird als Zeiger auf eine Datenstruktur übergeben. Die
Datenstruktur enthält die Authentikations und Authorisierungs-„Papiere“
des Clients.
z.B.: Wird als AuthService RPC_C_AUTHN_WINNT verwendet, muß
AuthIdentity auf eine SEC_WINNT_AUTH_IDENTITY-Struktur zeigen.
(Struktur ist in Anhang B enthalten)
AuthKeyFunction
= Funktion, die einen Verschlüsselungs-Schlüssel für den Authentication
Service bereitstellt;
z.B.: Wird als AuthService RPC_C_AUTHN_WINNT verwendet, ist für diesen
Parameter Null zu übergeben.
Credentials
=Sicherheitsinformationen des Clients (Papiere), die mit RPC übertragen
werden;
Obwohl zu diesem Punkt keine direkten Informationen vorlagen, kann davon
ausgegangen werden, das die Client-Credentials die gleichen Informationen
wie die Struktur RPC_C_AUTHN_WINNT enthalten (Username, Domain,
Paßwort), nur in verschlüsselter Form.
Tabelle 2: RPC Parameterbeschreibung
2.7.3 Sicherheitsoptionen von RPC unter Windows
Client
Windows 3.1
Windows 95
Windows NT
1Die
Nutzerauthentikation
Nein1
Ja
Ja
Datenverschlüsselung
Nein1
Ja
Ja
Funktionen RpcServerRegisterAuthInfo und RpcBindingSetAuthInfo sind nur unter Windows 95 und NT verfügbar.
2.7.4 Verwendetes RPC-Transportprotokoll für TAPI 2.1
Die folgenden Aussagen beruhen auf einer Analyse der Netzwerkkommunikation zwischen einem
TAPI-Client und TAPI-Server. Auf beiden Systemen war ein NetWare-Client installiert und somit auch
IPX/SPX als Transportprotokoll verfügbar.
Bei der Analyse wurde festgestellt, daß in dieser Konfiguration zwei unterschiedliche Kommunikationsstacks verwendet werden, je nachdem, ob der Client ein RPC-Request einleitet oder der Server. Für
die zugehörige RPC-Response-PDU wird jeweils der gleiche Kommunikationsstack verwendet wie
beim Request. Der Grund für diese Lösung ist dem Autor nicht bekannt.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
19
client-initiierte RPCs:
RPC
TAPI-Client
(Remote-SP)
TAPI-Server
Microsoft RPC - Protokoll
RPC
Protokoll für named Pipes
SMB
NetBIOS over IPX
stellt NetBIOS über IPX bereit
IPX
RPC
SMB
NetBIOS over IPX
IPX
IPX (Novell)
Ethernet
Ethernet
LAN
Abbildung 10: Kommunikationsstack für Client-RPCs
server-initiierte RPCs:
RPC
TAPI-Client
(Remote-SP)
MSRPC
TAPI-Server
Microsoft-RPC - Protokoll
TCP
TCP
IP
IP
Ethernet
MSRPC
TCP
IP
Ethernet
LAN
Abbildung 11: Kommunikationsstack für Server-RPCs
Die im TAPI 2.1 SDK [TAPI 2.1 SDK - 1] enthaltene Aussage ist also für Systeme mit NetWare-Clients
nur Teilweise zutreffend:
*) TAPI 2.1 only supports communication between client and server using the TCP/IP protocol.
Additional protocols will be supported in a future release.
2.7.5 Verwendete RPC-Sicherheitsmechanismen bei TAPI 2.1
Authentikation der TAPI-Clients
Die TAPI 2.1 Clients werden über die RPC-Sicherheitsmechanismen authentifiziert. Die RPC RunTime des TAPI-Servers nutzt dafür den Windows NT Security Service. Im Anhang C sind die sicherheitsrelevanten RPC-Funktionen aufgeführt, die der TAPI-Server bzw. der Remote-SP verwenden.
Die folgenden Aussagen beruhen auf einer Analyse der Netzwerkkommunikation zwischen TAPI-Client
und TAPI-Server.
Genutzter Authentikations-Level:
Genutzter Authentikations-Service:
Inhalt der Client-Credentials:
Die Authentikation erfolgt nur einmalig beim Binding des
Clients, also am Anfang einer Session.
RPC_C_AUTHN_WINNT; es wird der NT LAN Manager
Security Support Provider (NTLMSSP) verwendet,
Username, Domain, Paßwort(verschlüsselt).
Es kann davon ausgegangen werden, daß die verwendete NT-Nutzerauthentikation eine ausreichende
Sicherheit gegenüber Angriffen gewährleistet.
Keine Datenverschlüsselung
Im TAPI 2.1 SDK wird zum Thema Datenverschlüsselung zwischen Client und Server folgende
Aussage getroffen [TAPI 2.1 SDK –1]:
*) TAPI presently does not support encryption of data passed between the client and the server. This
issue will be addressed in a future release.
Statusbericht Mai‘98, Teil: TAPI
20
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Warum die Datenverschlüsselung zwischen TAPI-Client und Server noch nicht implementiert ist,
konnte vom Autor nicht in Erfahrung gebracht werden. In den durchsuchten Dokumenten zu RPC
wurden keine technischen Gründe gefunden. Ein möglicher Grund könnte der zusätzliche Performance-Bedarf im NT-Server sein, wenn viele Clients gleichzeitig aktiv sind.
Schlußfolgerungen:
Bei einem busförmigen3 LAN können die zwischen TAPI Client und Server übertragenen Informationen
relativ einfach abgehört werden. Dafür ist nur ein PC mit einer speziellen Software zur Filterung und
Aufzeichnung von LAN-Paketen notwendig. Ein Telefon kann somit überwacht werden, sobald ein
HICOM-Monitor auf dieses eingerichtet ist. Aus den Monitormeldungen, die daraufhin vom Server zum
Client gesendet werden, können folgende, durchaus sensible Informationen, abgehört werden:


Rufnummern von gehenden und kommenden Gesprächen,
Zeitpunkt und Dauer von Gesprächen.
2.8 Zusammenfassung zu TAPI 2.1
Einsatzgebiete:
+ Der Einsatz von TAPI 2.1 ist nur in einer vorhandenen oder geplanten NT-Domain zu empfehlen.
+ In einer Umgebung mit verschiedenen PBX-Typen, kann eine einheitliche Telefonieunterstützung
angeboten werden, wenn die PBX-Hersteller jeweils einen Service Provider für TAPI 2.1 liefern.
– Der Einsatz von TAPI 2.1 in einer NetWare-Umgebung ist nicht zu empfehlen (extra NT-Lizenzen).
– Eine plattformunabhängige Unterstützung von Java-Clients (JTAPI) ist nicht möglich. Unter
Windows könnte beim Client ein Mapping von TAPI nach JTAPI erfolgen.
Administrierung:
+ Microsoft stellt ein Administration Tool bereit, mit dem eingerichteten Nutzern einer NT-Domain
Rechte auf Endgeräte zugewiesen werden können.
 Microsoft wünscht laut [TAPI SDK, Zeile 282] Hinweise zur Gestaltung des Administration Tools.
Mögliche Erweiterungen wurden unter 2.5.3 genannt.
 Über das Client Management API können Telefonieanbieter zusätzliche Management-Funktionen
bereitstellen.
 Siemens kann auf eine bessere NetWare-Unterstützung hinwirken.
Sicherheit:
+ Eine Nutzerauthentikation wird unterstützt, dazu werden die Sicherheitsmechanismen von Windows
NT genutzt.
+ Über das TAPI Client Management können zusätzliche Sicherheits- und Managementfunktionen
realisiert werden.
– Es wird keine Datenverschlüsselung zwischen Client und Server angeboten.
3 Arbeitsplatzbezogene Berechtigungen
3.1 Bereits vorgestellte Sicherheitsmechanismen
Als ein Themenschwerpunkt wurde in den vergangenen Statusberichten ein PaCT-System unter
sicherheitstechnischen Aspekten betrachtet. Ausgehend von diesen Betrachtungen wurden konkrete
Sicherheitsmechanismen spezifiziert, mit denen einzelnen Gefahren begegnet werden kann. Die
Sicherheitsmechanismen werden im folgenden noch einmal kurz vorgestellt, wobei als weiterer
3
Einem sternförmiges Netz bietet dagegen eine höhere Sicherheit, da sich ein Angreifer physisch in den Strang zwischen
TAPI-Server und Switch „einklinken“ müßte.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
21
Schwerpunkt des Kapitels auf eine alternative Möglichkeit zur Nutzerauthentikation eingegangen
werden soll – die Vergabe von arbeitsplatzbezogenen Berechtigungen.
3.1.1 Geheimhaltung von Nutzerdaten [Stat 12/96]
Aufgrund der Tatsache, daß in einem PaCT-System mit Telefonieserver vertrauliche Informationen
über das lokale Netzwerk übertragen werden, ist die Bereitstellung eines sicheren Datenkanals
zwischen Client und Server erforderlich.
Im Statusbericht 12/96 wurde ein Verfahren vorgestellt, mit dem ein sicherer Kanal hergestellt werden
kann. Als Randbedingung wurde davon ausgegangen, daß die Client-Anwendung in Besitz eines
geheimen Paßwortes ist, welches sie von der vorher erfolgten Nutzerauthentikation übernimmt.
3.1.2 Authentikation von Anwendungsprogrammen
Die Authentikation von Anwendungsprogrammen wurde im letzten Statusbericht relativ ausführlich
vorgestellt. Ein Anwendungsgebiet in einer PaCT-Umgebung wäre die Authentikation der ClientTelefonieanwendungen gegenüber dem Telefonieserver. Mit der Authentikation wird die Identität der
Clientanwendung festgestellt und gleichzeitig überprüft, ob diese unverändert bezüglich ihrer Funktionalität ist. Auf diese Weise soll verhindert werden, daß fremde oder manipulierte Anwendungen das
PaCT-System bedrohen können. Die Schutzfunktion beruht auf der Tatsache, daß bestehende
Sicherheitslücken in der Client-Server-Kommunikation für einen Angreifer nicht zugänglich sind.
3.1.3 Nutzerauthentikation
Das größte Sicherheitsproblem in einem System aus Telefonieserver und Clients ist die Vergabe von
Rechten zur Steuerung von Endgeräten. Eine häufig gewählte Lösung ist die nutzerbezogene Vergabe
von Rechten. Diese Variante wird z.B. auch von dem Novell Telephony Server und dem TAPI 2.1
Server verwendet. Im Statusbericht 12/96 wurde auch eine Nutzerauthentikation für den ACL-Server
spezifiziert.
Vorteile einer Nutzerauthentikation:
 Durch eine Nutzerauthentikation (Nutzername , Paßwort) kann eine hohe Sicherheit gewährleistet
werden.
 Der Dienstnutzer ist im Telefonieserver bekannt, somit kann bei Bedarf auch eine nutzerbezogene
Protokollierung erfolgen.
 Es kann sein, daß spezielle Berechtigungen nur nutzerbezogen vergeben werden können (z.B.
wenn eine Client-Anwendung mehrere lokal verteilte Endgeräte steuern/überwachen will). Die
alternative zu nutzerbezogenen Berechtigungen wären arbeitsplatzbezogene Berechtigungen.
Nachteile einer Nutzerauthentikation:
 Wenn zum Start einer Telefonieanwendung eine extra Abfrage von Nutzername und Paßwort
erfolgt, kann dies die Akzeptanz durch den Nutzer verringern. Dieses Problem kann umgangen
werden, wenn ein bereits erfolgtes Login übernommen werden kann (z.B. Login an einem FileServer), somit ergibt sich u.U. aber eine Abhängigkeit von der Systemumgebung.
 Die Verwaltung von Nutzerberechtigungen verlangt einen gewissen Administrierungsaufwand.
 Wenn ein Nutzer für ein spezielles Endgerät berechtigt ist, kann er dieses von jedem Arbeitsplatz
aus steuern. Die Fernsteuerung eines Endgerätes, von einem anderen Arbeitsplatz aus, stellt ein
Sicherheitsproblem dar.




Problem 1: extra Login oder Systemabhängigkeit
Problem 2: Administrierungsaufwand
Problem 3: Sicherheit
Im folgenden soll geklärt werden, ob mit einer Vergabe von arbeitsplatzbezogenen Berechtigungen
diese Probleme gelöst werden können.
3.2 Einleitung / Problemstellung
In diesem Kapitel wird ein Verfahren vorgestellt, mit dem Endgeräteberechtigungen bezogen auf den
Arbeitsplatz vergeben werden können. Bei diesem Verfahren wird überprüft, ob ein spezielles Endgerät
Statusbericht Mai‘98, Teil: TAPI
22
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
von einem Arbeitsplatzrechner mit Telefonieanwendung gesteuert werden darf; der aktuelle Nutzer
(Person) bleibt dabei unberücksichtigt. Unter der Annahme, daß eine Person, die physischen Zugang
zu einem Endgerät hat, dessen freigeschaltete Leistungsmerkmale nutzen kann, sollten die gleichen
Möglichkeiten zur Steuerung des Telefons auch über den lokalen Arbeitsplatzrechner bereitgestellt
werden.
Arbeitsplatz
HICOM 300
ACL-Server
ACL-Link
ACL
LAN
Application Connectivity Link
Abbildung 12: Endgerätezugriff durch den Nutzer am Arbeitsplatz
Somit ist folgendes Problem zu lösen:
Es ist zu überprüfen, ob der Computer, über den die Steuerung des Endgerätes erfolgt, auch in
unmittelbarer Nähe des Endgerätes steht.
Vorteile gegenüber einer Nutzerauthentikation



Die Identifikation des steuernden Rechners ist für viele Anwendungen ein besseres Sicherheitskriterium als die Nutzerauthentikation. Bei einer Nutzerauthentikation kann ein Endgerät auch von
einem anderen Arbeitsplatz aus gesteuert werden, wenn sich dort ein berechtigter Nutzer anmeldet. Dies stellt ein Sicherheitsproblem dar.
Zur Vergabe der Endgeräteberechtigungen ist keine Administrierung (Nutzername  Endgerät)
erforderlich. (Der Nutzer durchläuft automatisch den Sicherheitsmechanismus.)
Ein Nutzer kann den Arbeitsplatz wechseln und dort ebenfalls computerunterstützte Telefonieanwendungen nutzen. (keine Administrierung erforderlich)
3.3 Lösungsansatz
In einer PaCT-Umgebung mit Telefonieserver und mehreren Clients, stellt der Telefonieserver
Sicherheitsmechanismen bereit. Der Telefonieserver muß somit auch den Mechanismus zur Vergabe
von arbeitsplatzbezogenen Berechtigungen bereitstellen.
Um festzustellen, ob der Nutzer gleichzeitig Zugriff auf den Computer und das Endgerät hat, kann der
Telefonieserver folgende Überprüfungs-Mechanismen einleiten:
Variante 1 (Hookflash):
Der Telefonieserver fordert den Nutzer am Client-Computer über ein Meldungsfenster auf, eine
spezielle Aktion am Endgerät auszuführen, z.B.: den Hörer kurz abnehmen. Über einen Endgerätemonitor überwacht der Telefonieserver, ob diese Aktion innerhalb einer gewissen Zeitspanne erfolgt.
Diese Variante ist bei analogen und digitalen Endgeräten anwendbar.
Variante 2 (Code-Abfrage):
Bei Endgeräten mit Display kann der Telefonieserver über dieses eine Meldung anzeigen, die mit einer
Aktion am Arbeitsplatzrechner zu quittieren ist. Beispielsweise kann über das Telefondisplay ein Code
angezeigt werden, der daraufhin am Rechner einzugeben ist. Der Telefonieserver überprüft den
eingegebenen Code.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
23
Gemeinsam:
Im Telefonieserver werden die erworbenen Berechtigungen unter der Rechneradresse des Clients
gespeichert. Erfolgt eine erneute Anmeldung von einem Client-Rechner aus, kann dieser Aktionen
nach seinen Endgeräteberechtigungen ausführen, ohne daß eine erneute Überprüfung erfolgt.
3.4 Anwendbarkeit für TAPI und TSAPI
Der Sicherheitsmechanismus für die Vergabe von arbeitsplatzbezogenen Berechtigungen kann in
einer TAPI-Umgebung bereitgestellt werden. Allerdings sind dabei die Eigenschaften der verschiedenen TAPI-Versionen zu betrachten.
3.4.1 TAPI 1.0 bis TAPI 2.0
Die TAPI-Versionen 1.0 bis 2.0 wurden prinzipiell für First Party Telefonieanwendungen ausgelegt, bei
denen eine lokale Telefoniehardware genutzt wird. Sollen diese TAPI-Versionen für ein PaCT-System
mit Telefonieserver genutzt werden, ist eine Systemkonfiguration nach Abbildung 13 erforderlich.
Systembeschreibung:
Eine TAPI-Anwendung nutzt über die TAPI.DLL die Dienste eines TAPI Service Providers. Der
Service Provider bietet seine Dienste über die standardisierte Schnittstelle TSPI an. Da er aber nicht
auf die lokale Telefoniehardware zugreifen kann, leitet er seine Dienstanforderungen an den Telefonieserver weiter. Dies erfolgt über das lokale Netzwerk, wobei ein proprietäres Protokoll verwendet
wird. Der Telefonieserver nutzt wiederum die Dienste der PBX (z.B. HICOM 300), die diese über ihre
PaCT-Schnittstelle (z.B. ACL-Link) bereitstellt. Die PBX realisiert den Zugriff auf die Telefoniehardware
(Endgeräte).
TAPI
ACL
Telephony Application Program
Interface
Application Connectivity Link
HICOM 300
TAPIAnwendung
TAPI
TAPI.DLL
TSPI
TAPI-Service
Provider
TCP/IP
Telefoniesever
ACL
TCP/IP
ACL-Link
LAN
Telefonieserver
Abbildung 13: Systemkonfiguration für TAPI 1.0 bis TAPI 2.0
Vorhandene Sicherheitsmechanismen
In den TAPI-Versionen 1.0 bis 2.0 sind keine Sicherheitsmechanismen implementiert. Dies war
aufgrund der Auslegung für First Party Telefonieanwendungen, die auf die lokale Telefoniehardware
zugreifen, nicht erforderlich. Erst durch den Einsatz in einer Client-Server-Umgebung, bei der die
Dienste über ein unsicheres lokales Netzwerk erbracht werden, sind Sicherheitsmaßnahmen erforderlich.
Einbindung von zusätzlichen Sicherheitsmechanismen
Der Telefonieserver und der TAPI Service Provider bilden eine Funktionale Einheit (System), die von
einem Hersteller angeboten wird. In dieses System können vom Hersteller zusätzliche Sicherheitsmechanismen in beliebigen Umfang implementiert werden.
Für einige Sicherheitsmechanismen, wie Nutzerauthentikation oder die Vergabe von arbeitsplatzbezogenen Berechtigungen, ist ein Nutzerdialog (Dialogfenster) erforderlich. Diese Aufgabe übernimmt
Statusbericht Mai‘98, Teil: TAPI
24
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
der TAPI Service Provider. Für andere Sicherheitsmechanismen, wie Datenverschlüsselung der ClientServer-Kommunikation, ist kein Nutzerdialog erforderlich.

Der Sicherheitsmechanismus zur Vergabe von arbeitsplatzbezogenen Berechtigungen kann in
einem System nach Abbildung 13 implementiert werden. Für die meisten Client-Arbeitsplätze
dürfte dieser Sicherheitsmechanismus ausreichend sein (keine Nutzerauthentikation).
3.4.2 TAPI 2.1
Die Version TAPI 2.1 wurde um die Funktionalität für eine Client-Server-Umgebung erweitert. Als
Sicherheitsmaßnahme wird von Microsoft eine Nutzerauthentikation angeboten. Die Nutzerberechtigungen werden dabei über eine Administierungs-Anwendung im TAPI-Server vergeben.
Genauere Informationen zur Systemkonfiguration und Sicherheit bei TAPI 2.1 sind dem Kapitel 2 zu
entnehmen.
Einbindung von zusätzlichen Sicherheitsmechanismen
Wie in Anschnitt 2.4 beschrieben, bietet TAPI 2.1 ein Client Management API, mit dem beliebige
Anbieter eigene Management-Funktionen bereitstellen können. Mit dem Funktionsumfang des Client
Management APIs kann die Vergabe von arbeitsplatzbezogenen Berechtigungen realisiert werden. Auf
Aspekte der Implementierung geht der Abschnitt 3.6 ein.
Wird die Vergabe von arbeitsplatzbezogenen Berechtigungen zusätzlich zur vorhandenen Nutzerauthentikation von TAPI 2.1 implementiert läßt sich folgende Sicherheitslücke schließen:
Ein autorisierter Nutzer kann sich an einem beliebigen Rechner einloggen und sein zugewiesenes
Endgerät fernsteuern/überwachen. Eine derartige Aktion sollte normalerweise nicht möglich sein. Mit
der zusätzlichen Authentikation des Arbeitsplatzrechners kann dies verhindert werden.
Ersetzen der Nutzerauthentikation von TAPI 2.1
In Anschnitt 2.4 wurde gezeigt, daß es prinzipiell möglich ist, die Nutzerauthentikation von TAPI 2.1
auszuschalten, indem die TSec.DLL ersetzt wird. Somit kann die Nutzerauthentikation vollständig
durch arbeitsplatzbezogene Berechtigungen ersetzt werden. Bei dieser Variante entfällt der Aufwand
für die Nutzeradministrierung.
Der Sicherheitsmechanismus zur Vergabe von arbeitsplatzbezogenen Berechtigungen kann:

die vorhandene Nutzerauthentikation von TAPI 2.1 ergänzen und somit zusätzliche Sicherheit
bereitstellen oder

die vorhandene Nutzerauthentikation von TAPI 2.1 vollständig ersetzen.
3.4.3 Anwendbarkeit für TSAPI
Obwohl der Schwerpunkt in diesem Abschnitt bei TAPI liegt, soll hier ein kurzer Ausblick auf eine
Realisierungsmöglichkeit in einer Novell Telephony Server Umgebung oder einem vergleichbaren
System, das TSAPI anbietet, gegeben werden.
Kann der Sicherheitsmechanismus zur Vergabe von arbeitsplatzbezogenen Berechtigungen mit TSAPI
realisiert werden?:
In einer TSAPI-Systemumgebung (siehe [Stat 9/97] ACL-Server S.11ff ) kann der Sicherheitsmechanismus nur in Absprache zwischen dem Anbieter des PBX-Treibers und der Telefonieanwendung
realisiert werden. Die Telefonieanwendung hat dabei die Aufgabe, einen Nutzerdialog bereitzustellen.
Zur Kommunikation zwischen Anwendung und Telefonieserver, ist der PrivateData-Mechanismus von
TSAPI zu verwenden (siehe [Stat 9/97] ACL-Server S.25f).
Eine Implementierung für TSAPI ist also nur für Komplettsysteme aus PBX-Treiber und Telefonieanwendung zu realisieren.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
25
3.5 Spezifikation des Sicherheitsmechanismus
In diesem Abschnitt wird die Funktionsweise des Sicherheitsmechanismus zur Vergabe von arbeitsplatzbezogenen Berechtigungen spezifiziert. Die Funktionsweise wird anhand einer TAPI-Umgebung
erläutert.
3.5.1 Gliederung
Da es sich bei dem Sicherheitsmechanismus um einen relativ komplexen Vorgang handelt, wird dieser
in mehrere Teilschritte gegliedert.
1.
2.
3.
4.
Grundlagen für den Sicherheitsmechanismus.
Es ist festzulegen, zu welchen Zeitpunkt der Überprüfungsmechanismus eingeleitet wird.
Zur Erhöhung der Sicherheit, ist die Absenderadresse zu validieren.
Es werden zwei Varianten vorgestellt, mit denen die lokale Bindung von Arbeitsplatzrechner und –
telefon überprüft werden kann.
5. Das Ergebnis der Überprüfung ist an folgende Sessions zu vererben.
6. Aufbau folgender Sessions.
7. Probleme innerhalb von Nutzergruppen.
3.5.2 Grundlagen zum Sicherheitsmechanismus
Der Sicherheitsmechanismus hat folgende Grundfunktionalität:
1. Von einem Client-Rechner aus wird ein Auftrag an den Telefonieserver gesendet, z.B. zum Aufbau
einer Gesprächsverbindung, ausgehend von einem internen Endgerät. Im Auftrag ist die Rufnummer des internen Endgerätes und auch die Absenderadresse des Client-Rechners enthalten (z.B.
IP-Adresse).
2. Der Telefonieserver führt die Aktion auf das Endgerät aus, wenn die Absenderadresse für dieses
Endgerät berechtigt ist.
Als Informationen für den Sicherheitsmechanismus stehen also zur Verfügung:
 Die Rufnummer des zu steuernden Endgerätes.
 Die Rechneradresse des Absenders (IP- oder IPX-Adresse). Da die Rechneradresse nicht sehr
zuverlässig ist, wird diese später durch eine weitere Information gesichert.
Datenbank im Telefonieserver:
Im Telefonieserver ist eine Datenbank (Liste) zu verwalten, in der bekannten Rechneradressen
Rufnummern zugeordnet sind (eine, keine oder mehrere Rufnummern).
HICOM 300
Rechneradresse
141.55.96.67
141.55.96.65
141.55.96.100
...
Rufnummer(n)
2230
2111
2231
2232
...
Rufnummer
z.B.: 2230
Daten
ACL-Link
PDU (141.55.96.67, 2230, ...)
Rechneradresse
z.B.: 141.55.96.67
LAN
Telefonieserver
Abbildung 14: Sicherheitsinformationen im PaCT-System
3.5.3 Einleitung des Sicherheitsmechanismus
Der erste Teilschritt des Sicherheitsmechanismus hat die Aufgabe, die lokale Bindung von Arbeitsplatzrechner und –telefon zu überprüfen. Diese Überprüfung sollte gleich beim Start einer
Telefonieanwendung erfolgen. Für eine TAPI-Umgebung ergibt sich ein Anfangssequenz nach
Abbildung 15:
Statusbericht Mai‘98, Teil: TAPI
26
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
(ACL-Server)
TSP = TAPI Service Provider
Telefonieserver
Client-Computer
TSP
TAPI.DLL
TAPI-Anwendung
lineNegotiateApiVersion()
1
TSPI_lineNegotiateTSPIVersion()
return
lineInitialize()
2
TSPI_providerEnumDevices()
return
AclAssociate[...,ipValidator]
3
AclAssociate_Response[...,ipValidator]
4
5
6
7
AclOpenDevice[rufnummer]
return
TSPI_providerInit()
return
return lineInitialize()
TSPI_lineGetDevCaps()
return
lineGetDevCaps()
TSPI_lineOpen()
lineOpen()
return
return
return
Überprüfungsmechanismus
AclOpenDevice_Result
Abbildung 15: Anfangssequenz beim Start einer TAPI-Anwendung
Erläuterung: lineOpen() = Funktionsaufruf
Beschreibung:
In der Abbildung basiert auf der vorliegenden Implementierung des ACL-Servers. Der eigene Service
Provider beim Client steht mit dem ACL-Server über das lokale Netzwerk in Verbindung.
1. Überprüfung, ob der TAPI Service Provider die geforderte TAPI-Version unterstützt.
2. Die TAPI.DLL erfragt die Anzahl der devices, die der Service Provider unterstützt. Der Service
Provider entnimmt diese Information einer lokalen Datenbank (Registry).
3. Die erste Interaktion zwischen Service Provider und ACL-Server wird durch den Funktionsaufruf
TSPI_providerInit() eingeleitet. In dieser Funktion baut der Service Provider über eine AclAssociate—PDU eine Verbindung zum ACL-Server auf. Im ACL-Server wird dabei eine Session angelegt
und der Service Provider erhält mit AclAssociate_Response den Session-ID.
Auf die Funktion des ipValidators wird im folgenden Abschnitt eingegangen.
4. Mit lineGetDevCaps() fragt die TAPI-Anwendung die Fähigkeiten der devices des Service
Providers ab (z.B. Sprache, G3-Fax, G4-Fax, Datenübertragung). Möchte die Anwendung eine
Sprachverbindung aufbauen, wird sie das erste device öffnen, das den Sprachdienst unterstützt.
5. Als nächste Aktion führt die Telefonieanwendung ein lineOpen() aus, meist mit dem Ziel, mit dieser
line später eine Sprachverbindung aufzubauen. Die line repräsentiert ein (lokales) Endgerät. Bei
lineOpen() wird als Parameter ein deviceID übergeben, dies ist aber nur ein lokaler Index, er gibt
also keine Rufnummer an. Im Service Provider wird die Funktion TSPI_lineOpen() auf die AclOpenDevice-PDU abgebildet, die speziell für den Sicherheitsmechanismus eingeführt wurde. In der
AclOpenDevice-PDU ist als Parameter die Rufnummer des gewünschten Endgerätes einzutragen.
Da von lineOpen() keine Rufnummer geliefert wird, ist diese vom Nutzer über einen Dialog abzufragen (nur beim erstmaligen Anmelden erforderlich). Im Dialog können bereits eine oder mehrere
Rufnummern zur Auswahl gestellt werden, die für den Arbeitsplatz vorkonfiguriert wurden.
6. Unter der Annahme, daß der Client-Rechner noch nicht für das gewünschte Endgerät berechtigt ist,
leitet der ACL-Server jetzt einen Überprüfungsmechanismus ein.
7. Das Ergebnis der Überprüfung wird dem Client mitgeteilt.
3.5.4 Validierung der Absenderadresse (IP-Adresse)
Der folgend beschriebene Sicherheitsmechanismus beruht u.a. auf der Identität der Absenderadresse,
da der Telefonieserver eine Dienstanforderung nur ausführt, wenn der Absender (IP-Adresse) die
entsprechende Berechtigung besitzt.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
27
Für einen Angreifer ist es leider ohne großen Aufwand möglich, eine andere IP-Adresse für seinen
Rechner einzutragen. Somit könnte er die Identität eines autorisierten Rechners übernehmen und
dessen Endgeräte steuern. Wenn in einem Netzwerk gleichzeitig zwei Rechner mit identischer IPAdresse angemeldet sind, kann dieser Konflikt zwar erkannt und behandelt werden, aber wenn der
rechtmäßig autorisierte Rechner ausgeschaltet ist, bleibt der Angriff unerkannt. Als Angriff wäre
beispielsweise das Abhören eines Raumes denkbar.
Lösung:
Die IP-Adresse ist durch eine weitere Information zu sichern, die der Client bei AclAssociate mit
senden muß. Dazu wurde im ACL-Server folgender Mechanismus eingeführt:






Im ACL-Server wird zu jeder, ihm bekannten, IP-Adresse ein ipValidator (Zufallszahl) verwaltet.
Wie in Abbildung 15 dargestellt, wird in der AclAssociate-PDU u.a. der Parameter ipValidator vom
Client verlangt.
Sendet der Client eine AclAssociate-PDU mit falschen ipValidator, werden alle Berechtigungen, die
dieser IP-Adresse im ACL-Server zugewiesen sind, gesperrt.
Der Client erhält mit jeder AclAssociate_Response-PDU einen neuen ipValidator (als Parameter
enthalten), auch, wenn bei AclAssociate ein falscher angegeben wurde. Den ipValidator muß der
Client (TSP) lokal auf seinem Rechner speichern, am besten in der Windows-Registry unter
(HKEY_LOCAL_MACHINE\Software\...).
Der ipValidator ist beim nächsten Aufbau einer Session mit AclAssociate zum ACL-Server zu
übertragen. Wurde ein gültiger ipValidator gesendet, behält der Absender seine bisherigen Berechtigungen (für Endgeräte).
Unter der Annahme, daß die Kommunikation zwischen ACL-Server und Client über einen
gesicherten Kanal läuft, kann der ipValidator auch nicht bei der Übertragung über das LAN abgelauscht werden (vom ACL-Server zum Client).
Ein Angreifer müßte also physischen Zugang zu einem fremden Rechner haben, um dessen
ipValidator auszulesen und somit die Berechtigung für dessen Endgeräte zu erwerben.
Über den folgend beschriebenen Überprüfungsmechanismus kann der Client-Rechner neue Berechtigungen für Endgeräte erwerben bzw. die Sperrung vorhandener Berechtigungen aufheben.
3.5.5 Überprüfung der Computer-Telefon-Bindung (Variante 1)
In diesem Abschnitt wird die erste Variante des Überprüfungsmechanismus vorgestellt. Die Überprüfung erfolgt, indem der Nutzer über ein Dialogfenster am Computer aufgefordert wird, einen
Gabelschlag am Endgerät (Hookflash) auszuführen.
In der Abbildung 16 wird davon ausgegangen, daß der Client-Computer noch keine Berechtigung für
das gewünschte Endgerät besitzt, also noch kein Eintrag in der Datenbank des Telefonieservers
vorhanden ist. Die AclOpenDevice-Anforderung leitet unter diesen Bedingungen eine Überprüfung der
Computer-Telefon-Bindung ein.
Statusbericht Mai‘98, Teil: TAPI
28
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Arbeitsplatz
(HICOM)
Telefon
Telefoniesserver
Computer
TSP
AclOpenDevice [device]
(Absender = IP-Adresse)
Monitor einrichten
1
2
CT_Bind [device, mode=hookflash]
3
wait for DIAL
Ereignismeldung: DIAL
wait for IDLE
Ereignismeldung: IDLE
4
5
Dialog
Bitte kurz den
Hörer abnehmen
T
Hookflash
T
AclOpenDevice_Result [device,typ,result=OK]
exc
6
AclOpenDevice_Result [device,typ,result=0]
T
Monitor löschen
7
T
exc
= Timer
= exception
= Telephony Service Provider
TSP
CT_Bind = Computer Telefon Bindung
Abbildung 16: Ablauf für Überprüfung mit Hookflash
Beschreibung:
1. Der Telephony Service Provider beim Client sendet ein AclOpenDevice, um die Berechtigung für
ein Endgerät zu erwerben. Unter der Annahme, daß die Absender noch nicht für das Endgerät
berechtigt ist, wird der Überprüfungsmechanismus eingeleitet.
2. Es wird ein Monitor auf das Endgerät eingerichtet, um den Hookflash zu erkennen.
3. Zum Client wird eine CT_Bind-PDU gesendet, aus der der Client entnehmen kann, daß die
Computer-Telefon-Bindung für das angegebene Endgerät mit einem Hookflash überprüft werden
soll. Der TSP zeigt daraufhin einen Dialog an, mit der Aufforderung, kurz den Hörer für die angegebene Rufnummer abzunehmen.
Im Telefonieserver wird ein Timer gestartet, der die Zeit für die Hookflash-Erkennung begrenzt.
4. Der Nutzer führt an seinem Arbeitsplatz den Hookflash aus. Im Telefonieserver wird der Zustandsübergang IDLE => DIAL => IDLE erkannt.
5. Die Überprüfung war erfolgreich. Im ACL-Server wird zur IP-Adresse die Berechtigung für die
Rufnummer eingetragen. Der Timer wird gelöscht und es wird eine AclOpenDevice_Result-PDU
zum Client gesendet, der result-Parameter wird auf 1=OK gesetzt. Beim Client wird mit Eintreffen
der PDU der Nutzerdialog geschlossen und der TSP kann in seiner lineOpen()-Prozedur fortfahren, z.B. indem er einen Monitor auf das Endgerät einrichtet.
6. Wurde innerhalb der Timer-Zeitspanne kein Hookflash erkannt, wird bei Ablauf des Timers
ebenfalls eine AclOpenDevice-PDU zum Client gesendet, der Parameter result hat dabei aber den
Wert Null. Der TSP sollte daraufhin seine lineOpen()-Prozedur mit einer Fehlermeldung beenden.
7. Der vorab eingerichtete Monitor ist wieder zu löschen.
Erweiterungen
Wenn der Nutzer an seinem Arbeitsplatz mehrere Endgeräte hat, kann parallel zu Punkt 3 an das
Endgerät eine Display-Ausgabe erfolgen, um dem Nutzer die Selektion zu erleichtern. Beispielsweise
kann der Text „PC-FERNSTEURUNG“ ausgegeben werden, aber auf keinen Fall „BITTE HOERER
KURZ ABNEHMEN“.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
29
Probleme / Erforderliche Sicherheitsmaßnahmen
Eine Sicherheitslücke ergibt sich, da der Telefonieserver normalerweise Display-Ausgaben zu anderen
Teilnehmern erlaubt (Anzeige kurzer Nachrichten). Ein „Angreifer“ könnte dies ausnutzen, indem er
zum Zeitpunkt der Anmeldung auf ein fremdes Endgerät eine Display-Nachricht wie „BITTE HOERER
KURZ ABNEHMEN“ sendet. Wenn der ahnungslose Nutzer am Endgerät dieser Aufforderung
nachkommt hätte der Angreifer die Berechtigung erlangt.

Für den Zeitpunkt der Überprüfung sollten Display-Ausgaben durch andere Teilnehmer unterdrückt werden.
Es ist auch möglich, daß bereits eine Displayausgabe wie „PC-Fernsteuerung“ einen Nutzer zu einem
Hookflash veranlassen kann, zumal, wenn er auf diesen „Reiz“ hin vorher schon einmal einen
Hookflash ausgeführt hat (um die Berechtigung für sein Endgerät zu erwerben).
Vorteile dieses Überprüfungsmechanismus


Er ist für analoge und digitale Endgeräte geeignet.
Er bedarf nur einer kurzen manuellen Handlung (Hookflash).
3.5.6 Überprüfung der Computer-Telefon-Bindung (Variante 2)
Bei dieser Variante wird die Computer-Telefon-Bindung überprüft, indem der Nutzer einen Code über
ein Dialogfenster am Computer eingeben muß, der ihm über das Telefondisplay vorgegeben wird.
Arbeitsplatz
(HICOM)
Telefon
Telefoniesserver
Computer
TSP
AclOpenDevice [device]
(Absender = IP-Adresse)
1
2
CT_Bind [device, mode=Codeeingabe]
Code
w ürfeln
Dialog
Bitte Code vom
Tel. eingeben
TDD-Ausgabe: "CODE = 123"
3
123
Code "123"
eintippen
wait for Input
4
5
CT_BindInput [code]
AclOpenDevice_Result [device,typ,result]
TDD: Display löschen
6
TSP
= Telephony Service Provider
CT_Bind = Computer Telefon Bindung
Abbildung 17: Ablauf für Überprüfung mit Codeabfrage
1. Der Telephony Service Provider beim Client sendet ein AclOpenDevice, um die Berechtigung für
ein Endgerät zu erwerben. Unter der Annahme, daß die Absender noch nicht für das Endgerät
berechtigt ist, wird der Überprüfungsmechanismus eingeleitet.
2. Zum Client wird eine CT_Bind-PDU gesendet, aus der der Client entnehmen kann, das die
Computer-Telefon-Bindung für das angegebene Endgerät mit einer Codeabfrage überprüft werden
soll. Der TSP zeigt daraufhin einen Dialog zur Codeeingabe an.
3. Im Telefonieserver wird eine Zufallszahl (Code) gewürfelt und als Textnachricht an das Telefondisplay gesendet. Ein dreistelliger Code wird als günstige Länge angesehen. Der Nutzer am ClientComputer muß den Code über das geöffnete Dialogfenster eingeben.
4. Der eingegebene Code wird vom TSP in der CT_Bind-PDU zum Telefonieserver übertragen und
dort überprüft.
5. Der Telefonieserver antwortet mit einer AclOpenDevice_Result-PDU. Der Parameter result enthält
das Ergebnis der Überprüfung (1,0).
Statusbericht Mai‘98, Teil: TAPI
30
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
6. Wenn die vorhergehende Codeausgabe als Daueranzeige erfolgte, ist das Telefondisplay wieder
zu löschen.
Bewertung dieses Überprüfungsmechanismus




Er ist nur für Endgeräte mit Display anwendbar.
Er erfordert vom Nutzer etwas mehr Aufmerksamkeit und Zeit als ein Hookflash.
Eine ungewollte Berechtigungserteilung ist ausgeschlossen.
Ein Hookflash ist somit die bessere Lösung.
3.5.7 Rechnerauthentikation bei den folgenden Sessions
In diesem Abschnitt wird der Verbindungsaufbau (AclAssociate und AclOpenDevice), ausgehend von
einer bereits überprüften RechnerEndgerät – Kombination, näher beschrieben.
Folgende Probleme sind zu lösen:

Einem überprüften Client-Rechner soll durch den Telefonieserver automatisch seine Rufnummer
zugewiesen werden, somit braucht die in Abschnitt 3.5.3 beschriebene Nutzer-Abfrage nicht täglich wiederholt werden.

Die Sicherheit des ipValidator soll erhöht werden.
Zur Lösung des ersten Punktes wurde im ACL-Server ein Verbindungsaufbau nach folgender Sequenz
implementiert:
(ACL-Server)
TSP = TAPI Service Provider
Telefonieserver
Client-Computer
TSP
1
TAPI.DLL
TAPI-Anwendung
TSPI_lineNegotiateTSPIVersion()
return
lineNegotiateApiVersion()
TSPI_providerEnumDevices()
return
lineInitialize()
return
TSPI_providerInit()
2
AclAssociate[...,ipValidator]
AclAssociate_Response[...,ipValidator,deviceList]
return
return lineInitialize()
TSPI_lineGetDevCaps()
return
lineGetDevCaps()
TSPI_lineOpen()
lineOpen()
return
return
3
4
AclOpenDevice[rufnummer]
return
5
AclOpenDevice_Result[...,result]
Abbildung 18: Verbindungsaufbau für überprüften Client-Rechner
Beschreibung:
1. Abfrage der Anzahl von lokal registrierten Endgeräten.
2. Bei AclAssociate wird als Parameter der ipValidator mit gesendet, den der Client beim letzten
AclOpenDevice_Result vom ACL-Server erhalten hat. Beim Empfang wird auch die Absenderadresse (IP-Adresse) festgestellt. Der ACL-Server vergleicht daraufhin, ob die Kombination [IPAdresse, ipValidator] mit dem Inhalt seiner Datenbank übereinstimmt.
3. War der ipValidator korrekt, wird bei AclAssociate_Response eine Liste aller Devices übertragen,
für die dieser Rechner Berechtigungen erworben hat. Die Liste wird als nullterminierter String
übertragen, wobei die Rufnummern durch Komma getrennt sind. Meist dürfte nur eine Rufnummer
enthalten sein. Auf die Funktion der deviceListe wird im Punkt 5 eingegangen.
War der ipValidator ungültig, werden alle Endgeräteberechtigungen zu dieser IP-Adresse in der
Datenbank des ACL-Servers gesperrt. Beim folgenden AclOpenDevice wird dann wieder eine
Überprüfung vorgenommen. War diese Überprüfung für ein Endgerät erfolgreich, werden alle
Endgeräteberechtigungen wieder frei geschaltet.
4. Die Anwendung fragt die Fähigkeiten des bzw. der lokalen Endgeräte(s) ab.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
31
5. TSPI_lineOpen() wird aufgerufen, wobei über den Parameter deviceID ein Device selektiert wird.
Der Service Provider entnimmt seiner lokalen Datenbank die zugehörige Rufnummer und kontrolliert anhand der deviceListe, ob er für diese noch berechtigt ist. Wenn JA braucht er kein
AclOpenDevice auszuführen.
Wenn NEIN, sendet er eine AclOpenDevice-PDU; vorher holt er sich vom Nutzer noch die Bestätigung für die Rufnummer ein (über einen Dialog).
3.6 Realisierung für TAPI 2.1
In diesem Abschnitt wird auf die Realisierung des Überprüfungsmechanismus in einer TAPI 2.1Umgebung und deren grundlegende Probleme eingegangen.
3.6.1 Verwendete APIs (Funktionen)
Für eine Implementierung in TAPI 2.1 sind Funktionen von folgenden APIs zu nutzen:

Service Provider Funktionen (TSPI_xxx), beschrieben in: [TSPI 2.0],

Client Management API Funktionen (TAPICLIENT_xxx), beschrieben in: [TAPI ClMgmt],

User Interface Funktionen (TUISPI_xxx), beschrieben in: [TSPI 2.0].
Eine Beschreibung der einzelnen Funktionen wird hier nicht vorgenommen, diese kann den angegebenen Quellen entnommen werden.
3.6.2 Mapping der Funktionalität
Ausgehend von der Implementierung des Überprüfungsmechanismus im ACL-Server, soll hier nur das
Mapping der beschriebenen Funktionalität (ACL-Server) auf die entsprechenden Komponenten der
TAPI 2.1-Umgebung erfolgen.
Die Funktionalität des ACL-Servers ist in die Komponenten Client Management DLL und Service
Provider DLL zu übertragen.
Die Funktionalität des bisherigen Client Service Providers ist in die Komponente User Interface DLL
(beim Client) zu übertragen.
Client Management DLL:
ACL-Server
AclAssociate_Req und
AclAssociate_Res
AclOpenDevice
Client Management DLL,
Funktionalität wird übernommen durch:
TAPICLIENT_lineInitialize();
Diese Funktion stellt die Parateter userName, userDomain und machineName bereit.
Der Parameter ipValidator kann dabei nicht abgebildet werden.
TAPICLIENT_lineOpen();
Die erforderlichen Parameter Rufnummer (device-ID) und Rechneradresse
(machineName) sind verfügbar. Anhand der lokalen Datenbankinformationen ist zu entscheiden, ob eine Überprüfung durchzuführen ist. Diese
Überprüfung kann innerhalb der Funktion TAPICLIENT_lineOpen erfolgen1
oder der Service Provider DLL ist ein entsprechendes Signal zu senden2.
1
Prinzipiell ist es möglich, daß die Funktion der Komponenten Client Management und Service
Provider in einer DLL vereint sind. Somit kann innerhalb von TAPICLIENT_lineOpen() auf die User
Interface Funktionen des TSPI zugegriffen werden.
2
Eine Signalisierung von der Client Management DLL zur Service Provider DLL kann über die
Manipulation der Parameter lpPermanentID oder dwAPIVersion oder über eine extra Funktion
erfolgen, die von der Service Provider DLL zu exportieren ist. Es ist nur ein Bit zu übertragen (überprüfe Computer Telefon Bindung / nicht überprüfen).
Statusbericht Mai‘98, Teil: TAPI
32
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
Service Provider DLL:
ACL-Server
Service Provider DLL,
Funktionalität wird übernommen durch:
AclOpenDevice
TSPI_lineOpen();
Wenn die Client Management DLL „Überprüfe Computer Telefon Bindung!“
signalisiert, ist es Aufgabe der Service Provider DLL diese Überprüfung mit
den Mitteln des User Interfaces durchzuführen.
CT_Bind
Über die Message LINE_CREATEDIALOGINSTANCE wird ein Dialog beim
Client erzeugt.
CT_BindInput
Bei Überprüfung mit Codeabfrage empfängt der Service Provider den Code
über die Callback-Funktion TUISPIDLLCALLBACK.
AclOpenDevice_Result
Das Ergebnis der Überprüfung kann dem Client über die Message
LINE_SENDDIALOGINSTANCEDATA und/oder
LINE_CREATEDIALOGINSTANCE mitgeteilt werden.
Die Service Provider DLL muß das Ergebnis der Überprüfung der Client Management DLL mitteilen,
damit diese ihre Datenbank aktualisieren kann. Das Ergebnis kann über einen Funktionsaufruf
übermittelt werden (extra Funktion).
User Interface DLL:
Ehemaliger Service
Provider beim Client
User Interface DLL,
Funktionalität wird übernommen durch:
Erzeugen eines Dialogs
Über die exportierte Funktion TUISPI_providerGenericDialog() wird die User
Interface DLL aufgefordert einen speziellen Dialog zu erzeugen.
CT_BindInput
Eventuelle Nutzereingaben (z.B. Code) sind über die Callback-Funktion
TUISPIDLLCALLBACK dem Service Provider mitzuteilen.
Schließen des Dialogs
Entweder durch den Nutzer oder über die Funktion
TUISPI_providerGenericDialogData (), die an die Message
LINE_SENDDIALOGINSTANCEDATA gebunden ist.
Mit dem beschriebenen Mapping der ACL-Server-Funktionalität auf die Komponenten von TAPI 2.1
kann die Überprüfung von arbeitsplatzbezogenen Berechtigungen realisiert werden.
3.7 Weitere Sicherheitsprobleme
3.7.1 DHCP (Dynamic Host Configuration Protocol)
Über das Dynamic Host Configuration Protocol können den Clients (Windows 95, Windows NT)
dynamisch IP-Adressen zugewiesen werden. Die Zuweisung übernimmt ein Windows NT Server mit
installierten DHCP-Service. Die Gültigkeitsdauer einer IP-Adressen-Zuweisung kann konfiguriert
werden (z.B. von Stunden bis zu mehreren Tagen).
Problem: Werden die Client-Rechner, nach beschriebenen Überprüfungsmechanismus, anhand der
IP-Adresse authentifiziert, wird bei Ablauf der Gültigkeitsdauer eine Überprüfung der ComputerTelefon-Bindung vorgenommen. Erfolgt z.B. täglich eine Überprüfung, kann das zu Akzeptanzproblemen führen.
Lösungsmöglichkeit: Die Authentikation des Client-Rechners erfolgt nur anhand des Parameters
ipValidator (siehe Abschnitt 3.5.7). Als zusätzliche Sicherheit kann die erwartete Gültigkeitsdauer
ausgewertet werden.
3.7.2 Sicherheitsmaßnahmen beim Monitoring von fremden Endgeräten:
Ein Monitoring von fremden Endgeräten kann z.B. innerhalb einer Nutzergruppe erlaubt sein, um
einfach den Gesprächszustand der anderen Teilnehmer optisch anzuzeigen oder Leistungsmerkmale
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
33
wie Anrufübernahme zu realisieren. Werden im Telefonieserver administrativ keine Nutzergruppen
festgelegt, kann diese Aufgabe auch vom Nutzer übernommen werden. Dazu sind dem Nutzer
folgende Informationen bereitzustellen:
 Wieviel Monitore auf sein(e) Endgerät(e) eingerichtet sind. Auf weitere Anfrage auch von welchen
Rechner aus.
 Wieviel Rechner noch Berechtigungen für sein Endgerät besitzen.
Zur Administrierung sind dem Nutzer folgende Optionen anzubieten:
 Er muß die Möglichkeit haben fremde Monitore zu sperren.
 Die Anzahl der Rechner beschränken, die sich maximal auf sein Endgerät anmelden dürfen.
 Diese Einstellungen sind im ACL-Server zur Session zu speichern.
 Er kann die momentanen Sicherheitseinstellungen abfragen.
 Ändert der Nutzer seine Sicherheitseinstellungen, ist er am nächsten Tag darüber zu informieren.
Damit wird verhindert, daß bei Abwesenheit eine andere Person die Sicherheitseinstellungen zum
eigenen Arbeitsplatz unbemerkt ändern kann.
Die genannten Sicherheitsmaßnahmen funktionieren nur für die Arbeitsplätze, die ihre Endgeräte über
eine TAPI-Anwendung steuern und somit über Sicherheitsverletzungen durch den Telefonieserver
informiert werden. Um auch Sicherheit für Nicht-CTI-Arbeitsplätze anzubieten, sollte der Telefonieserver eine Liste von Endgeräten verwalten, die für den CTI-Dienst freigeschaltet sind. Zugriffsversuche
auf andere Endgeräte werden generell abgewiesen.
3.8 Zusammenfassung
Vorteile dieses Verfahrens
Durch die Vergabe von arbeitsplatzbezogenen Berechtigungen ergeben sich folgende Vorteile:
 Es ist keine zentrale Administrierung von Nutzern erforderlich.
 Es ist für alle TAPI-Versionen anwendbar.
 Das vorhandene Sicherheitskonzept von TAPI 2.1 (namensbezogene Rechte), kann durch die
Überprüfung der Computer-Telefon-Bindung ergänzt oder ersetzt werden.
Nachteile
 Die Datenbank mit der Zuweisung von IP-Adresse zu Rufnummer läßt sich nur schwer überprüfen.
Der Administrator müßte zum Vergleich über eine korrekte Tabelle mit der Zuordnung von IPAdressen zu Rufnummern verfügen. Wird eine dynamische IP-Zuweisung für die Clients eingesetzt,
wird die genannte Überprüfung zusätzliche erschwert.
Anwendungsgebiete
 Der beschriebene Sicherheitsmechanismus ist anwendbar, wenn ein Nutzer ein oder mehrere
Endgerät(e) am Arbeitsplatz über eine Telefonieanwendung steuern will.
 Der Sicherheitsmechanismus ist nicht anwendbar, wenn von einem Rechner aus ein oder mehrere,
lokal verteilte Endgeräte gesteuert werden sollen. In diesem Fall sind namensbezogene Berechtigungen besser geeignet.
 Ein Telefonieserver sollte die Überprüfung von namensbezogenen und arbeitsplatzbezogenen
Berechtigungen beherrschen.
Statusbericht Mai‘98, Teil: TAPI
34
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
4 TAPI 3.0
4.1 Einleitung
Mit TAPI 3.0 verbindet Microsoft die Steuerung der klassischen Telefonie und der IP-Telefonie unter
einer einheitlichen Schnittstelle. Mit dem Begriff IP-Telefonie wird eine multimediale Kommunikation
(Sprache, Video und Daten) zwischen zwei oder mehreren Endpunkten bezeichnet. Die Unterstützung
für IP-Telefonie zielt dabei vordergründig auf die Kommunikation innerhalb von Unternehmen, wobei
ein LAN oder WAN ohne garantierte Bandbreite als Transportmedium genutzt wird. Eine Kommunikation mit Internet-Clients ist ebenfalls möglich. TAPI 3.0 steht somit in Konkurrenz zu
Nebenstellenanlagen, wie sie in vielen Unternehmen eingesetzt werden.
Über die Funktionalität des TAPI 3.0 APIs lassen sich eine Vielzahl von Anwendungen realisieren
(Abbildung 19).
Call Control
Application
Interactive Voice
Response (IVR)
Application
Voice Mail
Application
Call Center
Application
IP Conferencing
Application
Telephony API
(TAPI)
TAPI
klassische Telefonie
TAPI
PBX
IP-Telefonie
IP-Netzw erk
Abbildung 19: TAPI 3.0 = Konvergenz von IP- und PTSN-Telefonie [TAPI 3.0 WP]
Wesentliche Merkmale von TAPI 3.0 sind:

TAPI 3.0 stellt eine einheitliche Schnittstelle für PSTN- und IP-Telefonie mit den Leistungsmerkmalen:
Verbindungssteuerung,
und Medienzugang bereit.

Die TAPI-Schnittstelle basiert auf dem Component Objekt Modell (COM), d.h., sie ist objektorientiert und sprachunabhängig.

TAPI 3.0 nutzt die Verzeichnisdienste des Windows NT Active Directory.

TAPI 3.0 unterstützt einen Quality of Service.
Die grundlegenden Anwendungsgebiete für TAPI 3.0 sind:

Anwendungen zur Steuerung von Gesprächsverbindungen in öffentlichen und privaten Netzwerken, die auf Funktionalität von TAPI 2.x beruhen (TAPI 3.0 ist abwärtskompatibel zu TAPI2.1),

H.323 IP-Telefonie im LAN, WAN oder Internet,

IP-Multicast Conferencing im LAN, WAN oder Internet.
4.2 Architektur von TAPI 3.0
Zur Beschreibung der Architektur von TAPI 3.0 ist zu unterscheiden in APIs und Komponenten, die das
„Grundgerüst“ von TAPI 3.0 bilden, und in Service Provider, die von Fremdherstellern oder von
Microsoft bereitgestellt werden können.
Zu „Grundgerüst“ von TAPI 3.0 gehören:

Das TAPI 3.0 COM API mit den Fähigkeiten:
Call Control - Steuerung von Calls (Sprache, Daten, Video),
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
-
35
Media Stream Control - Zugriff auf den Datenstrom eines Calls (Sprache, Daten, Video),
Directory Control - Verzeichnisdienst.

Das Telephony Service Provider Interface (TSPI) - abwärtskompatibel zu TAPI 2.1.

Die TAPI-Schnittstelle von TAPI 2.1, die weiterhin unterstützt wird.

Die Komponente TAPI Server, die die TAPI-Schnittstelle (TAPI 2.1 und TAPI 3.0) vom TSPI
entkoppelt.
Media Stream
Control
Call Control
Directory Control
Call Control
RP
C
TAPI Server
3rd Party
TSP
Unimodem
LDAP
TAPI 3.0 (COM API)
TAPI 2.1 (C API)
NDIS Proxy
H.323
Window s NT
5.0 Active
Directory
Media Stream Provider
Interface (MSPI)
Telephony Service
Provider Interface (TSPI)
Unimodem
MSP
IP Multicast
H.323
MSP
IP MC
MSP
DirectShow Streaming Filter Graph
RTP
Codec
Audio/
Video
Winsock 2.0
PBX Driver
Unimodem
Driver
NDIS 5.0
Miniport
TCP/IP
PBX
Modem
ATM/ISDN NIC
NIC
PSTN
Cloud
PSTN
Cloud
ATM/
ISDN
Cloud
Abbildung 20: Architektur von TAPI 3.0 [TAPI 3.0 WP]
Microsoft liefert mit TAPI 3.0 auch gleich einige Service Provider, mit denen in einer standardisierten
Umgebung sofort TAPI-Dienste angeboten werden können. Eine standardisierte Umgebung kann z.B.
ein Modem oder ein LAN-Karte (für IP-Telefonie) sein.
Für die IP-Telefonie liefert Microsoft die Service Provider für H.323 und IP-Multicast. Die Service
Provider unterteilen sich jeweils in einen Telephony Service Provider (TSP) und einen Media Stream
Provider (MSP).
Als weitere Komponente nutzt TAPI 3.0 die Dienste des Windows NT Active Directory.
4.2.1 TAPI 3.0 COM API
Im Gegensatz zu TAPI 2.1 wurde das TAPI 3.0 API nach dem Component Object Model (COM)
definiert. Im Component Object Model wird ein Objekt über ein oder mehrere objektorientierte
Interfaces angesprochen. Das TAPI 3.0 COM API besteht aus mehreren Objekten und Interfaces, mit
dem Vorteil, jedes einzelne Interface durch eine neue Version ersetzen zu können und die alte Version
weiterhin parallel anzubieten. Als weiterer Vorteil kann das TAPI 3.0 API in verschiedene Programmiersprachen eingebunden werden, so lassen sich Anwendungen in Java, Visual Basic oder C4/C++
implementieren.
Das TAPI 3.0 COM API wird in drei funktionale Bereiche unterteilt:
4
Optional kann auch eine C-Anwendung auf das TAPI 3.0 COM API zugreifen, das C-API wird dabei über bedingte
Compilierung exportiert.
Statusbericht Mai‘98, Teil: TAPI
36
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.

Call Control COM API - insgesamt 35 Interfaces, die sich auf 5 Objekte verteilen (TAPI, Address,
Terminal, Call und Call Hub). Diese API übernimmt die bisherige Funktionalität von TAPI 2.1.

Media Stream Control COM API – dieser API-Bereich ist (nach Kenntnis des Autors) identisch
mit dem DirectShow COM API von Windows. Das DirectShow COM API bietet einen einheitlichen
Zugang zu verschiedenen Medienströmen. Die Spezifikation des APIs erfolgte nach dem RTP
Standard (RFC 1889 und 1890).

Directory Control COM API – über diese API kann eine Verbindung zu einem Verzeichnis
aufgenommen werden, um Teilnehmer zu finden oder selbst Einträge zu veröffentlichen.
Neben der definierten API-Funktionalität von TAPI 3.0 kann ein Service Provider zusätzliche Interfaces
exportieren. Dieser Mechanismus ersetzt die Extended Telephony Services der älteren TAPIVersionen.
4.2.2 TAPI Server
Der TAPI Server entkoppelt das Telephony Service Provider Interface (TSPI) von TAPI 3.0 und TAPI
2.1. Er übernimmt somit die gleiche Aufgabe, wie in älteren TAPI-Versionen, nur mit einer funktionalen
Erweiterung für IP-Telefonie.
4.2.3 Telephony Service Provider
Ein Telephony Service Provider (TSP) hat die Aufgabe, eine Verbindung zu einem oder mehreren
Teilnehmern herzustellen. Dazu muß er das TAPI Call-Modell auf ein anderes Call-Modell (z.B. ACL,
Hayes oder H.225.0 (Q.931)) abbilden und mit dessen Fähigkeiten eine Verbindung aufbauen, steuern
und abbauen.
TSPs für IP-Telefonie können Verzeichnisdienste zur Adreßauflösung nutzen. Ein Verzeichnisdienst
wandelt logische Adressen (Personenname, Name einer Konferenz, eMail-Adresse) in NetzwerkAdressen (OSI Schicht 3).
Zu einem TSP unter TAPI 3.0 kann es auch ein Media Stream Provider bereitgestellt werden (z.B.
H.323-TSP und H.323-MSP).
4.2.4 Media Stream Provider
Ein Media Stream Provider (MSP) erlaubt einer Anwendung den Zugriff auf die Daten bzw. den
Datenstrom eines Calls. Ein MSP sollte dazu das DirectShow COM API implementieren, das einen
einheitlichen Zugang zu verschiedenen Medienströmen bietet. Für spezielle Anwendungsfälle kann der
MSP auch proprietäre COM-Interfaces exportieren.
Von der funktionalen Seite hat ein MSP die Aufgabe, eine Verbindung von einer Datenquelle mit einer
Datensenke zu ermöglichen. Eine Datenquelle kann z.B. eine Soundkarte, eine Kamera oder eine
Datei sein, als Datensenke sind eine Soundkarte, ein Monitor oder eine Datei denkbar. Der MSP nutzt
zur Verbindung von Quelle und Senke spezielle Filter-Komponenten, die eine Anpassung des
Datenstromes vornehmen können, mit diesen baut er einen sogenannten Filtergraph auf. Grundlegende Filter-Komponenten werden von Microsoft bereitgestellt.
4.3 IP-Telefonie nach H.323
In diesem Abschnitt wird die TAPI 3.0-Unterstützung der IP-Telefonie nach dem H.323-Standard
vorgestellt.
4.3.1 Was ist H.323?
[H.323] (ITU-T): "Recommendation H.323 describes terminals, equipment and services for multimedia
communication over Local Area Networks (LAN) which do not provide a guaranteed quality of service.
H.323 terminals and equipment may carry real-time voice, data and video, or any combination,
including videotelephony."
H.323 definiert vier Komponenten für ein H.323-basiertes Kommunikationssystem:

Terminals,

Gateways (zählt zu equipment),

Gatekeepers (zählt zu equipment),
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.

37
Multipoint Control Units (MCUs) (zählt zu equipment).
Ein Terminal ist ein Client-Endpunkt im Netzwerk. Alle H.323-Terminals müssen Sprachkommunikation unterstützen, Video- und Daten-Unterstützung ist optional. Als Terminal dürfte meist ein MultimediaPC verwendet werden, es kann aber auch ein H.323-Telefon mit LAN-Anschluß sein.
Gateways erlauben einen Übergang zu anderen Netzwerken (z.B. PSTN), Kommunikationsprotokollen
und Datenformaten. Ein Gateway ist ein optionales Element in einer H.323-Umgebung.
Gatekeeper sind optionale Elemente in einer H.323-Umgebung. Wird ein Gatekeeper eingesetzt, ist er
u.a. dafür verantwortlich logische Adressen in Netzwerkadressen zu wandeln, die Auslastung der
Bandbreite im LAN zu kontrollieren und Zugangsberechtigungen zu erteilen.
Multipoint Control Units (MCUs) unterstützen Konferenzen zwischen drei oder mehreren Teilnehmern.
MCUs sind u.a. für die Mischung der Datenströme verantwortlich.
4.3.2 H.323 Service Provider für TAPI 3.0
Microsoft liefert zu TAPI 3.0 einen H.323 Service Provider. Der H.323 Service Provider (Telephony
Service Provider + Media Stream Provider) ermöglicht TAPI-Anwendungen multimediale Verbindungen
zu beliebigen H.323-kompatiblen Endgeräten im LAN, WAN oder im Internet aufzubauen.
Telephony Service Provider
Der TSP ist für den Aufbau und die Steuerung von Verbindungen (Sprache, Video, Daten) verantwortlich. Seine Funktionalität gliedert sich in drei Bereiche:

Für eine Adreßauflösung von Personenname, Rechnername oder eMail-Adresse in eine Netzwerkadresse nutzt er die Dienste eines ILS Dynamic Directory Servers von Microsoft. Auf den ILS
Dynamic Directory Server wird im Abschnitt 4.5 näher eingegangen.

Über Q.931-Messages (definiert in H.225.0) wird eine Setup-Connect-Sequenz mit dem ZielTerminal durchgeführt. Die Connect-Message enthält u.a. den H.245-Port (siehe nächster Punkt),

Über H.245-Messages baut der TSP logische Kanäle für Audio-, Video- oder Datenverbindungen
auf, vorher erfolgt u.a. eine Absprache unterstützter Codecs. In einer bestehenden Verbindung
kann über H.245-Messages z.B. die Bandbreite gewechselt werden.
Media Stream Provider
Der MSP baut im lokalen Endgerät einen DirectShow-Filtergraph auf, der die Ein- und Ausgabegeräte
(z.B. Soundkarte) mit dem TCP/IP-Stack verbindet und die notwendige Wandlung der Datenformate
vornimmt.
Eine detaillierte Beschreibung der Funktionsweise des H:323 TSP und MSP und deren Zusammenwirken kann hier nicht gegeben werden, dazu wären weitere Untersuchungen notwendig.
Statusbericht Mai‘98, Teil: TAPI
38
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
H.323 Conferencing Application
Call Control
Media Stream
Control
Directory Control
TAPI 3.0 COM API
RPC
TAPI Server
ILS
Dynamic
Directory
Server
LDAP
H.323 Telephony Service
Provider (TSP)
H.323 Media Stream Provider
(MSP)
Audio
Renderer
Speakers
DirectShow Streaming Filter
Graph
Sound Card
Microphone
Audio
Capture
RTP Filter
Codec
Filter
Video
Renderer
Monitor
Winsock 2.0
Video
Capture
Video
TCP/IP
Netw ork Interface
Abbildung 21: H.323 Service Provider für TAPI 3.0 [TAPI 3.0 WP]
Verwendete Standards für IP-Telefonie
RTP:
Real-Time Transport Protocol = RFC 1889,
RTCP: RTP Control Protocol = RFC 1889,
Q.931: Messages für Call Setup, Q.931 wird in Gateways zum PTSN verwendet, für H.323Endgeräte wird H.225.0 verwendet (siehe auch H.225.0),
T.120: ITU-T Recommendation, für multimedialen Datenaustausch in Konferenzen (z.B. Whiteboard),
H.323: ITU-T Recommendation, describes terminals, equipment and services for multimedia
communication over Local Area Networks (LAN), H.323 beinhaltet die folgenden ITU-T
Recomendations,
H.225.0: ITU-T Recommendation, specifies the mandatory Q.931 messages that are used for call
signalling in this Recommendation (H.323).
H.245: Call Control für multimediale Kommunikation, beinhaltet: capabiltiy exchanges, commands
and indications.
RAS:
Registration, Admissions and Status, [H.323]: „The RAS signalling function uses H.225.0
messages...“; RAS-Verbindungen bestehen zwischen Terminals und einem Gatekeeper,
G.711: ITU-T Recommendation, Audio Codec zur Übertragung von A-Law und -Law PCM mit
Bitraten von 48, 56, und 64 Kbps,
G.723: ITU-T Recommendation, Audio Codec für 5.3 und 6.3 Kbps,
G.729: ITU-T Recommendation, Audio Codec für 8 Kbps
H.261: ITU-T Recommendation, Video Codec zur Übertragung von komprimierten Videoinformationen mit 64 Kbit/s und einer Auflösung von 176x44 Pixel,
H.263: ITU-T Recommendation, Video Codec für geringe Bitraten bei einer Auflösung von 176x44
Pixel,
4.4 IP-Multicast Conferencing
Neben dem H.323 Service Provider stellt Microsoft auch einen TAPI 3.0 Service Provider für IPMulticast Conferencing bereit. IP-Multicast ist eine Erweiterung zu IP, die eine effiziente Verteilung von
Daten einer Quelle zu mehreren Empfängern erlaubt. IP-Multicast wird von einer Vielzahl5 von Routern
5
genaue Zahlen sind dem Autor nicht bekannt
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
39
im Internet unterstützt. Die effiziente Verteilung beruht auf der Tatsache, daß zwischen zwei Routern
jeweils nur eine Kopie von einem Datenpaket übertragen wird, auch wenn sich hinter dem Router
mehrere Empfänger befinden.
Beispiele für IP-Multicast Anwendungen sind:

Video- und Audio-Konferenzen im LAN, WAN oder Internet,

Verteilung von Daten,

Distance Learning.
IP-Multicast bietet gegenüber H.323 den Vorteil, daß es durch eine funktionsfähige Infrastruktur
(Router) im Internet unterstützt und bereits auch aktiv genutzt wird. Die breiteste Anwendung findet IPMulticast im Multicast Backbone (MBONE). MBONE ist ein experimentelles, globales MulticastNetzwerk, das das physische Internet überlagert. Dieses wird bereits fünf Jahre betrieben und
überträgt z.B. IETF-Meetings, Musik, Konzerte oder andere Live-Ereignisse.
Der Service Provider für IP-Multicast unterteilt sich ebenfalls in einen Telephony Service Provider mit
der Aufgabe die Adreßauflösung von Konferenznamen nach IP-Multicast-Adressen vorzunehmen und
einem Media Stream Provider, der für den Aufbau eines lokalen DirectShow-Filtergraphs verantwortlich ist.
Parallel zum TAPI 3.0 COM API wird ein Rendevous Conferencing Control API angeboten, über das
Konferenzen bekannt gemacht oder gesucht werden können.
Als ein Einsatzgebiet von IP-Multicast, lassen sich z.B. firmeninterne Konferenzen realisieren.
4.5 Gatekeeper / Windows NT 5.0 Active Directory
Das erste Problem, das sich beim Aufbau einer Verbindung ergibt, ist die Lokalisierung des Zielteilnehmers, wobei als Adreßangabe möglichst logische Namen (z.B. Personenname) zu verwenden sind.
Ausgehend von den logischen Namen ist eine Abbildung auf Netzwerkadressen notwendig, mit denen
das Transportnetzwerk (IP) eine Verbindung zum Zielteilnehmer aufbauen kann. Zur Adreßauflösung
sind Verzeichnisdienste erforderlich. Im H.323-Standard werden für diesen Dienst Gatekeeper
definiert, die über H.225.0-Messages (RAS) anzusprechen sind.
Neben der Adreßauflösung hat ein Gatekeeper u.a. die Aufgabe:

Zugriffe auf das LAN zu kontrollieren. Als Zugangskriterien können u.a. die aktuell verfügbare
Bandbreite oder die Autorisierung eines Calls gelten. Der Gatekeeper kann einen neuen Verbindungswunsch abweisen.

Den Bandbreitenbedarf der einzelnen Verbindungen zu verwalten,

Zonen-Management – der Gatekeeper bietet seine Dienste innerhalb einer Zone (z.B. Firma) an.
Unter TAPI 3.0 wird die Funktionalität des Gatekeepers von einer Komponente des Windows NT 5.0
Active Directory - dem Internet Locator Service (ILS) Dynamic Directory - erbracht. Die Einbettung des
ILS Dynamic Directory in eine TAPI 3.0-Umgebung kann der Abbildung 21 entnommen werden. Das
ILS Dynamic Directory bietet die Dienste:

Adreßauflösung und

Abfrage/Hinzufügen von Verzeichniseinträgen an.
Der H.323 TSP von TAPI 3.0 verwendet zur Adreßauflösung das Lightwight Directory Access Protocol
(LDAP), welches vom ILS Dynamic Directory unterstützt wird. Die Mapping-Informationen des
Directories werden ebenfalls über das LDAP regelmäßig aktualisiert.
LDAP ist in RFC1777 standardisiert, es definiert einen einfachen Zugriff auf ein X.500 Directory und
setzt direkt auf einem Transportprotokoll auf (z.B. TCP/IP). Die Protokoll-Parameter werden zum
größten Teil in Textform übertragen.
Statusbericht Mai‘98, Teil: TAPI
40
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
4.6 Quality of Service (QoS)
Im Gegensatz zum PSTN stellen IP-Netzwerke normalerweise keine garantierte Bandbreite für eine
Datenübertragung bereit. Die Übertragung von multimedialen Daten stellt aber besondere Anforderungen an die Bandbreite (z.B. Video) und die Verzögerung (z.B. Sprache). Eine IP-Gesprächsverbindung,
die mit der klassischen Telefonie konkurrieren will, muß auch annähernd deren Qualitätsparameter
besitzen, d.h., es dürfen keine großen Verzögerungen auftreten und es sollte eine garantierte
Bandbreite verfügbar sein.
Dieses Problem wurde auch bei TAPI 3.0 berücksichtigt, indem der DirectShow RTP-Filter (siehe
Abbildung 21) eine erforderliche Bandbreite mit dem unterlagerten Kommunikationsstack aushandeln
kann. Um einen bestimmten Quality of Service anbieten zu können, muß der eigene Kommunikationsstack und die Netzwerkkomponenten (Router, Switch) entsprechende Mechanismen bereitstellen. Auf
die Mechanismen wird im nächsten Statusbericht näher eingegangen.
4.7 Einsatz von IP-Telefonie in einem Unternehmen
Mit den Komponenten von TAPI 3.0 sowie einigen zusätzlichen Komponenten kann in einem Unternehmen eine Kommunikationsinfrastruktur für IP-Telefonie aufgebaut werden. Diese Infrastruktur kann
die klassische Nebenstellentechnik vollständig ersetzen. Die Abbildung 22 aus [TAPI 3.0 WP] zeigt ein
derartiges Szenario für ein Unternehmen mit zwei Niederlassungen, wobei zu beachten ist, daß dies
keine neue Erfindung von Microsoft und TAPI 3.0 ist, sondern auch mit Komponenten anderer Anbieter
realisiert werden kann.
Enterprise IP Network
ILS
Dynamic
Directory
Server
Public Switched
Telephone Network
IP/PSTN
Gateway
Dynamic
Directory
Conference
Server
IP Telephony Client
IP Telephony Client
Audio
Audio
Video
IP Telephony Client
Video
Enterprise IP
Network
Audio
Video
IP Telephony Client
Internet
LAN
Firewall
H.323 Proxy
MBONE Proxy
Firewall
H.323 Proxy
MBONE Proxy
IP Telephony Client
Abbildung 22: TAPI 3.0 IP-Telefonie-Infrastruktur in einem Unternehmen [TAPI 3.0 WP]
Komponenten:
Das IP/PTSN-Gateway ermöglicht die Kommunikation mit dem öffentlichen Fernsprechnetz oder auch
einer vorhandenen Nebenstellenanlage. Dies gilt für kommende und gehende Verbindungen.
Der ILS Dynamic Directory Server von Microsoft verwaltet die H.323-Clients eines Unternehmesbereiches.
Der Dynamic Directory Conference Server von Microsoft verwaltet die Konferenzen innerhalb eines
Unternehmes.
Ein H.323 Proxy erlaubt den H.323-Clients Verbindungen über das Internet aufzubauen, wobei er die
Unternehmensstruktur nach außen verdecken soll.
Statusbericht Mai‘98, Teil: TAPI
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.
41
Der MBONE-Proxy hat übernimmt die gleiche Aufgabe, wie der H.323-Proxy, nur für IP-Multicast.
Interne Konferenzen dürfen von außen nicht zugänglich sein.
Als Nutzerschnittstelle wird eine TAPI 3.0-Anwendung benötigt.
4.8 Zusammenfassung

Mit TAPI 3.0 verbindet Microsoft die Steuerung der klassischen Telefonie und der IP-Telefonie
unter einer einheitlichen Schnittstelle. Zusätzlich erlaubt TAPI 3.0 den Zugriff auf den Datenstrom
einer Verbindung (Sprache, Video und Daten).

TAPI 3.0 ist somit u.a. für Anwendungen interessant, die klassische und IP-Telefonie unterstützen
wollen.

Für die IP-Telefonie werden Service Provider für H.323 und IP-Multicast bereitgestellt.

TAPI 3.0 nutzt die Verzeichnisdienste des Windows NT Active Directory.

Es wird ein Quality of Service für IP-Telefonie unterstützt.

Die Bereich IP-Telefonie wird vorerst nur unter Windows NT 5.0 verfügbar sein, somit ist mit keiner
sofortigen Akzeptanz durch die Hersteller von IP-Telefonieanwendungen zu rechnen. Dies dürfte
sich erst mit einer Unterstützung von Windows 95, 98 und NT 4.0 ändern.

Der Bereich Call Control von TAPI 3.0, der auch unter Windows 95 und älteren NT-Versionen
verfügbar sein soll, wird eher von Anwendungen genutzt werden. Ein Vorteil ergibt sich hier u.a.
durch das objektorientierte API.

TAPI 3.0 ist, besonders durch die Marktpräsenz von Microsoft, als Konkurrenz zu klassischer
Nebenstellentechnik zu beachten.
5 Zusammenfassung und Weiterführung des Themas
5.1 TAPI 2.1
Im ersten Teil des Berichtes wurde die aktuelle TAPI 2.1-Version mit folgenden Schwerpunkten
vorgestellt:

Die TAPI 2.1-Architektur und deren Komponenten unterstützen aktiv eine Client-ServerUmgebung.

TAPI 2.1 kann in Verbindung mit einem Telefonieserver eines Fremdherstellers oder in einer
Windows NT Domain betrieben werden. Der Einsatz in einer reinen Novell-Umgebung ist nicht zu
empfehlen.

Als Sicherheitsmechanismus wird eine Nutzerauthentikation unterstützt, die auf dem Windows NT
Security Service beruht. Es wird aber keine Datenverschlüsselung zwischen Client und Server
angeboten.

Über das Client Management API kann der TAPI-Server um Management- und Sicherheitsfunktionen erweitert werden.
5.2 Arbeitsplatzbezogene Berechtigungen
Im zweiten Teil wurde ein Verfahren zur Vergabe von arbeitsplatzbezogenen Berechtigungen in einer
TAPI-Umgebung vorgestellt und spezifiziert. Als Ergebnisse sind zu nennen:

In einem PaCT-System mit Telefonieserver können arbeitsplatzbezogenen Berechtigungen die
nutzerbezogenen Berechtigungen ersetzen oder ergänzen, wenn eine Steuerung der Endgeräte
am Arbeitsplatz erfolgen sollen.
Statusbericht Mai‘98, Teil: TAPI
42
Error! Use the Home tab to apply Überschrift 1 to the text that you want to appear here.

Das Verfahren ist für alle TAPI-Versionen anwendbar.

Der zentrale Administrierungsaufwand kann eingespart werden.
5.3 TAPI 3.0
Siehe Abschnitt 4.8.
5.4 Themen für weitere Forschungsarbeiten

Die Untersuchungen zu den Komponenten und Mechanismen von TAPI 3.0 können fortgesetzt
werden,

JTAPI – Stand der Entwicklung, vorhandene und mögliche Anwendungen/Szenarien,

Weiterführung des Themas „Implementierung eines Zustandsautomaten“ aus dem Statusbericht
Dez‘96,
Statusbericht Mai‘98, Teil: TAPI
Anhang
43
Anhang A
Beispiel für ein IDL-File für eine „Hello World“-Anwendung
//file hello.idl
[
uuid(7a98c250-6808-11cf-b73b-00aa00b677a7),
version(1.0)
]
interface hello
{
void HelloProc([in, string] unsigned char * pszString);
void Shutdown(void);
}
mögliche Transportprotokolle für RPC unter Windows
[Win32 SDK] RPC: Datatypes and Structures – String Binding










TCP over IP,
(Connection-oriented)
TCP over NetBIOS,
(Connection-oriented)
IPX over NetBEUI,
(Connection-oriented)
NetBIOS over NetBEUI,
(Connection-oriented)
named pipes,
(Connection-oriented)
SPX,
(Connection-oriented)
DECnet transport,
(Connection-oriented)
UDP over IP,
(connectionless)
IPX,
(connectionless)
Local (cross-process) procedure call
von Windows 95 nicht unterstützt
von Windows 95 nicht unterstützt
unter Win95 nur für Client-Applic.
nur für MSDOS und Win16
RPC - Authentication Services
[Win32 SDK] RPC: Datatypes and Structures
Authentication Service
Beschreibung
RPC_C_AUTHN_DCE_PRIVATE
DCE private key authentication
RPC_C_AUTHN_DCE_PUBLIC
DCE public key authentication (reserved for future use)
RPC_C_AUTHN_DEC_PUBLIC
DEC public key authentication (reserved for future use)
RPC_C_AUTHN_DEFAULT
Default authentication service
RPC_C_AUTHN_NONE
No authentication
RPC_C_AUTHN_WINNT
NTLMSSP (NT LAN Manager Security Support Provider)
[http://www.microsoft.com/ntserver/guide/security_faq.asp?A=2&B=9]:
Windows NT Server 5.0, entering beta test later this year, will improve security interoperability even
further with support for Kerberos authentication.
Statusbericht Mai‘98, Teil: TAPI
44
Anhang
Anhang B
RPC - Authentication Levels für RpcBindingSetAuthInfo
[Win32 SDK] RPC: Datatypes and Structures
Authentication Level
Beschreibung
RPC_C_AUTHN_LEVEL_DEFAULT
Uses the default authentication level for the specified
authentication service.
RPC_C_AUTHN_LEVEL_NONE
Performs no authentication.
RPC_C_AUTHN_LEVEL_CONNECT
Authenticates only when the client establishes a
relationship with the server.
RPC_C_AUTHN_LEVEL_CALL
Authenticates only at the beginning of each remote
procedure call when the server receives the request.
Does not apply to remote procedure calls made using
the connection-based protocol sequences (those that
start with the prefix "ncacn"). If the protocol sequence in
a binding handle is a connection-based protocol
sequence and you specify this level, this routine instead
uses the RPC_C_AUTHN_LEVEL_PKT constant.
RPC_C_AUTHN_LEVEL_PKT
Authenticates that all data received is from the expected
client.
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY Authenticates and verifies that none of the data
transferred between client and server has been modified.
RPC_C_AUTHN_LEVEL_PKT_PRIVACY
Authenticates all previous levels and encrypts the
argument value of each remote procedure call.
Note For Windows 95 platforms, RPC_C_AUTHN_LEVEL_CALL, PC_C_AUTHN_LEVEL_PKT,
RPC_C_AUTHN_LEVEL_PKT_INTEGRITY, and RPC_C_AUTHN_LEVEL_PKT_PRIVACY are
only supported for a Windows 95 client communicating with a Windows NT server. These levels
are never supported for a Windows 95 client communicating with a Windows 95 server.
Struktur-Definition _SEC_WINNT_AUTH_IDENTITY für Windows NT:
typedef struct _SEC_WINNT_AUTH_IDENTITY{
unsigned short RPC_FAR* User;
unsigned long
Userlength;
unsigned short RPC_FAR* Domain;
unsigned long
Domain Length;
unsigned short RPC_FAR* Password;
unsigned long
Password length;
}
// Username als String
// Domainname als String
// Paßwort als String
Remarks
The SEC_WINNT_AUTH_IDENTITY structure allows you to pass a particular user name and
password to the runtime library for the purpose of authentication.
Statusbericht Mai‘98, Teil: TAPI
Anhang
45
Anhang C
Sicherheitsrelevante RPC-Funktionen, die von den Komponenten TAPISRV.EXE und
REMOTESP.TSP aufgerufen (importiert). Die aufgelisteten Funktionen sind in der RPCRT4.DLL (RPC
Run-Time) enthalten.
RPC-Funktion
TAPISRX.EXE
RpcServerRegisterAuthInfoA
RpcBindingFromStringBindingW
RpcBindingSetAuthInfoA
RpcServerRegisterIf
RpcServerUseProtseqEpA
RpcImpersonateClient
RpcRevertToSelf
RpcStringBindingComposeW
RpcBindingFromStringBindingA
RpcStringBindingComposeA
RpcServerRegisterAuthInfoA
...A = ASCII
...W = Wide-Character
x
x
x
x
x
x
x
x
Statusbericht Mai‘98, Teil: TAPI
REMOTESP.TSP
x
x
x
x
x
x
x
x
x
46
Verzeichnisse
Abbildungsverzeichnis
Abbildung 1: Client-Server-Architektur bei TAPI 2.1.................................................................................6
Abbildung 2: Einsatz von TAPI 2.1 mit fremden Telefonieserver .............................................................8
Abbildung 3: TAPI 2.1 Server in einer Windows NT Domain Umgebung.................................................9
Abbildung 4: Einfügen eines TAPI 2.1 Servers in eine Netware-Umgebung ..........................................10
Abbildung 5: Integriertes TAPI Client Management................................................................................11
Abbildung 6: TAPI Administration Tool ...................................................................................................13
Abbildung 7: User Interface Konzept ......................................................................................................15
Abbildung 8: Stackaufbau für RPC .........................................................................................................16
Abbildung 9: RPC-Sequenz mit Client-Authentikation am Beispiel der Funktion HelloProc() ................17
Abbildung 10: Kommunikationsstack für Client-RPCs ...........................................................................19
Abbildung 11: Kommunikationsstack für Server-RPCs ..........................................................................19
Abbildung 12: Endgerätezugriff durch den Nutzer am Arbeitsplatz ........................................................22
Abbildung 13: Systemkonfiguration für TAPI 1.0 bis TAPI 2.0 ...............................................................23
Abbildung 14: Sicherheitsinformationen im PaCT-System .....................................................................25
Abbildung 15: Anfangssequenz beim Start einer TAPI-Anwendung ......................................................26
Abbildung 16: Ablauf für Überprüfung mit Hookflash .............................................................................28
Abbildung 17: Ablauf für Überprüfung mit Codeabfrage.........................................................................29
Abbildung 18: Verbindungsaufbau für überprüften Client-Rechner ........................................................30
Abbildung 19: TAPI 3.0 = Konvergenz von IP- und PTSN-Telefonie [TAPI 3.0 WP] .............................34
Abbildung 20: Architektur von TAPI 3.0 [TAPI 3.0 WP] ..........................................................................35
Abbildung 21: H.323 Service Provider für TAPI 3.0 [TAPI 3.0 WP]........................................................38
Abbildung 22: TAPI 3.0 IP-Telefonie-Infrastruktur in einem Unternehmen [TAPI 3.0 WP] ....................40
Tabellenverzeichnis
Tabelle 1 : Beschreibung eines RPC mit Authentikation ........................................................................17
Tabelle 2: RPC Parameterbeschreibung ................................................................................................18
Statusbericht Mai‘98, Teil: TAPI
Verzeichnisse
47
Quellenverzeichnis
[Stat 12/96]
HTW Mittweida, Statusbericht Dezember’96
[Stat 9/97]
HTW Mittweida, Statusbericht September’97
[TAPI 2.1 SDK - 1]
TAPI 2.1 SDK – readme.txt
[TAPI ClMgmt]
TAPI 2.1 Microsoft TAPI Client Management, TAPI 2.1 SDK
[TAPI Admin]
Microsoft TAPI 2.1 Administration Tool, TAPI 2.1 SDK
[TAPI 2.1 WP]
TAPI 2.1 WhitePaper, 1997,
http://microsoft.com/backoffice/communications/tapi21learnmore.htm
[TSPI 2.0]
http://premium.microsoft.com/msdn/library/
SDK Documentation - Platform SDK - Networking and Distributed Services TSPI 2.0
[WinNT_Net]
Microsoft Windows NT Server Networking Guide, Microsoft Press, 1996
[Win32 SDK]
Win32 Software Development Kit (z.B. von Microsoft Visual C++ 4.0)
[Win32 SDK - 1]
Win32 SDK – RPC: OSF Standards for RPC
[Win32 SDK - 2]
Win32 SDK – RPC: Run-Time RPC Functions – Using Authenticated RPC
[Schenck FAQ]
http://ourworld.compuserve.com/homepages/SCHENCK/tapifaq.txt
[TAPI 3.0 WP]
IP Telephony with TAPI 3.0, White Paper, 1997,
http://www.microsoft.com/ntserver/guide/whitepapers.asp
[OSF DCE-Secur]
http://www.camb.opengroup.org/tech/dce/security/
[DFS]
Distributed File Systems
(http://www.transarc.com/afs/transarc.com/public/www/Public/ProdServ/Product/
DFS/Seybold/dfssey.html)
[TAPI3.H]
http://premium.microsoft.com/msdn/library/sdkdoc/c494_7kq9.htm
[News TAPI 3.0]
Newsgroup von TAPI 3.0: microsoft.public.win32.programmer.tapi.beta
[H.323]
ITU-T Recommendation H.323
Statusbericht Mai‘98, Teil: TAPI