1 Zertifikate in HiPath

Transcrição

HiPath
Verwendung von Zertifikaten in HiPath
Allgemeine Beschreibung
bkTOC.fm
Nur für den internen Gebrauch
Inhalt
Inhalt
0
1 Zertifikate in HiPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1 Allgemeine Übersicht – PKI und Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1.1 PKI (Public Key Infrastructure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1
1.1.2 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3
1.2 Derzeitige Verwendung und Handhabung von Zertifikaten in HiPath . . . . . . . . . . . . . 1-6
1.2.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6
1.2.2 Protokolle, die Zertifikate nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7
1.2.2.1 Protokolle, die zum Schutz TLS verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9
1.2.2.2 MIKEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11
1.2.2.3 IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
1.2.2.4 IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14
1.2.3 Anwendungen, die Zertifikate verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
1.2.3.1 Softwareverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
1.2.4 Zertifikatserstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
1.2.4.1 HG1500/HG3550 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15
1.2.4.2 HiPath 4000 Assistant (UW7) und Manager. . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.2.4.3 CAP V3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.2.4.4 DLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16
1.2.5 Zertifikatsverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.2.5.1 HG1500/HG3550 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.2.5.2 HiPath 4000 Assistant (UW7) und Manager. . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.2.5.3 HiPath 8000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-17
1.2.6 Zertifikatswiderruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18
1.3 Varianten bei der Zertifikatshandhabung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
1.3.1 Benutzerzertifikate im Vergleich zu Gerätezertifikaten . . . . . . . . . . . . . . . . . . . . 1-19
1.3.1.1 Allgemeine Betrachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19
1.3.1.2 Betrachtungen in Bezug auf HiPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21
1.3.2 Zertifikatserstellungsmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22
2 Profilerstellung bei Sicherheitsoptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1 Schlüsselverwaltungsprotokolle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
2.1.1 Aktuelles Verwaltungsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1
6. Juni 2008
Verwendung von Zertifikaten in HiPath, Allgemeine Beschreibung
0-3
bkTOC.fm
Inhalt
Nur für den internen Gebrauch
3 Technischer Anhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.1 TLS-Grundwissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.1.1 TLS - Übersicht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.1.2 Anonyme TLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5
3.1.3 Unilateral authentifiziertes TLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6
3.1.4 Gegenseitig authentifiziertes TLS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8
3.1.5 TLS-Sitzungswiederaufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-9
3.1.6 Erweiterte TLS-Sitzungswiederaufnahme: Umgehen des serverseitigen Zustands. 311
3.1.7 Erweiterte TLS-Schlüsselverwaltung: TLS-PSK. . . . . . . . . . . . . . . . . . . . . . . . . . 3-13
3.1.8 TLS-Handshake - Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
3.1.9 Datagramm-TLS – Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
3.2 MIKEY-Schlüsselverwaltungsoptionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15
3.2.1 Symmetrische Schlüsselverteilung (Preshared-Keys) . . . . . . . . . . . . . . . . . . . . . 3-16
3.2.2 Asymmetrische Schlüsselverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-17
3.2.3 Durch digitale Signaturen geschützte Diffie-Hellman-Schlüsselvereinbarung . . . 3-18
3.2.4 Ungeschützte Schlüsselverteilung (nur mit Vorsicht anzuwenden) . . . . . . . . . . . 3-19
3.2.5 MIKEY-Erweiterung: Durch Preshared-Secrets geschützte Diffie-Hellman-Schlüsselvereinbarung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20
3.2.6 MIKEY-Erweiterung: Asymmetrische Schlüsselverteilung mit Zertifikatsaustausch per
Innenband-Signalisierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21
3.2.7 MIKEY-Anwendung: Bootstrapping von TESLA – Übersicht . . . . . . . . . . . . . . . . 3-22
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Stichwörter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1
Abkürzungen
0-4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1
6. Juni 2008
c01.fm
Zertifikate in HiPath
Allgemeine Übersicht – PKI und Zertifikate
1
Dieser Abschnitt bietet eine generelle Übersicht über Zertifikate und deren Generierung,
Bereitstellung und Widerruf mit besonderem Augenmerk auf zukünftige Architekturen. Davon ausgehend ist die Verwendung von Zertifikaten in den verschiedenen in HiPath genutzten Protokollen beschrieben. Dies beinhaltet auch die derzeit in H.323, SIP und MIKEY genutzten Sicherheitsoptionen sowie die Anwendung von Zertifikaten in IEEE 802.1x.
1.1
Dieser Abschnitt enthält eine generelle Übersicht zum Thema PKI und Näheres zum Thema Zertifikate. Die allgemeinen Begriffe im Zusammenhang mit PKI sind hier für ein besseres Verständnis der nachfolgenden Informationen kurz erläutert. Verweise auf geeignete
Quellen für weitere Detailinformationen sind ebenfalls enthalten.
1.1.1
PKI (Public Key Infrastructure)
Generell steht PKI für eine sichere, verlässliche und skalierbare Methode für den gesamten Lebenszyklus von Schlüsselmaterial, d. h. das Generieren, Verteilen und Abfragen von
öffentlichen Schlüsseln zwecks Geheimhaltung, Sicherstellung der Richtigkeit und Absenderverifizierung. Darüber hinaus bindet die PKI den Eigentümer anhand eines digitalen
Zertifikats an den öffentlichen Schlüssel und ermöglicht so die Identifizierung von Benutzern und Komponenten, die solche Zertifikate nutzen. Außerdem werden Statusinformationen während der Lebensdauer dieser Bindung von der Generierung bis zum Widerruf
aufrecht erhalten und verteilt.
Key Generation
Certification
Authority - CA
Registration
Authority - RA
Revocation Lists
Bild 1-1
Key / Certificate
Archive
Key
Distribution
Public Directory
PKI-Komponenten
Die folgende Aufstellung bietet einen Überblick über die verschiedenen Komponenten:
6. Juni 2008
1-1
c01.fm
●
●
●
●
●
●
Registration Authority (RA) Registrierungsstelle. Diese authentifiziert den Benutzer
bzw. die vom Benutzer übergebenen Daten, führt eine Berechtigungsprüfung aus und
veranlasst die Generierung des Zertifikats durch die CA.
Certification Authority (CA) Zertifizierungsstelle. Hierbei handelt es sich um eine
vertrauenswürdige Entität, die öffentliche Schlüssel zertifiziert und Zertifikate ausstellt.
Key /Certificate Archive Schlüssel-/Zertifikatsarchiv. Dies ist die Aufbewahrungsstelle, wo die CA Sicherungskopien von Zertifikaten und / oder generierten Schlüsselpaaren hinterlegt.
Key Generation Schlüsselgenerierung. Diese Funktion der PKI sorgt für die Generierung von Schlüsselmaterial (öffentliche und private Schlüssel), das von der CA zertifiziert wird.
Public Directory Zertifikatsveröffentlichungsstelle. Dies ist eine (üblicherweise öffentlich zugängliche) Datenbank, in der die CA alle ausgestellten Zertifikate speichert.
Revocation Lists (Widerrufslisten) Auch dies ist eine öffentlich zugängliche Datenbank, in der die CA alle widerrufenen Zertifikate speichert.
Trust Center (TC) ist ein Begriff, der normalerweise angewendet wird, wenn keine weitere
Unterscheidung zwischen den unterschiedlichen Komponenten erfolgt. Somit fasst ein TC
die Funktionen einer CA zusammen und kann ggf. auch eine Registrierungs- oder Aufbewahrungsstelle enthalten. Ein monolithisches TC besteht sowohl aus der RA als auch der
CA, während ein geteiltes TC die RA einer anderen Organisation überantwortet.
HiPath_PKI beschreibt die allgemeinen Aspekte einer PKI einschließlich dem Lebenszyklus von Zertifikaten (Schlüsselgenerierung, Speicherung, Transport, Archivierung und Widerruf). Diese Informationen sind hier nicht wiederholt, stattdessen wird auf dieses Dokument verweisen. Nachfolgend sind PKI-Eigenschaften beschrieben, auf die in HiPath_PKI
nicht eingegangen wird.
1-2
6. Juni 2008
c01.fm
Sign Public
Self-Signed CA Key of Peer CA
Self-Signed CA
Self-Signed CA
Root CA
Root CA of
Company A
Sign Public Key of
Subordinate CA
Subordinate CA
of Company A
Subordinate CA
of Company B
Sign Public
Key of Peer CA
Hierarchical Signing
Bild 1-2
Root CA of
Company B
Root CA of
Company A
Root CA of
Company C
Cross-Certification
PKI-Vernetzungskonzepte
Die Nutzung einer PKI kann auf die Zertifizierung der Benutzerauthentifizierung von Mitarbeitern und die Komponentenauthentifizierung von Firmenservern innerhalb eines Unternehmens beschränkt werden. Dies ist üblicherweise der erste Schritt in Richtung einer
PKI. Zur Erzielung einer internationalen oder gar globalen auf Zertifikaten basierenden Infrastruktur zur Benutzerauthentifizierung können mithilfe von PKI-Vernetzungstechnologien einzelne PKIs vernetzt werden, um internationale und interoperable Trust-Infrastrukturen mit Provider-übergreifender Authentifizierung zu schaffen. Zu den wichtigsten PKIVernetzungskonzepten zählen hierarchisches Signieren, gegenseitige Zertifizierung,
Bridge-CA-Architekturen und vertrauenswürdige Listen (siehe PKIVernetzungskonzepte2.)
1.1.2
Zertifikate
Name:
Credential ties
a name or identity
to a public key
Peter Lustig
Address: Blumenallee,
Munich, Germany
Public Key:
Expires:
Credential
expiration
Issuer:
Signed:
Bild 1-3
Name of the Trust Center
12/2005
TC Name
The authenticity of the
certificate is guaranteed
by the digital signature
generated using the
TC’s private key
TC’s Signature
Allgemeiner Inhalt eines Zertifikats
6. Juni 2008
1-3
c01.fm
Zertifikate sind digitale Dokumente, die die Bindung eines öffentlichen Schlüssels an eine
Person oder eine andere Instanz bescheinigt. Sie gestattet einerseits die Überprüfung der
Behauptung, dass ein bestimmter öffentlicher Schlüssel einer bestimmten Person bzw. Instanz zugewiesen ist. Andererseits untermauern Zertifikate die Bescheinigung der Gültigkeit des öffentlichen Schlüssels durch ein Trust Center (siehe Abschnitt PKI (Public Key Infrastructure)).
Allgemeiner Inhalt eines Zertifikats zeigt, welche Informationen üblicherweise in Zertifikaten enthalten sind. Je nach beabsichtigter Nutzung können so genannte Zertifikatserweiterungen noch weitere Informationen enthalten. Folgende Zertifikatserweiterungen sind
gebräuchlich:
– Schlüsselverwendung – zur Beschreibung der Verwendungsbestimmungen des
Schlüsselmaterials (z.B. Verschlüsselung, digitale Signaturen)
– CRL-Verteilungspunkt – zur Angabe über den Abrufort der Zertifikatswiderrufsliste
– Alternativer Subjektname – zur Zuweisung alternativer Namen einer Instanz
HiPath_PKI beschreibt ebenfalls allgemeine Aspekte in Bezug auf Zertifikate wie z.B. deren Lebenszyklus (Schlüsselgenerierung, Speicherung, Transport, Archivierung und Widerruf).
Es gibt unterschiedliche Arten von Zertifikaten (vgl. RFC 3280)
:
–
–
–
1-4
Identitätszertifikate binden den Namen einer Instanz an einen öffentlichen Schlüssel.
Benutzer- auch Server- bzw. Komponentenzertifikate sind typische Beispiele hierfür.
Die Spezifikation hinsichtlich X.509 ist in RFC 3280 enthalten.
Wildcard-Zertifikate gestatten das Sichern mehrerer Websites mit einem einzigen Zertifikat. Für eine Organisation, die eine einzigen Domänennamen mit mehreren Subdomänen (z. B. www.globalsign.net, support.globalsign.net, secure.globalsign.net) hostet, ist das Wildcard-Zertifikat eine kostengünstige und einfache Art, sämtliche
Subdomänen zu sichern, ohne für jede Subdomäne ein separates Zertifikat verwalten
zu müssen. Nachteilig an Wildcard-Zertifikaten ist, dass sie keinem dedizierten System zugewiesen werden können.
Attributzertifikate nach X.509 RFC 3280 binden anstelle eines öffentlichen Schlüssels
einen Satz deskriptiver Datenelemente entweder direkt an einen Subjektnamen oder
an die ID eines anderen, auf einem öffentlichen Schlüssel beruhenden Zertifikats. Mit
dieser Art von Zertifikaten sollen (potenziell kurzlebige) Attribute eines bestimmten
Subjekts übermittelt werden, um eine einfache, flexible und skalierbare Privilegienverwaltung zu ermöglichen. Ein Beispielsszenario für die Verwendung eines Attributzertifikats wäre ein Benutzer, dessen Benutzerzertifikat und zusätzliches Attributzertifikat
zum Drucken über einen dedizierten Druckerserver berechtigt. Attributzertifikate dienen eher der Autorisierung als der Authentifizierung, da das Attributzertifikat an ein
Identitätszertifikat gebunden ist.
6. Juni 2008
c01.fm
Zur Standardisierung werden von der PKIX-Arbeitsgruppe der IETF (Public Key Infrastructure (X.509)) [W3PKIX] Format, Typen und Handhabung von Zertifikaten definiert. PKIX
definiert ITU PKI-Standards, entwickelt aber auch neue Standards in Bezug auf die Nutzung von X.509-basierten PKIs im Internet. Beispiele sind u. a. das Certificate Management Protocol (CMP) (RFC 2510), das Online Certificate Status Protocol (OCSP) (RFC
2560)und das Certificate Management Request Format (CMRF) (RFC 2511).
6. Juni 2008
1-5
c01.fm
Derzeitige Verwendung und Handhabung von Zertifikaten in HiPath
1.2
Derzeitige Verwendung und Handhabung von Zertifikaten in
HiPath
1.2.1
Allgemein
Derzeit machen verschiedene Teile der HiPath-Architektur von Zertifikaten Gebrauch. Der
Begriff „HiPath-Architektur“ bezieht sich in diesem Zusammenhang grundsätzlich auf die
SIPSEC2-Architektur, also HiPath 3000 V7, HiPath 4000 V4 und HiPath 8000.
Innerhalb der HiPath-Architektur werden verschiedene Arten von Identitätszertifikaten verwendet:
– Serverzertifikate beziehen sich auf allgemein zugänglich Serverkomponenten.
– Gerätezertifikate (Clientzertifikate)
Im nächsten Abschnitt sind die Protokolle, die in HiPath Zertifikate nutzen, sowie der Zweck der
verwendeten Zertifikate beschrieben.
1-6
6. Juni 2008
c01.fm
1.2.2
Protokolle, die Zertifikate nutzen
HTTP(S), TLS, …
Internet
Intranet
H.323, TLS
CorNet IP/TS,
HTTP(S), …
Administration
IP
optiPoint
HiPath 5000
HiPath 3000
HG 1500
S2M, S0 (ISDN)
optiPoint
SIP, TLS
HTTP(S)
SIP cl
OpenScape
H.323, (SIP)
HTTP(S),TLS
H.323, (SIP)
CorNet IP,
HTTP(S), TLS
ApplicationServer
HTTP(S),
SIP, TLS, …
HTTPS using
a proprietary
XML Scheme
H.323, SIP,
CorNet IP/TS,
HTTP(S), TLS
DLS
HiPath
Xpression
s
SIP
Overlay
SIP, (H.323), TLS
HTTP(S), IPSec,
MGCP, …
ISDN
SIP cl
HiPath
8000
HG 3550
optiPoint
HG 3530
HG 3530
ISDN
IP
optiPoint
H.323, CorNet IP/TS
HTTP(S), TLS, …
Bild 1-4
HG 3550
HiPath 4000
optiPoint
HiPath 4000
TDM
HiPath-Systeminteraktion
Viele Anwendungsschicht-Protokolle nutzen in gewissem Maß TLS zum Schutz des Nachrichtenaustauschs zwischen zwei Teilnehmern. Diese Protokolle sind hier im nachfolgenden Unterabschnitt zusammengefasst, da sie TLS als gemeinsame Grundlage haben. Bei
6. Juni 2008
1-7
c01.fm
den verschiedenen Anwendungsschicht-Protokollen dürfte nur die Verwendung variieren.
Außer TLS gibt es noch andere Protokolle, die Zertifikate wie IEEE802.1x. IPSec oder MIKEY verwenden.
HiPath-Systeminteraktion 4 verschafft eine allgemeine Übersicht über die HiPath-Landschaft und über verschiedene im HiPath-Kontext verwendete Protokolle. Die Abbildung erhebt keinen Anspruch auf Vollständigkeit, sondern soll nur einen Eindruck von der Vielfalt
der verwendeten Protokolle vermitteln.
Im nächsten Abschnitt sind die Protokolle, die in HiPath Zertifikate nutzen, sowie der
Zweck der verwendeten Zertifikate beschrieben.
1-8
6. Juni 2008
c01.fm
1.2.2.1
Protokolle, die zum Schutz TLS verwenden
TLS ist im technischen Anhang (vgl. „TLS-Grundwissen“ auf Seite 3-1) beschrieben und
wird hier nicht näher erläutert. TLS wird zusammen mit verschiedenen Protokollen zum
Schutz der Protokolldaten der oberen Schicht eingesetzt. Generell ist für die Verwendung
von TLS keine Standard-Cipher-Suite vorgesehen. Die folgende Tabelle bietet einen Überblick über die einzelnen Protokolle und deren Verwendung von Zertifikaten:
Protokoll
HTTP(S)
SIP
Beschreibung, Verwendung von TLS
– Zweck: Schutz von Administrationsdaten
– Unilaterale Authentifizierung mit serverseitigem Zertifikat
– Benutzerauthentifizierung über Benutzernamen/Passwort in Form
einer HTTP-Digestauthentifizierung mit gegenseitig bekanntem Geheimnis.
– Port (Standard): 443
– Zweck: Schutz von SIP-Signalisierungsdaten
– Unilaterale Authentifizierung mit serverseitigem Zertifikat. Client-Authentifizierung erfolgt über das Anwendungsschicht-Protokoll.
– Authentifizierung auf Anwendungsschicht (SIP) für Dienst mittels
Benutzernamen und Passwort in Form einer HTTP-Digestauthentifizierung mit gegenseitig bekanntem Geheimnis über eine Serverauthentifizierte (unilaterale) TLS-Verbindung. Diese Vorgehensweise kommt bei Telefon-/Server-Kommunikation zum Einsatz.
– Hinweis: Gegenseitige Authentifizierung ist über gerätebasierte Zertifikate auf Server- und Clientseite auf TLS-Ebene möglich. Da die
Zertifikate gerätebasiert sind, ist keine Benutzerauthentifizierung
(außer dass der Administrator das Passwort für den Zugriff auf den
privaten Schlüssel kennt) für die Server-/Server-Komunikation vorgesehen. Dieses Konzept ist unter Umständen für ankommende
TLS-Verbindungen interessant. Für HiPath ist es derzeit ohne Bedeutung. Vielmehr werden vorhandene TLS-Verbindungen wiederverwendet, um die Anfrage zum Client zu senden.
– Port (Standard): TLS: 5061 (sonst 5060)
6. Juni 2008
1-9
c01.fm
Protokoll
H.323
CorNet IP
DLS
Bootstrapping
1-10
– Zweck: Schutz von H.323-Signalisierungsdaten
– Unilaterale Authentifizierung mit serverseitigem Zertifikat. Client-Authentifizierung erfolgt direkt über das Anwendungsschicht-Protokoll
oder durch Wiederaufnahme einer für den CorNet-TS-Schutz verwendeten TLS-Sitzung, bei der eine Benutzerauthentifizierung vorgenommen wurde.
– Authentifizierung auf Anwendungsschicht (H.323) für Dienst mittels
Benutzernamen und Passwort in Form einer auf H.235.1 basierenden Authentifizierung mit gegenseitig bekanntem Geheimnis, falls
keine TLS-Verbindung genutzt wird. (H.323 nutzt nach Möglichkeit
die bereits bestehende TLS-Verbindung für CorNet TS.)
– Hinweis: Gegenseitige Authentifizierung ist über gerätebasierte Zertifikate auf Server- und Clientseite auf TLS-Ebene möglich. Da die
Zertifikate gerätebasiert sind, ist keine Benutzerauthentifizierung
(außer dass der Administrator das Passwort für den Zugriff auf den
privaten Schlüssel kennt) für die Server-/Server-Komunikation vorgesehen. Dieses Konzept ist unter Umständen für ankommende
TLS-Verbindungen interessant.
– Port (Standard): CS 1720 (RAS 1719, keine Verwendung durch CorNet)
– Zweck: Schutz von CorNet IP-Signalisierungsdaten
– Serverseitige Authentifizierung mittels gerätebasierter Zertifikate
auf Server-TLS-Seite. Client-Authentifizierung erfolgt über das Anwendungsschicht-Protokoll.
– Authentifizierung auf Anwendungsschicht (CorNet IP) für Dienst mittels Benutzernamen und Passwort ähnlich einer H.235.1-basierenden Authentifizierung mit gegenseitig bekanntem Geheimnis.
– Port (Standard): CorNet-TC4060; CorNet über TLS: 4061
– Zweck: Schutz von Signalisierungsdaten während des Bootstrapping-Vorgangs
– Gegenseitige Authentifizierung über standardmäßige gerätebasierte Zertifikate auf Serverseite und einem Wildcard-Zertifikat auf der
Clientseite auf TLS-Ebene. Während des Bootstrapping-Vorgangs
kommt es zum Austausch gerätebasierten Schlüsselmaterials (Zertifikat und privater Schlüssel, Stammzertifikat zur Validierung des
Serverzertifikats), das im späteren Verlauf zur gegenseitigen Authentifizierung verwendet wird.
– Beachten Sie, dass die Authentifizierung (als echte Siemens DLSAnwendung) auf Anwendungsschicht anhand der in die Software integrierten Zertifikate und privaten Schlüssel erfolgt.
6. Juni 2008
c01.fm
Protokoll
DLS
Kommunikation
Tabelle 1-1
– Zweck: Schutz von Signalisierungsdaten während der DLS-Kommunikation
– Gegenseitige Authentifizierung über gerätebasierte Zertifikate auf
Server- und Clientseite auf TLS-Ebene. Da die Zertifikate gerätebasiert sind, ist keine Benutzerauthentifizierung vorgesehen (außer
dass der Benutzer/Administrator das Passwort für den Zugriff auf
den privaten Schlüssel kennt, wenn die Installation während der
Bootstrap-Phase erfolgt ist)
Protokolle, die TLS verwenden
Hinweis: Es wurde entschieden, die Benutzerauthentifizierung auf Anwendungsschicht zu
halten, statt gegenseitige Authentifizierung in TLS zu diesem Zweck zu nutzen. In HiPath
gibt es derzeit keine Szenarien, bei denen die TLS-Verbindungs-Peers nicht mit den auf
der Anwendungsschicht authentifizierten Peers identisch sind. Daher erfolgt die gegenseitige Authentifizierung auf unterschiedlichen Protokollschichten.
Die oben erwähnten Protokolle gelten grundsätzlich für alle Komponenten der HiPath-Architektur. Von den Diensten werden möglicherweise unterschiedliche Zertifikate verwendet
(beispielsweise wird das für sicheren Verwaltungszugriff genutzte Zertifikat nicht für einen
sicheren Zugang in Multimedia-Szenarien verwendet), da Namensräume voneinander getrennt bleiben sollten.
1.2.2.2
MIKEY
MIKEY wird hier separat behandelt, da es verschiedene Schlüsselverwaltungsmodelle
(vgl. Abschnitt „Datagramm-TLS – Übersicht“ auf Seite 3-14), auch zertifikatbasierte Sicherheitsdienste, unterstützt. Generell bietet MIKEY die folgenden Optionen:
1.
Kein Schutz des MIKEY-Containers
2.
Schutz des MIKEY-Containers mithilfe von
●
Verteilung auf Preshared-Secret-Basis
●
Asymmetrische Verteilung
●
Asymmetrische Diffie-Hellman-Vereinbarung
●
Symmetrische Diffie-Hellman-Vereinbarung (DHMAC) Erweiterung von
( RFC 3830)
●
Übernommene asymmetrische Verteilung (DRSAR Erweiterung von
( RFC 3830))
Folgende MIKEY-Optionen werden im HiPath-Kontext unterstützt:
6. Juni 2008
1-11
c01.fm
1.
Nolnnticated gegenüber der vertrauenswürdigen Serverkomponente in der Registrierungsphase
2.
Verteilung auf Preshared-Secret-Basis. In diesem Fall wird der MIKEY-Container durch ein gegenseitig bekanntes Geheimnis geschützt. Das gegenseitig bekannte Geheimnis wird vom HiPath-Anrufverarbeitungssystem pro Anruf ausgewählt und nach Bedarf über eine TLS-gesicherte Verbindung an Endpunkte (z.B.
Telefone und Clients, die CorNet-TS nutzen) verteilt. Diese MIKEY-Option gilt für
DMC-Verbindungen ohne TLS als Signalisierungsschutz. Eine End-to-End-Benutzerauthentifizierung erfolgt nicht, aber da sich der Teilnehmer üblicherweise
bei der Anmeldung gegenüber dem HiPath-Anrufverarbeitungssystem authentifiziert, genießt er transitives Vertrauen.
3.
Asymmetrische Diffie-Hellman-Verteilung. Dies wäre zurzeit nur mit gerätebasierten Zertifikaten möglich, da Benutzerzertifikate nicht unterstützt werden. Da
die Zertifikate aber an ein Gerät statt an einen Benutzer gebunden sind, ist keine
End-to-End-Benutzerauthentifizierung möglich. Das ist kein Problem, solange die
Kommunikation ausschließlich über Netzwerkkomponenten erfolgt (z. B. können
sich beim Trunking zwei Gateways mittels gerätebasierter Zertifikate gegenseitig
authentifizieren), da diese Geräte ohnehin gerätebasierte Zertifikate nutzen. Außerdem ist ein gewisses transitives Vertrauen (durch eine dritte Komponente) gegeben, da das normale Verfahren folgendermaßen aussähe:
●
Benutzer 1 registriert sich über Client 1 bei einem zentralen Server.
●
Die Registrierung erfolgt über eine gegenseitig auf Gerätebasis authentifizierte Verbindung zwischen Client 1 und dem registrierenden Server.
●
Die Benutzerauthentifizierung geschieht auf Anwendungsschicht mittels Benutzernamen und Passwort.
MIKEY#1 or #3 maybe
d
H.323 +
CorNet-
H.323/SIP Node
SIP/ SIP-
DMC
Proxy
MIKEY#0 or
MIKEY
H.323 Node
SIP Node
SIP
HFA
A
SIP
DMC
connection
H.323 +
CorNet-
DMC
connection A
B
B
MIKEY#1 or
1-12
6. Juni 2008
c01.fm
Bild 1-5
Vom Verbindungstyp abhängige MIKEY-Optionen
●
Benutzer 2 führt dasselbe aus wie Benutzer 1.
●
Wenn beide Benutzer der zentralen Enterprise-Server-Infrastruktur vertrauen, so vertrauen sie der Art und Weise, wie der Server die Benutzer authentifiziert hat und damit auch den von einem Client über den Server zum anderen Client gesendeten Benutzerinformationen. Dieser Ansatz beruht letztlich
auf transitivem Vertrauen durch Hop-to-Hop-Sicherheit und unterscheidet
sich im Grunde nicht von Option 0. Der zusätzliche Vorteil liegt in der durchgängigen Gewähr, dass das Peer-Gerät über ein von der richtigen Zertifizierungsstelle signiertes Zertifikat verfügt, sowie in der Tatsache, dass der
SRTP-Master-Key zu keinem Zeitpunkt an einem der (möglicherweise Hackerangriffen ausgesetzten) Zwischenknoten unverschlüsselt zugänglich ist.
●
Aus dieser Sicht bietet Option 3 bei Nutzung gerätebasierter Zertifikate dieselbe Sicherheit.
Transitives Vertrauen kann für Benutzer innerhalb einer Unternehmensumgebung gelten.
Wird eine Kommunikation mit externen Teilnehmern gewünscht (sei es über den Zentralserver oder direkt), gilt es möglicherweise nicht. Bei Szenarien mit direkter Benutzerinteraktion über IP-Netzwerke wäre eine Benutzerauthentifizierung nur mittels benutzerbasierter Zertifikate oder anderer Methoden möglich. Die Nutzung benutzerbasierter Zertifikate
in HiPath bedarf noch weiterer Untersuchungen.
>
Eine Unterstützung der MIKEY-Option 2 in HiPath nicht vorgesehen. Möglicherweise
wird zukünftig Option 5 unterstützt, da sie den Austausch von Zertifikaten per Innenband-Signalisierung unterstützt.
802.1X Switch
10:53
RADIUS Server
MON 14 JUL 03
6936
>
HiPath
LAN Port
LAN
Ethernet 10 Mb/s or 100 Mb/s
optiPoint
IP Phone
3
1
Bild 1-6
2
IEEE802.1X mit IP-Telefon
6. Juni 2008
1-13
c01.fm
1.2.2.3
IEEE 802.1X
IEEE802.1X ist ein Standard zur Übertragung des EAP (Extensible Authentication Protocol) über ein verdrahtetes bzw. drahtloses LAN. Man spricht daher auch von EAP-Verkapselung über LANs (EAPOL). Damit bietet sich ein Rahmen für mehrere unterschiedliche
Authentifizierungsmethoden. IEEE802.1X mit IP-Telefon ist ein typisches Nutzungsszenario. Der Benutzer bzw. Client (optiPoint), der authentifiziert werden möchte, ist der „Supplicant“. Der die Authentifizierung vornehmende Server (üblicherweise ein RADIUS-Server)
wird als Authentifizierungsserver bezeichnet. Das dazwischenliegende Gerät, z.B. ein
Switch, ist der „Authenticator“.
>
Wie Zertifikate erstellt und an Server und Client verteilt werden, ist in der Administrationanleitung IEEE 802.1x Konfigurations Management, (A31003-J4200-M100-xA9) beschrieben beschrieben.
In der HiPath-Umgebung werden gerätebasierte Zertifikate innerhalb IEEE 802.1X zur Authentifizierung der Komponenten gegenüber der Netzwerkinfrastruktur verwendet. Je nach
angewendeter EAP-Methode - z.B. EAP-TLS, wobei TLS auf der Ethernet-Schicht verkapselt wird - kann gegenseitige Authentifizierung erfolgen. Der Supplicant in den optiPointGeräten unterstützt auf gegenseitigen Zertifikaten basierende TLS-Authentifizierung für
802.1x mit EAP-TLS.
Hinweis: Das Hauptproblem besteht in der Installation der optiPhone- und RADIUS-Server-Stammzertifikate im Telefon in einem 802.1x-fähigen Netzwerk. Ohne die Zertifikate
kann sich das optiPhone nicht gegenüber dem Zugangs- Switch authentifizieren, d. h. weder der DHCP-Server kann zum Abruf einer IP-Adresse noch der DLS zum Abruf von Zertifikaten kontaktiert werden. Bei einer Plug-and-Play-Lösung muss der Port am ZugangsSwitch so konfiguriert werden, dass das Telefon auf ein Gast- oder Fallback-VLAN (üblicherweise für nicht länger als ca. 10 Minuten) gelegt wird, falls die 802.1x-Authentifizierung
fehlschlägt. Das Gast- oder Fallback-VLAN muss zulassen, dass eine Verbindung zu einem DHCP-Server und DLS hergestellt wird, damit Zertifikate abgerufen werden können.
Wird das Telefon danach erneut authentifiziert, wird es auf das normale LAN bzw. VLAN
gelegt.
1.2.2.4
IPSec
In einer HG1500-/HG3550-Umgebung werden Zertifikate vom VPN auf Basis von IPSec
zur Authentifizierung während der Schlüsselverwaltungsphase mit IKE (Internet Key Exchange) genutzt. Gerätebasierte Zertifikate werden hier ebenfalls verwendet.
In HiPath 8000 dient IPSec hauptsächlich zwei Zwecken. Der erste Verwendungszweck
bezieht sich auf die Management- und Verwaltungsschnittstelle. Hier schützt IPSec den
Zugang zum HiPath 8000-System von verschiedenen Adminstrationsclients aus (sei es direkt oder über die Netzverwaltungskonsole). Der zweite Verwendungszweck ist der Schutz
des Media Gateway-Steuerungsprotokolls, d. h. die Signalisierung zwischen HiPath 8000
und den Media Gateways.
1-14
6. Juni 2008
c01.fm
1.2.3
Anwendungen, die Zertifikate verwenden
1.2.3.1
Softwareverteilung
Die Softwareverteilung geschieht in der HiPath-Umgebung mittels DLS-Server. Die vom
DLS-Server bereitgestellten Software-Images werden digital mit einem privaten Schlüssel
signiert, der ausschließlich zum Signieren von Software-Images dient. Das Empfangsbzw. Zielsystem kann die Integrität der zu installierenden Software durch Verifizierung der
Signatur überprüfen, die dem Softwarepaket in Form eines in die Firmware des Zielsystems integrierten Zertifikats zuzuordnen ist.
>
1.2.4
Siehe hierzu auch Administrationanleitung IEEE 802.1x Konfigurations Management (A31003-J4200-M100-x-A9).
Zertifikatserstellung
Da Zertifikate bereits in HiPath verwendet werden, stehen Möglichkeiten zur Zertifikatserstellung bereit. Der folgende Unterabschnitt bietet einen Überblick über die verschiedenen
Pakete zur Zertifikatserstellung.
1.2.4.1
HG1500/HG3550
In HG1500-/HG3550-Umgebungen verwenden WBM und VPN Zertifikate zur Authentifizierung aufgrund von PKC-Algorithmen (PKC=Public-Key Cryptography) auf der Basis von
IPSec.
In eine Umgebung, in der der Kunde keine eigene PKI betreibt, wird von HG1500/HG3550
zusätzlich eine sehr einfache und sehr eingeschränkte CA-Funktionalität bereitgestellt
(„PKI light“).
Diese CA beruht auf IPSec-Software von SSH Communications Corp. und unterstützt Folgendes:
– Generierung von Schlüsselpaaren aus privaten/öffentlichen Schlüsseln
– Signierung und Ausstellung von Zertifikaten; die Ergebnisse werden als PKCS
#12-Dateien gespeichert
– CRL-Generierung; das Ergebnis wird in einer Datei gespeichert
Folgendes wird von einer integrierten „PKI light“-Lösung nicht unterstützt:
– Certificate Enrollment-Protokolle wie CMP (RFC 2510) und SCEP (von CISCO
Systems vorgegeben) – dies muss manuell durch Service-Techniker erfolgen.
– Öffentlich zugängliche Zertifikats und CRL-Aufbewahrungsstelle – daher muss
die CRL analog zu den Zertifikaten verteilt werden
6. Juni 2008
1-15
c01.fm
1.2.4.2
HiPath 4000 Assistant (UW7) und Manager
HiPath 4000 Assistant/Manager unterstützt sicheren Zugang über HTTPS mit öffentlichen
Schlüsselzertifikaten (nur Server-Authentifizierung).
Verfügt der Kunde über keine eigene PKI, stellt HiPath Assistant eine sehr einfache und
eingeschränkte CA-Funktionalität bereit („PKI light“).
Diese CA beruht auf OpenSSL und unterstützt Folgendes:
– Generierung von Schlüsselpaaren aus privaten/öffentlichen Schlüsseln
– Signierung und Ausstellung von Zertifikaten; die Ergebnisse werden als PEM-formatierte X.509-Dateien gespeichert
Folgendes wird von einer integrierten PKI-Lösung nicht unterstützt:
– CRL-Generierung
– Zertifikat- und CRL-Aufbewahrungsstelle
1.2.4.3
CAP V3.0
In einer CAP V3.0-Umgebung dienen Zertifikate zum Schutz der Kommunikation zwischen
CAP-Instanzen. Auch CAP V3.0 beinhaltet, damit der Kunde von der Verfügbarkeit einer
PKI-Lösung unabhängig ist, eine eigene PKI-Lösung auf der Grundlage der Lösung für HiPath 4000 Assistant. Folgende zusätzliche Funktionen sind verfügbar:
– Unterstützung gegenseitiger Authentifizierung zwischen CAP-Instanzen
– Massenverwaltung (Erstellung einer Reihe von Zertifikaten – z.B. eines pro Instanz – in einem Schritt)
– Kerberos-Unterstützung (CAP V3.0 in OpenScape V3.0)
1.2.4.4
DLS
Die Kommunikation zwischen DLS-Server und Workpoints (optiPoint, optiClient, optiPocket) wird durch TLS abgesichert (Server-authentifiziert). Beachten Sie, dass die Workpoints das vom DLS-Server beim Bootstrapping (URL-Vergleich mit Subjektnamen in Zertifikat) verwendete Zertifikat nicht vollständig verifizieren (können), da es sich hier um ein
Wildcard-Zertifikat handelt. Allerdings überprüfen die Workpoints, ob dieses Zertifikat von
der standardmäßigen Stamm-CA signiert wurde. Da keine Instanzen-Authentifizierung erfolgt, sind Man-In-The-Middle-Szenarien nicht auszuschließen.
Zusätzlich wird der DLS-Server mit einem öffentlichen Schlüssel (keinem Zertifikat) ausgeliefert, dessen zugehöriger privater Schlüssel von einer Siemens-eigenen CA generiert
wird. Der öffentliche Schlüssel ist auch Teil des Software-Images von optiPoint-Geräten
(optiClient hat keinen solchen öffentlichen Schlüssel). Dieser private Schlüssel dient zur
Authentifizierung des DLS als echten Siemens DLS auf der Anwendungsschicht:
1-16
6. Juni 2008
c01.fm
–
–
Jede Anforderungsnachricht von optiPoint an den DLS enthält eine nach dem Zufallsprinzip generierte Byte-Sequenz (Challenge).
Die Antwort seitens des DLS beinhaltet (außer sonstigen Informationen) die Challenge und eine Signatur, die vom optiPoint-Gerät verifiziert werden kann.
DLS unterstützt noch NICHT den Import von von einer Kunden-PKI für Workpoints generierten Zertifikaten. Dies ist derzeit nur mit DLS-intern generierten, Workpoint-bezogenen
Zertifikaten sowie mit dem Zertifikat der Stamm-CA vom DLS.
1.2.5
Zertifikatsverteilung
In den folgenden Unterabschnitten ist erläutert, von welchen Komponenten Zertifikate importiert oder exportiert werden können.
1.2.5.1
HG1500/HG3550
In HG1500/HG3550 wurde Folgendes implementiert:
– Import von durch eine externe CA signierten Zertifikaten über PKCS #12-Dateien
– IPSec hat einen eigenen LDAP-Client implementiert; darüberhinaus ist ein weiterer LDAP-Client verfügbar und wird von anderen Anwendungen genutzt.
– Generierung und Export von CSR (Certificate Signing Request) über PKCS#10formatierte Dateien.
– Import/Export von Zertifikaten über X.509-Dateien
1.2.5.2
HiPath 4000 Assistant (UW7) und Manager
In HiPath 4000 Assistant/Manager wurde Folgendes implementiert:
– Generierung und Export (über PEM-formatierte X.509-Dateien) des CSR (Certificate Signing Request).
– Import von durch eine externe CA signierten Zertifikaten über PEM-formatierte
X.509-Dateien
– Export von durch die integrierte CA generierten/signierten Zertifikaten über PEMformatierte X.509-Dateien
1.2.5.3
HiPath 8000
Die folgenden Informationen gelten für HiPath 8000 und spiegeln Anforderungen und aktuelle Lösungsansätze wider.
6. Juni 2008
1-17
c01.fm
hiQ/HiPath-Produkte, die eine verbreitete Nutzung von Zertifikaten für beliebige Zwecke
erfordern, benötigen PKI-Unterstützung. PKI-Unterstützung wird beispielsweise im Zusammenhang mit Payload-Verschlüsselung und nicht-persistenten TLS-Verbindungen benötigt, um die Präsenz eines Zertifikats an jedem SIP-Endpunkt (z. B. optiPoint-SIP-Telefone, optiClient, RG8700-Gateways usw.) zu ermöglichen.
>
Hinweise zur Konfiguration der Endgeräte finden Sie im HiPath 8000 optiPoint SIP
7 Administrationshandbuch (A31003-J4270-M100-x-76A9).
Darüber hinaus erfordern hiQ8000, der ComServ. von hiQ4200 und HiPath 8000 die Unterstützung separater X.509-Zertifikate pro Business Group für TLS-geschützte SIPSchnittstellen. Derzeit stellt die HiPath 8000 ein einziges systemweites Zertifikat (X.509)
für die TLS-Serverauthentifizierung bereit.
Da es hier auch um SIP-Telefone geht, soll für die zentrale Verwaltung und Bereitstellung
von Zertifikaten für die in „Aktuelles Verwaltungsmodell“ auf Seite 2-1 beschriebenen Geräte und Gateways der DLS (Deployment Server) genutzt werden.
1.2.6
Zertifikatswiderruf
Allgemein liefern die folgenden Mechanismen Statusinformationen im Falle eines Zertifikatswiderrufs:
– OCSP – Online Certificate Status Protocol. Dieses Protokoll ermöglicht einem
System, den Widerrufsstatus zum Zeitpunkt der Verifizierung bei einer CA abzurufen. Der Nachteil von OCSP ist, dass die CA online sein muss.
– CRLs - Certificate Revocation Lists. Widerrufslisten werden entweder von der CA
verteilt oder können bei der CA heruntergeladen werden. Diese Listen werden üblicherweise zu festgelegten Zeiten aktualisiert.
Es sollte eine Unterstützung für Zertifikatswiderruf erfolgen, wenn eine der folgenden
Schnittstellen unterstützt wird:
– CMP - Certificate Management Protocol. Dies ist ein standardisiertes Protokoll
(RFC 2510) für die automatische Verwaltung des Zertifikatslebenszyklus.
– SCEP - Simple Certificate Enrollment Protocol. SCEP ist ein von Cisco Systems,
Inc. vorgegebenes PKI-Kommunikationsprotokoll.
Eine weitere Möglichkeit im Zusammenhang mit Zertifikatswiderruf ist, den Zertifikatsstatus auf einem LDAP-Server zu speichern. Der LDAP-Server kann als eine Art von Firmenverzeichnis betrachtet werden, auf dem der Status aller im Unternehmen verwendeten
Zertifikate abrufbereit ist. Jedes angeschlossene Gerät kann den Status eines Zertifikats
durch Übermittlung der Seriennummer und des Ausstellers des fraglichen Zertifikats abfragen. Der LDAP-Server hat die Aufgabe, den Zertifikatsstatus jederzeit auf dem neuesten Stand zu halten. Dies verringert die Schnittstellenzahl an Clients, da die Abfrage des
Zertifikatsstatus über LDAP erfolgt.
1-18
6. Juni 2008
c01.fm
Varianten bei der Zertifikatshandhabung
1.3
Im folgenden Abschnitt werden mehrere Ansätze vorgestellt, wie die Zertifikatshandhabung in HiPath verbessert bzw. optimiert werden kann. Verbesserungsmöglichkeiten bieten sich in folgenden Bereichen:
– Unterstützung von benutzer- und gerätebasierten Zertifikaten
– Zertifikatserstellung, und zwar im Hinblick auf die Unterstützung eigener „Mini“PKIs ausschließlich für HiPath- oder kundenbasierte PKI-Lösungen.
– Zertifikatsverteilung, insbesondere im Hinblick auf verschiedene Schnittstellen,
Protokolle und Umgebungen
1.3.1
Benutzerzertifikate im Vergleich zu Gerätezertifikaten
1.3.1.1
Allgemeine Betrachtungen
Benutzerzertifikate werden Personen aufgrund einer bestimmten Form der Identifikation
zugeordnet. VeriSign stellt beispielsweise Zertifikate in so genannten Klassen aus, wobei
Zertifikate der Klasse 1 online auf der Grundlage einer gültigen E-Mail-Adresse erteilt werden, während Zertifikate der Klasse 2 zwar ebenfalls online, jedoch aufgrund persönlicherer Daten als einer bloßen E-Mail-Adresse ausgestellt werden. Zertifikate der Klasse 3 beruhen auf denselben Daten wie Zertifikate der Klasse 2, erfordern aber darüber hinaus
noch das persönliche Erscheinen des Antragstellers.
Gerätezertifikate müssen an Daten gebunden sein, die von anderen Instanzen überprüft
werden können. Ein typisches Beispiel sind auf Webservern verwendete Serverzertifikate
z. B. zum Schutz des Zugangs zu Administrationszwecken bzw. zum Online-Banking. Hier
steht der Domänenname im Feld Subject bzw. Distinguished Name des Zertifikats. Der
Browser kann den Namen für die IP-Adresse problemlos der vom DNS-Server empfangenen Nachricht entnehmen und diese Information mit dem im Zertifikat angegebenen Namen vergleichen. Stimmen die Namen überein, kann die Verbindung als vertrauenswürdig
gelten. Dennoch sind, da die Diskussionen um DNS-Sicherheit noch nicht abgeschlossen
sind und diese Form der Sicherheit noch nicht weit verbreitet ist, bestimmte Angriffe möglich, auch wenn sie mit höherem Aufwand verbunden sein dürften.
Ein auf anderen Informationen als einem eindeutigen, überprüfbaren Namen beruhendes
Gerätezertifikat wird von Zertifizierungsstellen normalerweise nicht ausgestellt. In bestimmten Umgebungen, wo eine geschlossene Benutzergruppe miteinander kommuniziert, kann etwas anderes als ein eindeutiger Name in das entsprechende Feld des Zertifikats eingesetzt werden. Ein Beispiel wäre die MAC-Adresse, die jeder Netzwerkkarte
einzeln zugewiesen wird. Beachten Sie, dass dies eine eigene CA zur Ausstellung von auf
MAC-Adressen basierenden Zertifikaten erfordern würde, da keine öffentliche CA eine solche Dienstleistung anbietet. MAC-Adressen gelten zwar im Allgemeinen als eindeutig, sind
dies aber nur bedingt, da es ein Leichtes ist, einen Computer mit einer anderen MACAdresse als derjenigen zu konfigurieren, die gegenüber der Netzwerkkarte angegeben
6. Juni 2008
1-19
c01.fm
wird. Darüber hinaus ist die MAC-Adresse nur innerhalb eines Subnetzes sichtbar, so dass
eine von außerhalb des eigenen Subnetzes empfangene Nachricht keine Korrelation zulässt. (Nichtsdestoweniger können MAC-Adressen innerhalb eines Subnetzes mittels arp
abgefragt werden. In manchen Umgebungen sind über nbtstat –A auch Abfragen über die
Subnetzgrenzen hinaus möglich, solange die Firewall eine Kommunikation über Port 139
zulässt. Beachten Sie, dass die im Zertifikat enthaltenen Informationen für den verbundenen Teilnehmer überprüfbar sein muss, was in dem oben erwähnten Fall der MAC-Adresse
nicht unbedingt gegeben ist. Ein weiteres Beispiel kann ein gerätebasiertes Zertifikat sein,
das auf der Seriennummer des Geräts beruht. Die Seriennummer kann während des Produktionsvorgangs an das Gerät übermittelt werden und lässt sich dann nicht mehr ändern.
Häufig wird das Vertrauensverhältnis allerdings nur für eine bestimmte Sitzung benötigt,
was durch ein gerätebasiertes Zertifikat in Verbindung mit zusätzlichen Diensten erzielt
werden kann.
Ein allgemeines Problem bei gerätebasierten Zertifikaten ist die Schaffung einer Bindung
des Zertifikats an das Gerät bei gleichzeitiger Bindung des Geräts an einen Benutzer. Die
beschriebene Lösung, bei der die MAC-Adresse in Zertifikaten mit Protokollen wie ARP
verwendet wird, stellt nur eine Teillösung dar, da die MAC-Adresse nur innerhalb eines bestimmten Subnetzes und nicht über die Grenzen einer Domäne hinaus bekannt ist. Darüber hinaus gelten MAC-Adressen und das ARP-Protokoll nicht unbedingt als sicher.
Alternativ lassen sich Gerätezertifikate zur Absicherung von Multimedia-Kommunikation
erstellen, indem selbstsignierte Zertifikate direkt am Endgerät (optiPoint) generiert werden, die nur so lange gültig sind, wie der Benutzer angemeldet ist.
1-20
6. Juni 2008
c01.fm
1.3.1.2
Betrachtungen in Bezug auf HiPath
Wie in den Abschnitten weiter oben bereits erwähnt, werden in HiPath nur gerätebasierte
Zertifikate verwendet. Die folgende Tabelle enthält einen Vergleich zwischen gerätebasiertem und benutzerbasiertem Schlüsselmaterial, sowohl unter allgemeinen Aspekten als
auch im Hinblick auf VoIP-Kommunikation in HiPath. Der Vergleich beruht auf der Annahme, dass benutzerbasierte Zertifikate in Kombination mit gerätebasierten Zertifikaten verwendet werden. Das ist insofern sinnvoll, als dass gerätebasierte Zertifikate bereits in HiPath-Umgebungen genutzt werden, z.B. für den Zugang zum DLS-Server oder für
Verwaltungszwecke. Die nachfolgende Tabelle bietet einen Überblick über die Anwendbarkeit von Zertifikaten in HiPath je nach Zertifikatstyp (geräte- oder benutzerbasiert).
Sicherheitsdienst
Unterstützung
von gerätebasiertem
Schlüsselpaar
Authentifizie- Geräteauthentirung
fizierung
Integrität
Vertraulichkeit
Tabelle 1-2
Unterstützung Auswirkung in HiPath
von benutzerbasiertem
Schlüsselpaar
Benutzerauthen- Für den Dienstzugang und End-to-Endtifizierung
Verbindungen können unterschiedliche
Berechtigungsnachweise erforderlich
sein.
Hop-to-Hop-In- Hop-to-Hop- und Setzt voraus, dass das Stammzertifikat
tegritätsschutz, End-to-End-Inte- der ausstellenden Zertifizierungsstelle
begrenzter End- gritätsschutz
allen Teilnehmern bekannt und das Verto-End-Integritrauen aller Teilnehmer genießt. In einer
tätsschutz (BinEnterprise-Umgebung kann dies eindungsproblem)
fach, in einer offenen Umgebung jedoch
schwierig sein. (Näheres hierzu siehe
folgende Abschnitte.)
Hop-to-Hop-Ver- Hop-to-Hop- und Setzt voraus, dass das Stammzertifikat
schlüsselung,
End-to-End-Ver- der ausstellenden Zertifizierungsstelle
begrenzte End- schlüsselung
allen Teilnehmern bekannt und das Verto-End-Vertrauen aller Teilnehmer genießt. In einer
schlüsselung
Enterprise-Umgebung kann dies einfach
(Bindungsprobsein, da hier das Vertrauensverhältnis
lem)
„gegeben“ sein kann. In einer offenen
Umgebung können zusätzliche Maßnahmen (siehe weiter unten) nötig sein.
Gerätebasierte im Vergleich zu benutzerbasierten Zertifikaten
Bei der globalen Kommunikation spielt die Schlüsselverwaltung bei der Schaffung eines
Vertrauensverhältnisses zwischen zwei kommunizierenden Instanzen eine entscheidende
Rolle. Dies ist oft nur über Umwege möglich. Die folgende Aufstellung enthält Punkte, die
bei der Schaffung eines Vertrauensverhältnisses zu beachten sind:
6. Juni 2008
1-21
c01.fm
–
–
–
1.3.2
Globale Benutzerzertifikate und private Schlüssel (erfordern eine globale PKI
oder zumindest Brücken-CAs bzw. Kreuzzertifizierung zwischen verschiedenen
Sicherheitsdomänen).
Von vertrauenswürdigem Dritten stammende Benutzernamen-/Passwortkombinationen. Das Bootstrapping dieser Kombinationen ist mühsam und schlecht skalierbar
Lokale Zertifikate, denen innerhalb einer Sicherheitsdomäne vertraut wird, sind
externen Parteien möglicherweise unbekannt.
Zertifikatserstellungsmodelle
Zertifikate für die Multimedia-Kommunikation können folgendermaßen generiert werden:
– Durch eine globale CA wie VeriSign
Dies ist eine verbreitete Lösung für Webserver-Zertifikate, aus Kundensicht aber möglicherweise zu teuer
–
–
–
Von einer firmeneigenen CA generiert und damit möglicherweise nur innerhalb
der Sicherheitsdomäne nutzbar, es sei denn, die CA ist kreuzzertifiziert bzw. gehört zu einer Brücken-CA.
Von einer produkt-/anwendungsinternen CA und damit nur im Zusammenhang mit
einer bestimmten Anwendung nutzbar
Selbst-generiert
Zumindest die beiden letzteren Varianten bieten nicht unbedingt ausreichende Sicherheit,
da das Zertifikat nicht von einer vertrauenswürdigen CA stammt und daher nicht allgemein
verifizierbar ist. In der Multimedia-Kommunikation ist dies jedoch nicht unbedingt erforderlich. Die Einschränkung kann mithilfe eines vertrauenswürdigen Dritten umgehen (siehe
folgender Abschnitt). Wird ein verwendetes Zertifikat von einer allgemein vertrauenswürdigen Instanz bestätigt, kann es während einer Sitzung zur Schaffung einer Sicherheitszuordnung verwendet werden, die nur für die Dauer einer bestimmten Sitzung gültig ist.
1-22
6. Juni 2008
c02.fm
Profilerstellung bei Sicherheitsoptionen
Schlüsselverwaltungsprotokolle
2
Dieser Abschnitt konzentriert sich auf die sichere Nutzung von Multimediaprotokollen in
der HiPath-Umgebung, insbesondere auf die Definition von Profilen zur Sicherstellung der
Interoperabilität verschiedener Siemens-Produkte. Aspekte zum Thema Schlüsselverwaltung und Identitätsverwaltung werden ebenfalls berücksichtigt. Beachten Sie, dass die im
vorigen Abschnitt beschriebene Zertifikatshandhabung die Grundlage für einige der hier
vorgestellten Optionen bildet. Des Weiteren sind, soweit bekannt, Informationen über das
Interworking mit Drittanbiter-Produkten enthalten.
2.1
2.1.1
Aktuelles Verwaltungsmodell
Nachfolgend ist der aktuelle Stand der Schlüsselverwaltung in SIPSEC2 beschrieben:
1.
Bootstrapping gerätebasierter Berechtigungsnachweise (Verwendung für DLS-Kommunikation und Dienstzugang)
Werkseinstellungen: Das Telefon ist werksseitig mit einem Standardzertifikat und zugehörigem privaten Schlüssel versehen. Das Zertifikat ist von der selbstsignierten
(Stamm-) CA „Siemens Root CA" signiert. Alle Telefone ab einer bestimmten Version
enthalten dasselbe Standardzertifikat und denselben privaten Schlüssel. Darüber hinaus erhält das Telefon einen öffentlichen Schlüssel 2. Der öffentliche Schlüssel 2 wird
auf der Anwendungsschicht genutzt (Beschreibung weiter unten). Außerdem erhält
das Telefon einen öffentlichen Schlüssel 3 für die Identitätsprüfung der Software. Bei
Auslieferung wird die Software mit dem privaten Schlüssel 3 signiert. Diese Signatur
wird von der Software zur Laufzeit überprüft. Damit werden Manipulationen an der
Software ausgeschlossen (angegeben sind Software-Typ, Version und Lizenzbedingungen).
Lizenzierung: Wenn die Software eine Lizenz erfordert, überprüft das Telefon, ob der
Flash-Speicher ein Lizenztoken enthält. Dies kann nur der Fall sein, wenn der Befehl
zum Software-Download vom DLS stammte, der wiederum eine vertrauenswürdige Instanz für die Durchführung geeigneter Lizenzüberprüfungen durch den Customer Licensing Agent ist. Daher ist die Authentifizierung des DLS mithilfe des öffentlichen
Schlüssels 2 von so großer Bedeutung.
Startup: Das Telefon ist der TLS-Client für diese Verbindung. Beim Startup erkennt
das Telefon die Adresse des DLS und baut eine TLS-Verbindung zu dieser Adresse
auf. Diese Verbindung wird für die folgenden Schritte benötigt: Zertifikatsaustausch
und Signaturüberprüfung, zusätzliche Sicherheit auf Anwendungsschicht und Download sicherheitsrelevanter Daten auf das Telefon.
6. Juni 2008
2-1
c02.fm
Zertifikatsaustausch: Während des Aufbaus der TLS-Verbindung kommt es zur gegenseitigen TLS-Authentifizierung, wobei das Telefon sein Zertifikat an den DLS übermittelt und umgekehrt. Der DLS authentifiziert das Telefon, indem er das empfangene
Zertifikat verifiziert. Hierbei handelt es sich jedoch nur um eine „schwache" Authentifizierung, da das Telefon nur als Siemens-Telefon und nicht als spezifisches Gerät authentifiziert werden kann. Das Telefon kann das vom DLS empfangene Zertifikat möglicherweise nicht verifizieren, da es nicht unbedingt ein Zertifikat einer Stamm-CA
besitzt. Das Telefon kann beispielsweise über kein Zertifikat einer Stamm-CA zur Authentifizierung des DLS verfügen, wenn das DLS-Zertifikat von der Stamm-CA des
Kunden stammt. In diesem Fall kann das Telefon den DLS nicht authentifizieren. Die
Authentifizierung des DLS als echten Siemens-DLS (wie dies per öffentlichem Schlüssel 2 geschieht) ist jedoch wichtig, da das Telefon die erforderlichen Lizenzüberprüfungen zur Bereitstellung der neuen Software für das Telefon nur über einen vertrauenswürdigen DLS vornehmen kann.
Sicherheit auf Anwendungsschicht: Da das Telefon den DLS nicht auf der TLSSchicht authentifizieren kann, wird dies auf Anwendungsschicht ermöglicht. Hierzu
werden für eine bestimmte Telefon-Softwareversion jeweils ein privater Schlüssel 2
und ein zugehöriger öffentlicher Schlüssel 2 generiert. Der private Schlüssel 2 bleibt
geheim und ist in die DLS-Software eingebettet (zusammen mit anderen privaten
Schlüsseln 2 für andere Softwareversionen). Der öffentliche Schlüssel 2 wird an die
Telefonentwicklung weitergeleitet, wo er im letzten Produktionsstadium einer Baureihe
in die Telefonsoftware eingebettet wird, d. h., alle Telefone einer bestimmten Version
enthalten denselben öffentlichen Schlüssel 2, und alle DLS, die mit Telefonen dieser
Version kommunizieren, müssen den zugehörigen privaten Schlüssel 2 verwenden.
Nachdem das Telefon vom DLS auf TLS-Schicht als echtes Siemens-Telefon authentifiziert wurde, sendet das Telefon dem DLS eine Nachricht mit einer Nonce zur Verhinderung von Replay-Angriffen. Der DLS sendet dem Telefon eine Antwortnachricht,
die mit dem privaten Schlüssel 2 des DLS per XML-Signatur signiert ist. Diese Nachricht enthält auch die vom Telefon gesendete Nonce. Das Telefon kann nun die Signatur anhand des öffentlichen Schlüssels 2 überprüfen. Damit authentifiziert das Telefon
den DLS als echten Siemens-DLS.
Auf SIPSEC2 authentifiziert das Telefon den Server, auf dem der DLS auf der TLSSchicht ausgeführt wird, indem es beim ersten Mal ein in die Telefonsoftware integriertes Standard-CA-Zertifikat und später ein heruntergeladenes CA-Zertifikat verwendet.
Download sicherheitsrelevanter Daten auf das Telefon: Auf TLS-Schicht wurde
das Telefon vom DLS als echtes Siemens-Telefon, jedoch nicht als spezifisches Gerät
authentifiziert. Anhand der vom Telefon übermittelten MAC-Adresse erfährt der DLS,
mit was für einem Gerät er verbunden ist. Dabei wird einem echten Siemens-Telefon
vertraut, dass es seine korrekte MAC-Adresse übermittelt. Aufgrund dieser MACAdresse sendet der DLS einen privaten Ersatzschlüssel mit dem zugehörigen Ersatzzertifikat für zukünftige Kontakte mit dem DLS.
2-2
6. Juni 2008
c02.fm
Sobald der neue private Schlüssel und das Zertifikat für zukünftige DLS-Verbindungen
auf das Telefon heruntergeladen wurden, wird die TLS-Verbindung getrennt. Neue
TLS-Kanäle werden unter Verwendung der konfigurierten Sicherheitsparameter geöffnet und können gegenseitig authentifiziert geöffnet werden.
Hinweis: Sicherheitsüberprüfungen auf Anwendungsschicht bei DLS-Verbindungen
gelten nur für optiPoint-Geräte. optiClients authentifizieren den DLS nicht auf Anwendungsschicht, da sie keine Softwarelizenzen vom DLS erhalten.
2.
Benutzerbasierte Berechtigungsnachweise für Dienstzugang
Benutzerbasierte Berechtigungsnachweise werden für den Zugang zu Diensten benötigt. Hier wird meist ein dem Benutzer und dem Dienstanbieter bekanntes Geheimnis
zu Authentifizierungszwecken übermittelt. Protokolle, die dieses gegenseitig bekannte
Geheimnis verwenden, sind H.323 (H.235 Baseline-Sicherheitsprofil), CorNet (H.235ähnliche Sicherheit) und SIP (HTTP-Digestauthentifizierung). Die Berechtigungsnachweise werden üblicherweise per Außenband-Signalisierung übermittelt. Beachten Sie,
dass die Benutzer-Berechtigungsnachweise für den Dienstzugang dieselben sind (unabhängig vom verwendeten Dienstzugangsprotokoll).
3.
End-to-End-Schlüsselverwaltung
Die End-to-End-Schlüsselverwaltung in SIPSEC2 zielt auf die Bereitstellung aller für
einen End-to-End-Mediaschutz erforderlichen Parameter ab. Media- und Signalisierungsdaten können über verschiedene Pfade übermittelt werden; hierfür gibt es verschiedene Szenarien (Verbindungsaufbau über Server-geroutete Signalisierung,
DMC über direkt geroutete Signalisierung). Wie geplant, erfolgt die Schlüsselverwaltung mittels MIKEY. Informationen über MIKEY und dessen Anwendung in HiPath sind
in Abschnitt MIKEY enthalten.
Server-geroutete Signalisierung: Dies bezieht sich auf MIKEY-Option 0 (vgl. Anhang MIKEY-Schlüsselverwaltungsoptionen), mit der nicht nur der MIKEY-Container
abgesichert wird. Vielmehr wird die gesamte Nachricht mittels TLS-Verbindungen
nach dem Hop-to-Hop-Prinzip abgesichert. Verbindungen werden üblicherweise Server-geroutet hergestellt. Dieses Szenario kann auch mittels MIKEY-Option 3 gesichert
werden (vgl. Anhang Durch digitale Signaturen geschützte Diffie-Hellman-Schlüsselvereinbarung).
Direkt geroutete Signalisierung: Ein sitzungsbasierter Schlüssel wird aus der zentralen Infrastruktur generiert und als Teil der Server-gerouteten Verbindung an die
Kommunikationsteilnehmer übermittelt. Dieser Sitzungsschlüssel wird dann vom Anrufer und vom gerufenen Teilnehmer auf den MIKEY-Container mittels MIKEY-Option
1 (vgl. Anhang Symmetrische Schlüsselverteilung (Preshared-Keys)) angewendet.
Dieses Szenario kann auch mittels MIKEY-Option 3 gesichert werden (vgl. Anhang
Durch digitale Signaturen geschützte Diffie-Hellman-Schlüsselvereinbarung).
6. Juni 2008
2-3
c02.fm
2-4
6. Juni 2008
c03.fm
Technischer Anhang
TLS-Grundwissen
3
Technischer Anhang
3.1
TLS-Grundwissen
Die folgenden Informationen sind [[SIGSEC]] entnommen und mit aktualisierten Informationen und TLS-Erweiterungen (TLS-PSK und DTLS) ergänzt.
3.1.1
TLS - Übersicht
SMTP
HTTP
FTP
SIP
...
SSL/TLS
TCP
IP
Bild 3-1
SSL/TLS-Stack-Integration
TLS ist als anwendungsunabhängiges Sicherheitsprotokoll oberhalb eines verlässlichen
Transportprotokolls (z. B. TCP) und unterhalb von Internetanwendungen angesiedelt, die
Protokolle wie HTTP, SMTP usw. verwenden ( siehe SSL/TLS-Stack-Integration13). Das
TLS-Protokoll wurde von der IETF als (RFC 2246) standardisiert. Es basiert auf Version 3
des Protokolls SSL (Secure Socket Layer), das zur Absicherung von Protokollen wie z.B.
HTTPS dient. SSL ist eine weit verbreitete Sicherheitstechnologie für die sichere Übertragung von Daten über das Internet, die 1995 von Netscape initiiert wurde, um Webbrowsern
und anderen auf TCP beruhenden Anwendungen wie HTTP und FTP sichere Dienste zur
Verfügung zu stellen.
TLS bietet eine ähnliche Socket-API als Transportschicht, die eine transparente Nutzung
des Protokolls für Internetprotokoll-Stack und Anwendungen ermöglicht. Daher brauchen
Anwendungen, die TLS nicht erkennen, nicht geändert zu werden.
TLS bietet die folgenden Sicherheitsdienste:
●
verbindungsorientierte Datenvertraulichkeit
●
verbindungsorientierte Datenintegrität
●
sowohl unilaterale als auch gegenseitige Authentifizierung der TLS-Peers
Neben der Authentifizierung von Vertraulichkeit, Integrität und Datenherkunft bietet TLS
auch eine Schlüsselverwaltung. Das TLS-Protokoll arbeitet oberhalb der Transportschicht,
so dass zwischengeschaltete Firewalls die verschlüsselten Daten nicht interpretieren kön-
6. Juni 2008
3-1
c03.fm
Technischer Anhang
TLS-Grundwissen
nen. Da TLS ein sitzungsorientiertes Protokoll ist, richtet die TLS-Schlüsselverwaltung Sicherheitssitzungen ein, die die Sicherheitsparameter definieren, die für den Schutz der Anwendungsdaten der höheren Schicht angewendet werden.
TLS besteht außerdem aus mehreren Schichten, dem TLS Record Protocol und dem TLS
Handshake Protocol. Letzteres beinhaltet drei Unterprotokolle: Change Cipher Spec Protocol, Alert Protocol und Handshake Protocol. Das TLS Record Protocol verkapselt Protokolldaten höherer Ebenen. Es fragmentiert die Nachrichten des Protokolls der höheren
Ebene, komprimiert optional die Fragmente, hängt einen MAC (Message Authentication
Code) an, verschlüsselt die erweiterten Fragmente und leitet das Ergebnis an das verlässliche Transportprotokoll weiter. Das Handshake Protocol sorgt für die Authentifizierung der
TLS-Peers und die Schlüsselverwaltung für das TLS-Protokoll. Das Alert Protocol definiert
die vom Protokoll verwendeten Fehlermeldungen. Das Change Cipher Spec Protocol gibt
eine einzelne Nachricht an, die dem Kommunikations-Peer signalisiert, dass der Absender
seinen „Schreibstatus“ umgehend auf die neu ausgehandelte sichere Sitzung umschaltet.
Die Schlüsselverwaltung erfolgt für jede Sitzung separat.
Nachfolgend ist ein vollständiger TLS-Handshake dargestellt, der initiiert wird, wenn ein
Client eine Verbindung zu einem TLS-fähigen Server über den HTTPS-Port (üblicherweise
443) herstellt. Dieser Handshake erfolgt unabhängig davon, ob die Authentifizierung unilateral oder gegenseitig vorgenommen wurde.
Client
Server
ClientHello
à
ß
Certificate*
ClientKeyExchange
CertificateVerify*
ChangeCipherSpec
Finished
ServerHello
Certificate*
CertificateRequest*
ServerKeyExchange*
ServerHelloDone
à
ß
ChangeCipherSpec
Finished
Erklärung:
* verweist auf optionale Nachrichten
Tabelle 3-1
3-2
Nachrichtenfluss bei einem vollständigen TLS-Handshake
6. Juni 2008
c03.fm
Technischer Anhang
TLS-Grundwissen
Der generelle Zweck des Schlüsselaustauschs ist die Festlegung eines beiden Kommunikationsteilnehmern bekannten „Pre-Master-Secret“. Dieses Pre-Master-Secret dient zur
Generierung des Master-Secret. Ebenfalls erforderlich für diese Generierung sind die in
den ClientHello- bzw. ServerHello-Nachrichten ausgetauschten Zufallszahlen von Client
und Server. Die Länge des Master-Secret beträgt immer 48 Byte. Das Master-Secret wird
zur Generierung der Nachrichten „Certificate Verify“ und „Finish“, der Verschlüsselungsschlüssel und der MAC-Geheimnisse benötigt. Mit dem Senden einer korrekt beendeten
Nachricht beweisen die Teilnehmer einander, dass sie das richtige Pre-Master-Secret kennen.
Das Master-Secret kann für eine Wiederaufnahme der Sitzung gespeichert werden. In diesem Fall wird das Master-Secret wiederverwendet, ohne dass der oben dargestellte
Handshake ausgeführt werden muss. Dieses Verfahren gilt für dieselbe Sicherheitszuordnung. Die Wiederaufnahme einer Sitzung ist auch möglich, wenn mehrere Kanäle zwischen zwei Systemen geöffnet werden sollen, die derselben Sicherheitszuordnung vertrauen. Je nach geltenden Richtlinien kann eine zwischen zwei Servern beendete Sitzung
nach bis zu 24 Stunden wiederaufgenommen werden. Die Wiederaufnahme einer Sitzung
ist allerdings nur möglich, wenn dies vom TLS-Client initiiert wird.
Es ist auch möglich, eine erneute Aushandlung („Renegotiation“) zu initiieren. Die erneute
Aushandlung zwischen zwei Servern führt zu einem vollständigen TLS-Handshake, bei
dem alle zur Sitzung gehörigen Sicherheitsparameter erneuert werden. Auch dies ist von
den geltenden Richtlinien abhängig.
In (RFC 2246) bis werden mehrere Schlüsselaustausch-Algorithmen vorgeschlagen, z. B.
RSA, DSS, authentifizierter Diffie-Hellman-Austausch. Im Allgemeinen werden X.509v3Zertifikate verwendet. Es ist auch möglich, andere Schlüsselaustauschmethoden für TLS
festzulegen.
Sitzungsschlüssel werden aufgrund des in In TLS definierte Schlüsselgenerierung21 beschriebenen Master-Secret generiert.
Benutzer B
Benutzer A
Festlegung des Sitzungsschlüssels mittels Master-Secret zwischen A und B (TLS)
TLS generiert einen Schlüssel anhand des Master-Secret. Dies geschieht durch
P_hash(secret, seed) = HMAC_hash(secret, A(1) + A(0) +
HMAC_hash(secret, A(2) + A(0) +
HMAC_hash(secret, A(3) + A(0)) + ...
wobei + eine Verkettung bedeutet. Dies findet in jedem der beteiligten Endsysteme
statt.
6. Juni 2008
3-3
c03.fm
Technischer Anhang
TLS-Grundwissen
Benutzer A
Benutzer B
Erklärung:
P_hash()
Datenerweiterungsfunktion
HMAC_hash()keyed MAC, Verwendung mit Hash-Algorithmen MD5 und SHA-1
A(0)
seed
A(I)
HMAC_hash(secret, A(I-1)
Tabelle 3-2
In TLS definierte Schlüsselgenerierung
Darüber hinaus definiert RFC 2246 eine obligatorische Cipher-Suite,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, nämlich:
●
Schlüsselaustausch mit Ephemeral-Diffie-Hellman, wobei die Parameter mit DSS signiert werden
●
Verschlüsselung/Entschlüsselung mit 3DES-EDE-CBC
●
Hashing mit SHA-1
TLS kann in verschiedenen Modi genutzt werden, wobei unterschiedliche Voraussetzungen gegeben sein müssen:
●
●
●
●
3-4
Anonymer Modus: schafft eine verschlüsselte Verbindung zwischen zwei kommunizierenden, nicht authentifizierten Instanzen.
Server-Authentifizierungsmodus (unilateral): schafft eine verschlüsselte Verbindung zwischen zwei kommunizierenden Instanzen, wobei sich der TLS-Server gegenüber dem TLS-Client authentifiziert. Als Vorbedingung muss der Server ein Zertifikat
mit zugehörigem privaten Schlüssel und der Client das Stammzertifikat der CA besitzen, die das Zertifikat des Servers ausgestellt hat.
Gegenseitiger Authentifizierungsmodus: schafft eine verschlüsselte Verbindung
zwischen zwei kommunizierenden Instanzen, wobei sich der TLS-Server gegenüber
dem TLS-Client authentifiziert und umgekehrt. Als Vorbedingung muss sowohl der
Server als auch der Client ein Zertifikat mit zugehörigem privaten Schlüssel sowie das
Stammzertifikat der CA besitzen, die die Zertifikate ausgestellt hat.
Kerberized TLS: (RFC 2712) erweitert die TLS-Cipher-Suite für Kerberos. Um eine
Verbindung zu einer Serverkomponente anfordern zu können, muss ein TLS-Client
dem Server ein Kerberos-Ticket über das erweiterte TLS-Handshake-Protokoll senden. Der Client muss dann den Sitzungsschlüssel und das Ticket beim Kerberos KDC
abrufen. Kerberized TLS muss sowohl vom Client als auch vom Server unterstützt
werden, damit es genutzt werden kann. Beachten Sie, dass das KDC als erforderliche
Komponente in HiPath-Szenarien unterstützt werden müsste.
6. Juni 2008
c03.fm
Technischer Anhang
TLS-Grundwissen
3.1.2
Anonyme TLS
LAN
Client A
Server B
Client Hello
Server Hello
ServerKeyExchange
Server Hello Done
Client Key Exchange
Change Cipher Spec
Finished
Change Cipher Spec
Finished
Bild 3-2
INVITE
407 Uauthorized
INVITE
200 OK
HTTP Digest
Authentication
PROTECTED with Key A
Session Key A established
…
…
TLS mit anonymem Diffie-Hellman-Schlüsselaustausch, HTTP-Digestauthentifizierung
und geschützter SIP-Kommunikation
TLS kann auch ganz ohne Authentifizierung genutzt werden. Dies geschieht, wenn keiner
der Peers asymmetrisches Schlüsselmaterial besitzt oder wenn nur eine Verschlüsselung
des Datenstroms, aber keine Authentifizierung benötigt wird. Beachten Sie, dass bei Verwendung anonymer TLS-Handshakes aufgrund der fehlenden Authentifizierung Man-inthe-Middle-Angriffe möglich sind.
Zum Aufbau anonymer Sitzungen sind zwei Optionen verfügbar:
●
Anonymes RSA-Verfahren: Der Client verschlüsselt anhand des aus der ServerSchlüsselaustauschnachricht extrahierten unzertifizierten öffentlichen Schlüssels des
Servers ein Pre-Master-Secret. Das Ergebnis wird in einer Client-Schlüsselaustauschnachricht gesendet.
6. Juni 2008
3-5
c03.fm
Technischer Anhang
TLS-Grundwissen
●
Anonymer Diffie-Hellman-Schlüsselaustausch: Die öffentlichen Parameter des
Servers sind in der Server-Schlüsselaustauschnachricht enthalten, und die des Clients werden in der Client-Schlüsselaustauschnachricht gesendet.
Der vollständige Nachrichtenfluss bis zur geschützten Kommunikation ist in TLS mit anonymem Diffie-Hellman-Schlüsselaustausch, HTTP-Digestauthentifizierung und geschützter SIP-Kommunikation14 dargestellt; dabei dient SIP als Beispiel für das verwendete
Kommunikationsprotokoll:
3.1.3
Unilateral authentifiziertes TLS
TLS kann mit unilateraler, als Teil des TLS-Handshakes durchgeführter Authentifizierung
verwendet werden. Dies geschieht beispielsweise, wenn nur der (TLS-) Server über ein
Zertifikat und den zugehörigen privaten Schlüssel verfügt. Der Client benötigt auch Zugang zu dem entsprechenden Stammzertifikat, um das Serverzertifikat verifizieren zu können. Der Client kann sich oberhalb der TLS-Verbindung gegenüber dem Server authentifizieren und dabei zusätzliche Methoden nutzen, z.B. in SIP die HTTPDigestauthentifizierung.
Die im vorigen Abschnitt enthaltenen Angaben zur Leistung bei gegenseitig authentifizierten TLS-Verbindungen gelten bis zu einem bestimmten Grad auch für unilateral authentifizierte TLS-Verbindungen. Hier generiert nur der (TLS-) Server eine digital Signatur, und
nur der Client verifiziert die Signatur.
Der vollständige Nachrichtenfluss bis zur geschützten Kommunikation kann über TLS mit
unilateraler Authentifizierung erfolgen (siehe TLS mit unilateraler Authentifizierung, HTTPDigestauthentifizierung und geschützter SIP-Kommunikation); dabei dient SIP als Beispiel
für das verwendete Kommunikationsprotokoll:
3-6
6. Juni 2008
c03.fm
Technischer Anhang
TLS-Grundwissen
LAN
Client A
Server B
Client Hello
Server Hello
Certificate
Server Hello Done
Client Key Exchange
Change Cipher Spec
Finished
Change Cipher Spec
Finished
Bild 3-3
INVITE
407 Uauthorized
INVITE
200 OK
HTTP Digest
A th ti ti
PROTECTED with Key A
…
…
TLS mit unilateraler Authentifizierung, HTTP-Digestauthentifizierung
und geschützter SIP-Kommunikation
Für die Serverseite sind dieselben Systeminteraktionen erforderlich, wie bereits im vorigen
Kapitel beschrieben. Hier kann auch das in TLS-Sitzungswiederaufnahme vorgestellte
Konzept der Sitzungswiederaufnahme angewendet werden.
Beachten Sie, dass der SIP UA im hier dargestellten SIP-Szenario TLS-Verbindungen zum
Server, der Server jedoch nicht unbedingt TLS-Verbindungen mit unilateraler oder gegenseitiger Authentifizierung zum SIP UA öffnen kann. Das ist darin begründet, dass der SIP
UA als Server für die TLS-Verbindung agieren würde, möglicherweise aber ohne Zertifikat,
das für die Authentifizierung nötig wäre. Dies ist vor allem wichtig, wenn der SIP UA einen
Anruf empfängt, nachdem zuvor die Verbindung zum Server getrennt wurde. In diesem Fall
kann der Server TLS mit anonymen Cipher-Suites verwenden, damit zumindest die Vertraulichkeit der Signalisierungsnachrichten gewährleistet ist. Die Authentifizierung kann
oberhalb von TLS mittels HTTP-Digestauthentifizierung als Teil der SIP-Nachricht erfolgen.
6. Juni 2008
3-7
c03.fm
Technischer Anhang
TLS-Grundwissen
3.1.4
Gegenseitig authentifiziertes TLS
TLS gestattet gegenseitige Authentifizierung als Teil des TLS-Handshakes. Das ist allerdings nur möglich, wenn beide Seiten ein Zertifikat, den zugehörigen privaten Schlüssel
und das entsprechende Stammzertifikat besitzen. Nach dem in TLS mit gegenseitiger Authentifizierung und geschützter SIP-Kommunikation dargestellten Handshake werden beide Seiten authentifiziert, und die Integrität und Vertraulichkeit des darauffolgenden Datentransfers können entsprechend den ausgehandelten Algorithmen geschützt werden. Der
ausgehandelte Schutz gilt für jedes über die mit TLS abgesicherte Verbindung gesendete
Paket.
Was die Leistung anbelangt, so stellt der TLS-Handshake die höchste Belastung für das
System dar, da in diesem Schritt auf beiden Seiten alle asymmetrischen kryptografischen
Vorgänge ausgeführt werden. Jeder der beteiligten Server muss eine an den anderen Teilnehmer zu sendende digitale Signatur generieren und außerdem eine empfangene digitale Signatur verifizieren.
Es sind bereits Software-Bibliotheken verfügbar, die kryptografische Algorithmen mit hoher
Leistung unterstützen. TLS-Softwarelösungen wie IPL (von ICN EN SEC) unterstützen bereits eine so leistungsfähige kryptografische Bibliothek.
Der vollständige Nachrichtenfluss bei einem Verbindungsaufbau mit SIP als Beispiel-Anwendungsprotokoll und einer Absicherung über TLS mit gegenseitiger Authentifizierung ist
in TLS mit gegenseitiger Authentifizierung und geschützter SIP-Kommunikation dargestellt:
3-8
6. Juni 2008
c03.fm
Technischer Anhang
TLS-Grundwissen
LAN
Peer A
Peer B
Client Hello
Server Hello
Certificate
Certificate Request
Server Hello Done
Certificate
Client Key Exchange
Certificate Verify
Change Cipher Spec
Finished
Change Cipher Spec
Finished
PROTECTED
with Key A
Bild 3-4
3.1.5
Request
Response
…
…
TLS mit gegenseitiger Authentifizierung und geschützter SIP-Kommunikation
TLS-Sitzungswiederaufnahme
Der vollständige TLS-Handshake findet bei der erstmaligen Kommunikation zwischen zwei
Peers statt. Sobald auf beiden Seiten ein TLS-Sitzungskontext hergestellt ist, kann die Sitzung, wie in Abschnitt TLS - Übersicht beschrieben, wiederaufgenommen werden. Das erspart die Durchführung der aufwendigen asymmetrischen kryptografischen Vorgänge bei
gleichzeitiger Absicherung durch das Master-Secret. Mittels Sitzungswiederaufnahme lassen sich auch bestehende Sitzungen duplizieren. D. h., der Client kann eine Sitzung an einem anderen Port als dem ursprünglich für die erste Verbindung verwendeten Port wiederaufnehmen. Je nach geltenden Richtlinien kann der Server diese Verbindungsanforderung
akzeptieren. Darüber hinaus ist auch je nach Speicherungsstrategie von Client- und Serversitzungen eine Sitzungswiederaufnahme bei einem anderen Host möglich, vorausgesetzt, die Hosts sind sicher miteinander verbunden und einander zugeordnet und haben
auf denselben Sitzungsspeicher Zugriff. Das ist möglich, weil beim TLS-Handshake wäh6. Juni 2008
3-9
c03.fm
Technischer Anhang
TLS-Grundwissen
rend der Sitzungswiederaufnahme kein Zertifikatsaustausch erfolgt. Somit kann der TLSClient, sofern seine Richtlinien die Wiederaufnahme bei einem anderen Host gestatten,
eine Verbindung zu einem anderen Host öffnen. Die letztere Variante (Verbindung zu anderen Hosts) ist im Standard nicht eigens beschrieben und ist eher eine Sache der Implementierung.
Hierbei sendet der Client eine ClientHello-Nachricht unter der Sitzungs-ID einer bereits bestehenden Sitzung. Daraufhin durchsucht der Server seinen Sitzungsspeicher nach einer
Entsprechung. Findet der Server einen Treffer, und lassen seine Richtlinien eine Sitzungswiederaufnahme zu, antwortet er mit derselben Sitzungs-ID. Andernfalls wird durch Übermittlung einer neuen Sitzungs-ID eine neue Sitzung aufgebaut. Im ersteren Fall kommt es
zu einem reduzierten Handshake. Der weiter oben dargestellte Handshake würde dann
folgendermaßen abgewandelt:
LAN
Peer A
Peer B
PROTECTED
with Key A
Request
Response
…
…
Session paused
Client Hello
PROTECTED
with Key A
Server Hello
Change Cipher Spec
Finished
Change Cipher Spec
Finished
PROTECTED
with Key B
Session Key B established
Bild 3-5
3-10
Request
Response
…
…
TLS-Sitzungswiederaufnahme und geschützte Kommunikation
6. Juni 2008
c03.fm
Technischer Anhang
TLS-Grundwissen
Beachten Sie, dass nur dem Client der TLS-Verbindung (Peer A in der obigen Abbildung)
eine Sitzungswiederaufnahme möglich ist. Wird die TLS-Verbindung zwischen den Peers
beendet, kann Peer B Peer A mit einer Hello Request-Nachricht zum Öffnen einer TLSVerbindung zwingen. Peer A wäre dann zu einer Sitzungswiederaufnahme fähig.
Des Weiteren bietet TLS Funktionen zur erneuten Aushandlung („Renegotiation“), die
nach einer bestimmten Zeit zur Aktualisierung aller Parameter in Bezug auf die Sitzungssicherheit genutzt werden sollten. In diesem Fall kommt es zu einem vollständigen Handshake.
Eine Lösung, die weniger Ressourcen mit Handshakes verbraucht, lässt die TLS-Verbindung zwischen den Servern offen bzw. führt nach dem Trennen einer Verbindung eine Sitzungswiederaufnahme durch.
Wie bereits erwähnt, müssen auf den beteiligten Systemen ein Zertifikat mit zugehörigem
privaten Schlüssel vorhanden sein. Diese Informationen sind üblicherweise zugriffsgeschützt, z. B. durch ein Passwort.
3.1.6
Erweiterte TLS-Sitzungswiederaufnahme: Umgehen des serverseitigen Zustands
Um eine Sitzung wiederaufnehmen zu können, muss der TLS-Server den Sitzungszustand, d.h. die ausgehandelten Sicherheitsparameter beibehalten. Dies bedeutet eine Belastung des Servers, insbesondere dann, wenn eine große Anzahl von Clients zu unterstützen ist. Diese Einschränkung wird im Entwurf (DTLSST) mit der Beschreibung eines
Mechanismus aufgegriffen, der es dem TLS-Server ermöglicht, Sitzungen wiederaufzunehmen, ohne den Sitzungszustand pro Client beibehalten zu müssen. Hierzu verkapselt
der TLS-Server den Sitzungszustand in einem Ticket, das er an den Client weiterleitet. Mit
dem empfangenen Ticket kann der Client dann eine Sitzung wiederaufnehmen.
Um die Unterstützung dieses Mechanismus zu signalisieren, fügt der Client der ClientHello-Nachricht die TLS-Erweiterung SessionTicket hinzu. Der Server speichert seinen Sitzungszustand (z.B. Cipher-Suite und Master-Secret) in einem Ticket, für dessen Verschlüsselung und Integritätsschutz ein nur dem Server bekannter Schlüssel verwendet
wird. Der Vorgang ist in der folgenden Abbildung dargestellt.
6. Juni 2008
3-11
c03.fm
Technischer Anhang
TLS-Grundwissen
LAN
Peer A
Peer B
Client Hello
(empty
SessionTicket ext.)
Server Hello
Certificate
Server Hello Done
Client Key Exchange
Change Cipher Spec
Finished
SessionTicket
Change Cipher Spec
Finished
PROTECTED
with Key A
Request
Response
…
…
PROTECTED
with Key A
Session paused
Client Hello
(SessionTicket ext.)
Server Hello
SessionTicket
Change Cipher Spec
Finished
Change Cipher Spec
Finished
PROTECTED
with Key B
Session Key B established
Bild 3-6
3-12
Request
Response
…
…
TLS-Sitzungswiederaufnahme mit Sitzungstickets
6. Juni 2008
c03.fm
Technischer Anhang
TLS-Grundwissen
3.1.7
Erweiterte TLS-Schlüsselverwaltung: TLS-PSK
Für mobile Szenarien sind die Authentifizierungsoptionen von TLS möglicherweise unzureichend. Eine serverseitige Authentifizierung ist nicht immer möglich, da dies voraussetzt,
dass Clients das Serverzertifikat verifizieren können, also das Zertifikat des entsprechenden Ausstellers besitzen bzw. darauf zugreifen können. Andererseits gilt anonymes TLS
als nicht sicher genug für diese Art von Verbindungen. Daher wurde ein neuer Vorschlag
für die Nutzung von Preshared-Keys in TLS erarbeitet. Dieses Konzept ähnelt der in Abschnitt TLS-Sitzungswiederaufnahme beschriebenen Sitzungswiederaufnahme, kann
aber sowohl von der Client- als auch von der Serverseite initiiert werden. Der Lösungsansatz ist in (DTLSPSK) beschrieben. TLS-Preshared-Key (TLS-PSK) bietet mehrere neue
Cipher-Suites und unterstützt auch eine zusätzliche Authentifizierung auf Zertifikatsbasis.
LAN
Peer A
Peer B
Client Hello
Server Hello
ServerKeyExchange*
Server Hello Done
Client Key Exchange
Change Cipher Spec
Finished
Change Cipher Spec
Finished
PROTECTED
with Key A
Bild 3-7
Request
Response
…
…
Lösungsansatz TLS-PSK
TLS-PSK wird folgendermaßen verwendet: Der Client zeigt seine Bereitschaft zur PSKAuthentifizierung an, indem er eine oder mehrere PSK-Cipher-Suites in die ClientHelloNachricht einfügt. Wenn der TLS-Server ebenfalls Preshared-Keys verwenden möchte,
wählt er eine der PSK-Cipher-Suites aus, platziert sie in die ServerHello-Nachricht ein, und
fügt (...) Da sowohl Clients als auch Server Preshared-Keys für mehrere verschiedene Teilnehmer haben können, gibt der Client mit einer „PSK Identity“ in der ClientKeyExchangeNachricht an, welcher Schlüssel zu verwenden ist. Um den Client bei der Auswahl der
6. Juni 2008
3-13
c03.fm
Technischer Anhang
TLS-Grundwissen
Identität zu unterstützen, kann der Server als Hinweis einen „PSK Identity Hint“ in der ServerKeyExchange-Nachricht übermitteln. Ohne einen solchen Hinweis wird die ServerKeyExchange-Nachricht übergangen.
3.1.8
TLS-Handshake - Übersicht
In diesem Abschnitt ist kurz umrissen, welcher Aufwand je nach verwendeter Authentifizierungsmethode erforderlich ist, um eine TLS-Verbindung herzustellen. Optimierungen wie
Sitzungswiederaufnahme sind ebenfalls berücksichtigt. Das Gruppieren von Nachrichten
ist in TLS-Handshake - Übersicht22 nicht berücksichtigt.
Authentifizierungsmodus
anonym
unilateral
gegenseitig
PSK
Tabelle 3-3
3.1.9
Nachrichten für vollständigen Handshake
9
9
12
9
Nachrichten für Sitzungswiederaufnahme
6
6
6
6
TLS-Handshake - Übersicht
Datagramm-TLS – Übersicht
Der IETF liegt ein neuer Entwurf (DDTLS) vor, der eine Verwendung des TLS-Konzepts
auch für UDP-Verbindungen vorsieht. TLS wurde ursprünglich für den verlässlichen Transport von TLS-ähnlichen Diensten geplant, die auch für UDP von Interesse sein könnten.
DTLS sieht im Prinzip denselben Handshake vor wie TLS. Die Nachrichten werden in
DTLS-Datensätzen gesendet, die so erweitert sind, dass ein verlässlicher Handshake über
die UDP-Verbindung gewährleistet ist. Bei den Erweiterungen handelt es sich um eigene
Sitzungstimer für Neuübertragung, Fragmentation Handling und Laufnummerierung (zur
Neuanordnung). Auf der Datensatzebene werden die einzelnen Datensätze mit Laufnummern (als Zustandsinformation) versehen.
Da DTLS DoS-Angriffen ausgesetzt ist, wurde es mit einer von Photuris und IKE verwendeten Technik der zustandslosen Cookies (Stateless Cookies) erweitert. Auf das Senden
der ClientHello-Nachricht kann der Server mit einer HelloVerifyRequest-Nachricht reagieren, die ein zustandsloses Cookie enthält. Daraufhin muss der Client die ClientHello-Nachricht, die das Cookie enthält, neu übertragen, damit der Server das Cookie verifizieren
kann. Dieses Verfahren schützt vor DoS-Angriffen mit gefälschten IP-Adressen (siehe
DTLS mit gegenseitiger Authentifizierung und geschützter UDP-Kommunikation, rote Markierung).
3-14
6. Juni 2008
c03.fm
Technischer Anhang
MIKEY-Schlüsselverwaltungsoptionen
LAN
Peer A
Peer B
Client Hello
HelloVerifyRequest
with cookie
Client Hello
with cookie
Server Hello
Certificate
Certificate Request
Server Hello Done
Certificate
Client Key Exchange
Certificate Verify
Change Cipher Spec
Finished
Change Cipher Spec
Finished
PROTECTED
with Key A
Bild 3-8
3.2
Request
Response
…
…
DTLS mit gegenseitiger Authentifizierung und geschützter UDP-Kommunikation
MIKEY ( RFC 3830) definiert drei Optionen für die Benutzerauthentifizierung und Aushandlung der Master-Keys als Zweiwege-Handshakes, nämlich:
●
Ungeschützte Schlüsselverteilung
●
Symmetrische Schlüsselverteilung (Preshared-Keys, MAC für den Integritätsschutz)
●
Asymmetrische Schlüsselverteilung (aufgrund asymmetrischer Verschlüsselung)
●
Durch digitale Signaturen geschützte Diffie-Hellman-Schlüsselvereinbarung
6. Juni 2008
3-15
c03.fm
Technischer Anhang
●
Es gibt noch zwei weitere Varianten, die aber nicht in ( RFC 3830)) enthalten sind.
●
Durch symmetrische Preshared-Keys geschützte Diffie-Hellman-Schlüsselvereinbarung (DMKEXT1)
●
Asymmetrische Schlüsselverteilung (aufgrund asymmetrischer Verschlüsselung)
mit Zertifikatsübermittlung per Innenband-Signalisierung (DMKEXT2)
Die standardmäßige und obligatorische Schlüsseltransport-Verschlüsselung ist AES im
Zählermodus, wobei MIKEY auf ( RFC 3711)) Bezug nimmt. MIKEY nutzt ein 160-Bit-Authentifizierungstag, das von HMAC mit SHA-1 als obligatorischer Algorithmus gemäß (
RFC 2104)) generiert wird. Ebenso obligatorisch ist bei der Verwendung asymmetrischer
Mechanismen die Unterstützung von X.509v3-Zertifkaten für die Verschlüsselung mit öffentlichem Schlüssel und für digitale Signaturen.
3.2.1
Symmetrische Schlüsselverteilung (Preshared-Keys)
Client A - Initiator
Initialization:
Rand, TGK, KEK := Random()
encr-key, auth-key := PRF(pre-shared-secret,…|| Rand)
Protocol execution:
K := [IDA] || [IDB] || T || Rand || Eencr-key(TGKs [|| KEK]) || {SP}
A := HMAC-SHA1(auth-key, K)
Client B - Responder
K, A
Retrieve TGK, KEK from K
auth-key := PRF(pre-shared-secret, …
V := HMAC-SHA1(auth-key, IDA || IDB
[V]
Bild 3-9
MIKEY - Preshared-Key-Verteilung
Diese Option der Schlüsselverwaltung nutzt einen Preshared-Secret-Schlüssel, um daraus Schlüsselmaterial für den Integritätsschutz und die Verschlüsselung zum Absicherung
des tatsächlichen Austauschs des Schlüsselmaterials abzuleiten. Die Antwortnachricht ist
optional und kann zur gegenseitigen Authentifizierung verwendet werden.
Die Vorteile dieses Ansatzes liegen in der Unabhängigkeit von einer PKI; darüber hinaus
beansprucht die Lösung wenig Bandbreite bei hoher Leistung und stellt alles in allem eine
einfache und direkte Art der Master-Key-Übermittlung dar. Nachteilig ist, dass keine voll-
3-16
6. Juni 2008
c03.fm
Technischer Anhang
ständige Vorwärtsgeheimhaltung gewährleistet ist, und die Schlüsselgenerierung nur
durch den Initiator erfolgt. Außerdem lässt sich die Lösung nicht auf größere Konfigurationen skalieren, sondern ist nur für kleinere Gruppen geeignet.
Beachten Sie, dass die Implementierung dieser Option nach ( RFC 3830) obligatorisch ist.
3.2.2
Asymmetrische Schlüsselverteilung
Client A – Initiator
Client B - Respond
Initialization:
encr-key, auth-key := PRF(env-key,…|| Rand)
Protocol execution:
O := Eencr-key(IDA || TGKs || [KEK])
P := HMAC-SHA1(auth-key, O)
K := EPK-B(env-key), O, P, T, Rand, [(IDA || CertA)], [H(CertB)] || {SP}
S := SignSK-A(H(K))
K, S
Retrieve TGK, KEK from K
auth-key := PRF(env-key,…|| Ran
V := HMAC-SHA1(auth-key, IDA ||
[V]
Bild 3-10
1.1.1 Symmetric key-distributi
MIKEY - RSA-basierte Schlüsselverteilung
Bei der asymmetrischen Variante der Schlüsselverteilung generiert der Initiator das zu
übermittelnde Schlüsselmaterial und sendet es verschlüsselt mit dem öffentlichen Schlüssel des Antwortenden. Zusätzlich wird ein mit dem öffentlichen Schlüssel des Empfängers
verschlüsselter so genannter Envelope-Key übermittelt. Der Envelope-Key env-key dient
zur Ableitung der Schlüssel auth-key und enc-key. Darüber hinaus kann der Envelope-Key
als Preshared-Key zum Aufbau weiterer Crypto-Sitzungen genutzt werden. Die Antwortnachricht ist optional und kann zur gegenseitigen Authentifizierung verwendet werden.
Vorteilhaft an dieser Lösung ist, dass die Nutzung selbstsignierter Zertifikate eine PKI
überflüssig machen kann, allerdings zum Preis einer begrenzten Skalierbarkeit und hohem
Bereitstellungsaufwand. Nachteilig ist, dass für eine volle Skalierbarkeit eine PKI benötigt
wird, die Schlüsselgenerierung nur durch den Initiator erfolgt und keine vollständige Vorwärtsgeheimhaltung gegeben ist. Darüber hinaus ist die Verifizierung von Zertifikaten unter Umständen nicht in Echtzeit möglich.
Beachten Sie, dass die Implementierung dieser Option nach ( RFC 3830) obligatorisch ist.
6. Juni 2008
3-17
c03.fm
Technischer Anhang
3.2.3
Durch digitale Signaturen geschützte Diffie-Hellman-Schlüsselvereinbarung
Client B - Responde
Initialization:
Rand, x := Random()
Protocol execution:
K := gx, T, Rand, [(IDA || CertA)] || {SP}
S := SignSK-A(H(K))
Initialization:
y := Random()
K, S
K‘, S‘
TGK := gxy mod p
K‘ := gy, T, Rand, IDA, gx, [(ID
S‘ := SignSK-A(H(K‘))
TGK := gxy mod p
Bild 23: MIKEY - Diffie-Hellman-Schlüsselvereinbarung (signiert)
Die Diffie-Hellman-Option der Schlüsselverwaltung ermöglicht das Festlegen eines gegenseitig bekannten Geheimnisses zwischen Initiator und Antwortendem in einer Weise, bei
der beide Teilnehmer zu dem gegenseitig bekannten Geheimnis beitragen. Der Integritätsschutz bei der Diffie-Hellman-Vereinbarung wird durch digitale Signaturen gewährleistet.
( RFC 3830) schreibt keine spezifischen asymmetrischen Algorithmen für die Signaturberechnung vor. Welcher Algorithmus zur Verschlüsselung von Signaturen oder öffentlichen
Schlüsseln genutzt wird, wird definiert und ist abhängig vom verwendeten Zertifikat. Außer
der Verwendung von X.509v3-Zertifikaten ist die Unterstützung der Diffie-Hellmann-Gruppe „OAKLEY5“ ( RFC 2412) obligatorisch.
Die Vorteile dieses Ansatzes sind die faire, gegenseitige Schlüsselvereinbarung, die vollständige Vorwärtsgeheimhaltung und die Möglichkeit, mit der Nutzung selbstsignierter
Zertifikate auf eine PKI zu verzichten (allerdings zum Preis einer begrenzten Skalierbarkeit
und eines hohen Bereitstellungsaufwands).
Negativ anzumerken ist, dass diese Lösung nur für Point-to-Point-Gruppen ausreicht und
PKI für eine volle Skalierbarkeit unerlässlich ist. Darüber hinaus ist die Leistung begrenzt,
da eine kostspielige Nicht-Echtzeit-Validierung des Zertifikats erforderlich ist.
3-18
6. Juni 2008
c03.fm
Technischer Anhang
Client A - Initiator
Initialization:
Protocol execution:
K := [IDA] || [IDB] || T || Rand || TGKs [|| KEK] || {SP}
Client B - Responder
K
Bild 3-11
3.2.4
Retrieve TGK, KEK from
MIKEY - ungeschützte Schlüsselverteilung
Ungeschützte Schlüsselverteilung (nur mit Vorsicht anzuwenden)
MIKEY unterstützt auch einen Modus zur ungeschützten Schlüsselverteilung. Dieser beruht auf der in Anhang Symmetrische Schlüsselverteilung (Preshared-Keys) beschriebenen Preshared-Key-Option und ist vergleichbar mit der einfachen Vorgehensweise in sDecriptions (vgl. [DSDES]). Er verlässt sich völlig auf die zugrunde liegende Sicherheit und
kann mit den Algorithmen NULL-Verschlüsselung und NULL-Authentifizierung angewendet werden.
Diese Option sollte mit Vorsicht genutzt werden, da sie die Schlüsselverwaltung ungeschützt lässt.
6. Juni 2008
3-19
c03.fm
Technischer Anhang
3.2.5
MIKEY-Erweiterung: Durch Preshared-Secrets geschützte DiffieHellman-Schlüsselvereinbarung
Initialization:
Rand := Random()
auth-key := PRF(pre-shared-secret,…|| Rand)
Protocol execution:
K := gx, T, Rand, [IDA], IDB, {SP}
A := HMAC-SHA1(auth-key, K)
Client B - Responde
K, A
K‘, A‘
TGK := gxy mod p
Bild 3-12
K‘ := gy, T, [IDB], IDA, gx
A’ := HMAC-SHA1(auth-key,
TGK := gxy mod p
MIKEY - Diffie-Hellman-Schlüsselvereinbarung (HMAC-geschützt)
Dies ist eine weitere Option eines Schlüsselverwaltungsschemas und nicht im ursprünglichen MIKEY-Dokument enthalten. Im Dokument [DMKEXT1] ist diese Funktionalität als Erweiterung zu MIKEY beschrieben. Im Gegensatz zu der in Abschnitt Durch digitale Signaturen geschützte Diffie-Hellman-Schlüsselvereinbarung beschriebenen Methode erfolgt
der Integritätsschutz der Diffie-Hellmann-Schlüsselvereinbarung mittels Preshared-Secret
und Keyed-Hash-Funktion.
Für den Integritätsschutz der Diffie-Hellmann-Schlüsselvereinbarung schreibt [DMKEXT1]
die Verwendung von HMAC SHA-1 vor. Bezüglich Diffie-Hellman-Gruppen wird auf
( RFC 3830) Bezug genommen. Somit ist die Unterstützung der Diffie-Hellman-Gruppe
„OAKLEY5“ ( RFC 2412) obligatorisch.
Diese Option bietet auch mehrere Vorteile, z.B. die faire gegenseitige Schlüsselvereinbarung, die vollständige Vorwärtsgeheimhaltung sowie die Unabhängigkeit von einer PKI und
von PKI-Standards. Darüber hinaus bietet diese Lösung eine gute Leistung bei geringem
Bandbreitenbedarf und gestattet eine einfache und direkte Master-Key-Übermittlung. Die
Skalierbarkeit dieses Konzepts lediglich auf Point-to-Point-Gruppen ist ein Nachteil.
3-20
6. Juni 2008
c03.fm
Technischer Anhang
3.2.6
MIKEY-Erweiterung: Asymmetrische Schlüsselverteilung mit
Zertifikatsaustausch per Innenband-Signalisierung
Client B - Respond
Protocol execution:
I := T , [(IDB], CertA, [SP]
S := SignSK-A(H(I))
I, S
Initialization:
encr-key, auth-key := PRF(env-key,…|| Rand)
Protocol execution:
O := Eencr-key(IDA || TGKs || [KEK])
P := HMAC-SHA1(auth-key, O)
K := EPK-B(env-key), O, P, T, Rand, (IDB || Cert
S := SignSK-B(H(K))
K, S
Bild 3-13
MIKEY - asymmetrische Schlüsselverteilung mit Zertifikatsaustausch per
Innenband-Signalisierung
Dies ist eine weitere Option eines Schlüsselverwaltungsschemas und nicht im ursprünglichen MIKEY-Dokument enthalten. Die asymmetrische Schlüsselverteilung mit Zertifikatsaustausch per Innenband-Signalisierung ist in dem separaten Dokument [DMKEXT2] beschrieben.
Diese Option bietet gegenüber der in Abschnitt Asymmetrische Schlüsselverteilung beschriebenen asymmetrischen Schlüsselverteilung einige Vorteile. Der Absender und Empfänger brauchen hierbei nicht das Zertifikat des jeweils anderen Peers im Voraus zu kennen, da es in der MIKEY-Initiierungsnachricht gesendet wird. Der Empfänger dieser
Nachricht kann also die Sitzungsparameter anhand des empfangenen Schlüsselmaterials
verschlüsseln und sie als Teil der MIKEY-Antwortnachricht zurücksenden. Die Zertifikatsüberprüfung erfolgt entsprechend der Signierungsstelle. Ist das Zertifikat von einer Stelle
signiert, der beide Peers vertrauen, erfolgt die Validierung auf gemeinsamer Basis. Andernfalls können zusätzliche Schritte erforderlich sein; eine Option wäre die Verwendung
von Bestätigungen. Nachteilig ist, dass keine vollständige Vorwärtsgeheimhaltung gewährleistet ist, und die Schlüsselgenerierung nur durch den Initiator erfolgt.
6. Juni 2008
3-21
c03.fm
Technischer Anhang
3.2.7
MIKEY-Anwendung: Bootstrapping von TESLA – Übersicht
MIKEY an sich ist ein eigenständiges Schlüsselverwaltungsprotokoll, das in unterschiedlichen Szenarien eingesetzt werden kann. RFC 3830sieht bereits die Anwendung von MIKEY für den SRTP-Parameteraustausch vor, was jedoch nur eine von mehreren Nutzungsmöglichkeiten ist. Mit der Definition neuer Payloads für MIKEY ist auch ein Bootstrapping
anderer Sicherheitsprotokolle möglich. Ein Fallbeispiel hierfür ist nachfolgend beschrieben.
TESLA (Timed Efficient Stream Loss-tolerant Authentication) ist ein Protokoll zur Durchführung von Quellauthentifizierung in Multicast-Szenarien und ist in [DTESTLA] beschrieben. TESLA nutzt für die Authentifizierung MAC-Chaining. Zu den Nutzungsbeispielen für
TESLA zählen u.a. Präsentationen im Internet, Video-Streaming usw. TESLA erfordert
synchronisierte Peers für eine ordnungsgemäße Funktion.
Die Grundidee des von TESLA verwendeten MAC-Chaining ist in TESLA - Grundidee dargestellt. Der Absender von Mediadaten berechnet eine so genannte Hash-Kette, in der jeder Wert der Hash-Wert des Vorgängers ist. Der Mediaserver stellt die Integrität der Mediapakete anhand eines Keyed-Hash-Algorithmus (HMAC) sicher, wobei der Schlüssel der
Hash-Kette entspricht. Genauer gesagt, werden die zuerst gesendeten Pakete mit dem
letzten Schlüssel der Hash-Kette abgesichert. Dieser Schlüssel wird nach einer festgelegten Zeit von dem dem letzten Schlüssel vorangehenden Schlüssel ersetzt. Der Absender
gibt den letzten Schlüssel frei, damit die Empfänger die Integrität der empfangenen Pakete
verifizieren können. Der Empfänger muss also die empfangenen Pakete so lange speichern, bis der Integritätsschlüssel freigegeben wird. Hat ein Empfänger den vollständigen
Mediastrom, aber nicht alle Schlüssel für den Integritätsschutz erhalten, kann er die
Schlüssel neu berechnen, indem er durch Hashing des letzten Schlüssels die verwendeten
älteren Schlüssel ermittelt.
Bild 3-14
TESLA - Grundidee
Ein Nutzungsbeispiel für TESLA im Rahmen von SRTP (Secure Real-time Transport Protocol) wurde in [DTESLASRTP] veröffentlicht. Das Beispiel beruht auf der Annahme, dass
TESLA-Parameter durch Außenband-Mechanismen verfügbar gemacht werden. Siemens
hat ein Dokument über das Bootstrapping des TELSA-Parameters mittels MIKEY in [DB3-22
6. Juni 2008
c03.fm
Technischer Anhang
TESLA] veröffentlicht. In diesem Dokument wird eine neue MIKEY-Payload für den Transport aller für die TESLA-Quellauthentifizierung einer sicheren Gruppenkommunikation mit
SRTP benötigten Parameter vorgeschlagen. Die Beschreibung beruht auf einer der MIKEY-Schlüsselverwaltungsmodelle, z.B. mittels einer digital signierten, per Unicast, Multicast oder Broadcast transportierten MIKEY-Nachricht. Dieser Entwurf wurde 2006 fertiggestellt und liegt der RFC-Redaktion zur Bearbeitung vor.
6. Juni 2008
3-23
c03.fm
Technischer Anhang
3-24
6. Juni 2008
bkglos.fm
Glossar
Glossar
X
ACL
Abkürzung von Access List. Dies ist eine Liste der Einschränkungen für das Gast-VLAN.
Authenticator
Ein Authenticator ist im IEEE 802.1X-Sprachgebrauch ein Network Access Server, der in einer
RAS-Lösung als „Torwächter“ fungiert. „Supplicants“ genannte Clients beantragen bei ihm Zugang, den er nach Rückfrage bei einem zentralen Authentifizierungsserver mithilfe des RADIUS-Protokolls gewährt oder verweigert.
Auto-Enrollment
Seit Windows Server 2003 verfügbar. Bedeutet die Fähigkeit der automatischen Anforderung
und Verteilung von Zertifikaten, wenn dies gemäß Richtlinien erforderlich ist.
CA
siehe Certificate Authority (Zertifizierungsstelle)
Certificate Authority (Zertifizierungsstelle)
Eine Zertifizierungsstelle (kurz: CA) stellt digitale Zertifikate aus. In der IT ist ein digitales Zertifikat mit einem Pass zu vergleichen; es dient zur Bestätigung, dass ein öffentlicher Schlüssel
einer Person oder einer Organisation gehört. Die CA zertifiziert diese Zuordnung, indem sie
das Zertifikat mit ihrer eigenen Signatur versieht.
Zertifikate beinhalten „Schlüssel“ und weitere zur Authentifizierung benötigte Informationen sowie das Verschlüsseln/Entschlüsseln vertraulicher Daten, die über das Internet oder andere
Netzwerke gesendet werden. Weitere Informationen wie Ablaufdaten, Verweise auf Zertifikatswiderrufslisten usw. können von der CA in das Zertifikat aufgenommen werden.
Die grundlegende Aufgabe einer CA besteht in der Ausstellung und Verifizierung solcher Zertifikate. Die CA ist für die Bereitstellung, Zuweisung und Überprüfung der Integrität der Zertifikate verantwortlich. Sie ist daher wichtiger Teil der PKI.
Eine Zertifizierungsstelle kann eine bestimmte Firma sein (z.B. GlobalSign / Cybertrust, VeriSign) oder eine Institution innerhalb einer Firma mit eigenem speziellen Server (z.B. dem Microsoft Certificate Server). Öffentliche Organisationen oder Behörden können auch als CA agieren (z.B. die Bundesnetzagentur in Deutschland).
6. Juni 2008
X-1
bkglos.fm
Glossar
EAP
EAP (Extensible Authentication Protocol) vereinfacht die Verwendung einer breiteren Auswahl
an Authentifizierungsprotokollen und erschwert damit unautorisierte Zugriffe weiter.
EAPOL
Das in IEEE 802.1X definierte EAPOL (Extensible Authentication Protocol Over LAN) ist ein
Transportprotokoll für EAP zur Verkapselung von EAP-Paketen. Mit EAPOL lässt sich EAP
auch in heterogenen WAN-Umgebungen nutzen.
EAP-TLS
EAP-TLS ist eine Variante von EAP für die Verarbeitung von EAP-Kommunikation über eine
sichere TLS-Verbindung. Es kann auch zur Erzeugung von WEP-Schlüsseln und damit zum
Schutz eines WLAN genutzt werden.
EAP-TTLS
EAP-TTLS ist eine Variante von EAP-TLS. Außer dass es eine Authentifizierung über Zertifikate ermöglicht (ebenso wie EAP-TLS), gestattet EAP-TTLS auch die Nutzung anderer EAPMethoden wie MD5-Challenge und OTP (One-Time Password - einmaliges Passwort).
Instanz
In der Informationstechnologie bedeutet eine Instanz (Synonym: Informationsobjekt) ein eindeutig definiertes Objekt, dem Informationen zugewiesen sind. Die Objekte können greifbar
(z.B. der Kilimandscharo) oder nicht greifbar sein (z.B. die Abteilung RK12 einer Firma DemoAG).
Jede Instanz (das einzelne Objekt) ist einem Instanztyp zugewiesen - in den obigen Beispielen
„Berg“ und „Abteilung“. Instanzen sind konkrete Vorkommen eines Instanztyps. Mitunter wird
der Begriff „Instanztyp“ fälschlicherweise anstelle von „Instanz“ (Vorkommen eines Instanztyps) verwendet; in den meisten Fällen ergibt sich jedoch aus dem Zusammenhang, ob der Begriff auf ein einzelnes Objekt oder auf den Objekttyp bezogen ist.
Einzelne Instanzen desselben Instanztyps werden zu Instanzsätzen zusammengefasst. Die Instanzen innerhalb eines Instanzsatzes unterscheiden sich aufgrund ihrer Eigenschaften (Attributwerte) voneinander.
Jede Instanz eines bestimmten Instanztyps lässt sich anhand eines eindeutigen Attributwerts
von anderen Instanzen desselben Instanztyps unterscheiden (z.B. Fahrgestellnummer eines
bestimmten Autos oder ISBN-Nummer eines bestimmten Buchs).
Eine Instanz kann in Relation sowohl zu anderen Instanzen als auch zu sich selbst stehen.
Weitere Informationen über das Instanzrelationsmodell (ERM - Entity Relationship Model) finden Sie durch gezielte Internetrecherchen (z.B. über Google).
X-2
6. Juni 2008
bkglos.fm
Glossar
Beispiele für Instanztypen:
●
Kunden, gekennzeichnet durch das Attribut „Kundennummer“
●
Bankkonto, gekennzeichnet durch das Attribut „Kontonummer“
●
Buch, gekennzeichnet durch das Attribut „Bestandsnummer“ (z.B. in einer Bibliothek)
●
Buch, gekennzeichnet durch das Attribut „ISBN“ (im Verlagswesen)
IIS
HTTP-Server von Microsoft
PING
Abkürzung für „Packet Internet Groper“.
In diesem Fall wird ein Echoanforderungspaket an die Zieladresse gesendet. Wenn das Ziel
das Protokoll unterstützt und verfügbar ist, gibt es ein Echo zurück.
Public Key Infrastructure (PKI)
Bietet eine Umgebung für die Nutzung öffentlicher Schlüssel und besteht aus einer Kombination aus Software, Verschlüsselungstechniken und Diensten. Eine PKI sollte folgende Funktionen bereitstellen:
●
Zertifizierungsstellen (siehe Certificate Authority (Zertifizierungsstelle)), die Zertifikate
ausstellen und widerrufen können
●
Zertifikat-Herausgeber, wo Zertifikate gespeichert sind und eingesehen werden können
●
Tools zur Verwaltung von Schlüsseln und Zertifikaten
●
Programme und Anwendungen, die öffentliche Schlüssel nutzen können
RADIUS
RADIUS ist ein zur Authentifizierung in verteilten RAS-Lösungen genutztes Protokoll. Es vereinfacht den Austausch von Authentifizierungs-, Autorisierungs- und Konfigurationsdaten zwischen einem zentralen Authentifizierungsserver und dezentralen NASs (Network Access Servers), die als Clients des RADIUS-Servers fungieren. Stellt ein dezentral arbeitender Benutzer
eine Verbindung zum NAS her, fordert dieser die Angabe von Benutzernamen, Passwort,
NAS-ID und Port-ID an. Der NAS überprüft die Angaben (sowie, falls erforderlich, die Voraussetzungen für die Sitzung und die Dienst-Ports) anhand der RADIUS-Datenbank. So kann jedem Benutzer die Nutzung höherer IP-Protokoll einzeln gestattet oder verweigert werden und
dabei alles zentral verwaltet werden.
6. Juni 2008
X-3
bkglos.fm
Glossar
Supplicant
Im Zusammenhang mit IEEE 802.1X ist ein „Supplicant“ ein Client, der bei einem „Authenticator“ Zugang zu einem Netzwerk beantragt.
Wrapper
Im Allgemeinen ist dies ein Programm, das als Schnittstelle zwischen dem aufrufenden und
dem „eingepackten“ („wrapped“) Programmcode agiert. Wrappers können beispielsweise aus
Gründen der Kompatibilität genutzt werden, wenn der „eingepackte“ Code eine andere Programmiersprache verwendet, aus Sicherheitsgründen, z.B. um Zugriffsrechte zu erweitern
bzw. einzuschränken, oder zu Emulationszwecken. Ein ursprünglich für DirectX geschriebenes
Programm kann beispielsweise so für die Nutzung von OpenGL für Grafik modifiziert werden.
X-4
6. Juni 2008
bkIX.fm
Stichwörter
Stichwörter
Z
Zahlen
3DES-EDE-CBC 3-4
A
AES 3-16
Alert Protocol 3-2
Anonymes RSA-Verfahren 3-5
Anwendungsschicht 2-2
ARP 1-20
Asymmetrische Diffie-Hellman-Verteilung 1-12
Attributzertifikate 1-4
Authentifizierung 1-21
B
Benutzerauthentifizierung 3-15
Benutzerzertifikate 1-19
Bootstrapping 1-16
Bridge-CA-Architekturen 1-3
C
CA 1-2, 1-17, 1-22
CAP V3.0 1-16
CA-Zertifikat 2-2
Certificate Archive 1-2
Certificate Enrollment 1-15
Certificate Verify 3-3
Change Cipher Spec Protocol 3-2
Cipher-Suites 3-13
ClientHello 3-10
ClientKeyExchange 3-13
CMP 1-5, 1-15, 1-18
CMRF 1-5
CorNet IP 1-10
CRL 1-4, 1-15, 1-18
CSR 1-17
D
Datenintegrität 3-1
Datenvertraulichkeit 3-1
Diffie-Hellman-Verteilung 1-12
6. Juni 2008
Z-1
bkIX.fm
Stichwörter
Digitale Signaturen 1-4
DLS 1-10, 1-16
DLS-Server 1-15
E
EAP 1-14
EAP-TLS 1-14
End-to-End-Schlüsselverwaltung 2-3
F
Firewalls 3-1
G
Gerätezertifikate 1-19
H
H.235 2-3
H.323 1-10, 2-3
Handshake Protocol 3-2
Hashing mit SHA-1 3-4
Hello Request 3-11
HG1500/HG3550 1-15, 1-17
HiPath 4000 1-16
HiPath 4000 Assistant 1-17
HiPath 8000 1-14, 1-17
HiPath_PKI 1-2
hiQ4200 1-18
HMAC mit SHA-1 3-16
Hop-to-Hop 1-21
Hop-to-Hop-Sicherheit 1-13
HTTP 1-9, 3-1
HTTP-Digestauthentifizierung 2-3, 3-7
HTTPS-Port 3-2
I
Identitätszertifikate 1-4
IEEE802.1X 1-14
IEEE802.1x 1-8
IKE 1-14
Integrität 1-21
IPSec 1-8, 1-14
K
Kerberized TLS 3-4
Kerberos 3-4
Z-2
6. Juni 2008
bkIX.fm
Stichwörter
Key Generation 1-2
Klassen 1-19
Konfigurations Management 1-15
L
LDAP-Client 1-17
LDAP-Server 1-18
Lebenszyklus 1-4
Lizenzierung 2-1
Lizenztoken 2-1
M
MAC-Adresse 1-19
Master-Secret 3-3
Media Gateway 1-14
MIKEY 1-8, 1-11, 2-3, 3-16
MIKEY-Option 0 2-3
MKEY - Preshared-Key-Verteilung 3-16
O
OCSP 1-5, 1-18
Öffentlicher Schlüssel 2-1
optiPoint 1-18
P
Payload-Verschlüsselung 1-18
PEM 1-17
PKC=Public-Key Cryptography 1-15
PKCS #12 1-17
PKI 1-1
PKI light 1-15, 1-16
Preshared-Keys 3-13
Preshared-Key-Verteilung 3-16
Preshared-Secret-Basis 1-12
Privater Schlüssel 1-22
PSK Identity 3-13
Public Directory 1-2
R
RA 1-2
RADIUS-Server-Stammzertifikate 1-14
Renegotiation 3-3
Replay-Angriffe 2-2
Revocation Lists 1-2
RG8700-Gateways 1-18
6. Juni 2008
Z-3
bkIX.fm
Stichwörter
RSA 3-3
RSA-Verfahren 3-5
S
SCEP 1-15, 1-18
Schlüsselgenerierung 3-4
Schlüsselpaare 1-16
Schlüsselverwaltung 1-21
Schlüsselverwaltungsprotokoll 2-1
Serverzertifikat 1-19
SessionTicket 3-11
Siemens Root CA 2-1
Signaturüberprüfung 2-1
SIP 1-9
SIP-Kommunikation 3-7
SIPSEC2 2-1
Sitzungswiederaufnahme 3-9
SMTP 3-1
SSL 3-1
SSL/TLS-Stack-Integration 3-1
Stamm-CA 1-16
Stammzertifikat 3-4
Standardzertifikat 2-1
Startup 2-1
Stateless Cookies 3-14
T
Ticket 3-11
TLS 1-7, 1-9
TLS-Cipher-Suite 3-4
TLS-Handshake 3-3
TLS-Handshake Übersicht 3-14
TLS-Kanäle 2-3
TLS-Peers 3-1
TLS-PSK 3-13
TLS-Schlüsselverwaltung 3-13
TLS-Stack 3-1
Trust Center 1-2
U
Unilateral 3-4, 3-6
UW7 1-17
V
VeriSign 1-19, 1-22
Z-4
6. Juni 2008
bkIX.fm
Stichwörter
Vertraulichkeit 1-21
VPN 1-14
W
Widerrufslisten 1-2
X
X.509 1-4
X.509-Dateien 1-16, 1-17
X.509v3 3-3
X.509v3-Zertifkat 3-16
X.509-Zertifikate 1-18
XML-Signatur 2-2
Z
Zertifikatsarchiv 1-2
Zertifikatsaustausch 2-2
Zertifikatserstellung 1-15
Zertifikatstyp 1-21
Zertifikatsveröffentlichungsstelle 1-2
Zweiwege-Handshakes 3-15
6. Juni 2008
Z-5
bkIX.fm
Stichwörter
Z-6
6. Juni 2008
bkabk.fm
Abkürzungen
Abkürzungen
Y
Nachfolgend sind die in diesem Handbuch verwendeten Abkürzungen aufgeführt.
Abkürzung
Definition
AH
Authentication Header, Modus von IPsec
BCP
Best Current Practice (beste derzeitige Vorgehensweise)
CA
Certificate Authority (Zertifizierungsstelle)
CorNet IP/NQ
Zwischen HiPath-Knoten verwendetes Protokoll
CorNet IP/TS
Zwischen HFA-Phone bzw. Client und HiPath-Knoten verwendetes Protokoll
DHCP
Dynamic Host Configuration Protocol (Protokoll für dynamische Hostkonfiguration)
DLS
Deployment and Licensing Service (Bereitstellungs- und Lizenzierungsdienst)
DNS
Domänennamen-Server
DTLS
Datagramm-TLS (Datenpaket-TLS)
EAP
Extensible Authentication Protocol (Protokoll für erweiterbare Authentifizierung)
EAPOL
Extensible Authentication Protocol Over LAN (Protokoll für erweiterbare Authentifizierung über LAN)
ESP
Encapsulated Security Payload (Sicherheitsverkapselung), Modus von IPSec
FTP
File Transfer Protocol (Datenübertragungsprotokoll)
HFA
HiCom Feature Access (HiCom-Leistungsmerkmalzugang)
HMAC
Hashed-MAC-Algorithmus
IAS
Internet Authentication Service (Internet-Authentifizierungsdienst)
IETF
Internet Engineering Task Force; Organisation zur Entwicklung von InternetStandards
IIIS
Internet Information Server
IP
Internet Protocol
IPSec
Internet Protocol Security (IP-Sicherheit)
ISDN
Integrated Services Digital Network (Dienste-integrierendes digitales Fernmeldenetz)
6. Juni 2008
IEEE 802.1x, optiPoint 410/420 Familie, Konfigurations-Management
Y-1
bkabk.fm
Abkürzungen
Abkürzung
Definition
KDC
Key Distribution Service (Kerberos); Protokoll zur Authentifizierung von Benutzern
MIKEY
Multimedia Internet Keying (Multimedia-Internet-Verschlüsselung)
NAT
Network Address Translation (Netzwerkadressübersetzung)
PEAP
Protected Extensible Authentication Protocol (Protokoll für geschützte erweiterbare Authentifizierung)
PICS
Protocol Implementation Component Statement (Konformitätserklärung zur
Protokollimplementierung)
PKI
Public Key Infrastructure (Infrastruktur zur Verwendung asymmetrischer
Verschlüsselungsverfahren)
PPP
Point-to-Point-Protokoll
PRF
Pseudo Random Function (Zufallszahlenfunktion)
PSK
Preshared-Key (vorab ausgetauschter Schlüssel)
PSTN
Public Switched Telephone Network (öffentliches Telefonnetz)
RDI
Restricted Digital Information (eingeschränkte digitale Informationen; Teil
von ISDN)
RFC
Request For Comments (Aufforderung zu Kommentaren); eine IETF-Protokollspezifikation
RTP
Real-time Transport Protocol (Echtzeittransport-Protokoll)
S/MIME
Secure Multipurpose Internet Mail Extensions (Codierungsstandard zur
Festlegung der Struktur von E-Mails und anderen Internetnachrichten)
SAML
Security Assertion Markup Language (Auszeichnungssprache für Sicherheitsbestätigungen)
SCN
Switched Circuit Network (leitungsvermitteltes Netz)
SDP
Session Description Protocol (Sitzungsbeschreibungsprotokoll)
SHA
Secure-Hash-Algorithmus (SHA-1)
SIP
Session Invitation Protocol (Sitzungseinladungsprotokoll)
SRTCP
Secure Real-time Transport Control Protocol (Steuerungsprotokoll für sicheren Echtzeittransport)
SRTP
Secure Real-time Transport Protocol (Protokoll für sicheren Echtzeittransport)
SSL
Secure Socket Layer (Protokoll für sichere, verschlüsselte Kommunikation
im Internet)
TAP
Techniker ArbeitsPlatz (meist ein mit spezieller Hardware und Software ausgerüstetes Techniker-Notebook)
Y-2
6. Juni 2008
bkabk.fm
Abkürzungen
Abkürzung
Definition
TDM
Time Division Multiplex (Zeitmultiplex)
TESLA
Timed Efficient Stream Loss-tolerant Authentication (Verfahren zur individuellen Absenderauthentifizierung von Multicast-Nachrichten)
TLS
Transport Layer Security (Verschlüsselungsprotokoll für Datenübertragungen im Internet)
TLS-PSK
TLS- Preshared-Key (über TLS vorab ausgetauschter Schlüssel)
TTLS
Tunneled Transport Layer Security (Aufbau eines sicheren TLS-Kanals für
beliebige Authentifizierungsverfahren)
UAC
User Agent-Client
UAS
User Agent-Server
UDI
Unrestricted Digital Information (uneingeschränkte digitale Informationen;
Teil von ISDN)
URI
Uniform Resource Indicator (allgemeinere Form der URL)
VID
Virtual LAN ID (0-4095)
VLAN
Virtual LAN
6. Juni 2008
Y-3
bkabk.fm
Abkürzungen
Y-4
6. Juni 2008
www.siemens.com/enterprise
Die Informationen in diesem Dokument enthalten lediglich allgemeine
Beschreibungen bzw. Leistungsmerkmale, welche im konkreten
Anwendungsfall nicht immer in der beschriebenen Form zutreffen bzw.
welche sich durch Weiterentwicklung der Produkte ändern können.
Die gewünschten Leistungsmerkmale sind nur dann verbindlich, wenn
sie bei Vertragsschluss ausdrücklich vereinbart werden. Die
verwendeten Marken sind Eigentum der Siemens Enterprise
Communications GmbH & Co. KG bzw. der jeweiligen Inhaber..
Die Konformität des Gerätes zu der EU-Richtlinie 1999/5/EG
wird durch das CE-Kennzeichen bestätigt.
Dieses Gerät wurde nach unserem zertifizierten Umweltmanagementsystem (ISO 14001) hergestellt.
Dieser Prozess stellt die Minimierung des Primärrohstoff- und des
Energieverbrauchs sowie der Abfallmenge sicher.
*1PA31003-J4200-M100-3-A9*
Copyright © Siemens Enterprise
Communications GmbH & Co. KG 6.6.08
Hofmannstr. 51 • D-81359 München
Bestell-Nr.: A31003-J4200-M100-3-A9
Liefermöglichkeiten und technische Änderungen vorbehalten.

1 Zertifikate in HiPath

Transcrição

Documentos relacionados

HiPath Cordless Office für HiPath 500 und HiPath 3000 Familie

HiPath 500 V7 Datenblatt

HiPath Xpressions Advanced Unified Messaging

Anleitung FTP - Alfahosting.de

FOREST OPPORTUNITY

Emissionsbrief 07-2016 - Emissionshaendler.com

SMTP-Relay für Homepage-Produkte 20 KB

Budget vs target constrained auctions for conservation contracts

HiPath 8000 V3.1 - Telefonbau Schneider

HiPath 1220 - Brunner + Imboden AG