Kapitel 23 Konfiguration von IKE (Aufgaben)

In diesem Kapitel wird beschrieben, wie Sie den Internet Key Exchange (IKE) für Ihre Systeme konfigurieren. Nachdem IKE konfiguriert wurde, erzeugt es automatisch das für die Ausführung von IPsec in Ihrem Netzwerk erforderliche Schlüsselmaterial. Dieses Kapitel enthält die folgenden Informationen:

• Konfiguration von IKE (Übersicht der Schritte)

• Konfiguration von IKE mit PresharedKeys (Übersicht der Schritte)

• Konfiguration von IKE mit PublicKey-Zertifikaten (Übersicht der Schritte)

• Konfiguration von IKE für mobile Systeme (Übersicht der Schritte)

• Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte)

• Ändern der IKE-Übertragungsparameter (Übersicht der Schritte)

Eine Einführung in IKE finden Sie in Kapitel 22Internet Key Exchange (Übersicht). Referenzinformationen zu IKE finden Sie in Kapitel 24Internet Key Exchange (Referenz). Weitere Verfahren finden Sie im Beispielbereich der Manpages ikeadm(1M), ikecert(1M) und ike.config(4).

Konfiguration von IKE (Übersicht der Schritte)

Zur Authentifizierung von IKE können Sie PresharedKeys, selbst-designierte Zertifikate und Zertifikate von einer Zertifizierungsstelle (Certificate Authority, CA) verwenden. Eine Regel verbindet die jeweilige IKE-Authentifizierungsmethode mit den zu schützenden Endpunkten. Aus diesem Grund können Sie eine oder alle IKE-Authentifizierungsmethoden in einem System verwenden. Mit einem Zeiger auf die PKCS&;#11-Bibliothek können Zertifikate auch einen angehängten Hardwarebeschleuniger verwenden.

Nachdem Sie IKE konfiguriert haben, führen Sie die IPsec-Aufgabe aus, in der die IKE-Konfiguration verwendet wird. In der folgenden Tabelle wird auf die Übersichten verwiesen, die sich auf eine bestimmte IKE-Konfiguration beziehen.

Konfiguration von IKE mit PresharedKeys (Übersicht der Schritte)

In der folgenden Tabelle wird auf Verfahren zur Konfiguration und Verwaltung von IKE mit PresharedKeys verwiesen.

Konfiguration von IKE mit PresharedKeys

PresharedKeys ist die einfachste Authentifizierungsmethode für IKE. Wenn Sie beide Systeme so könfigurieren, dass sie IKE verwenden und Administrator beide Systeme sind, ist die Methode PresharedKeys eine gute Wahl. Im Gegensatz zu PublicKey-Zertifikaten sind PresharedKeys jedoch an bestimmte IP-Adressen gebunden. PresharedKeys können daher nicht mit mobilen Systemen oder Systemen verwendet werden, die neue Adressen erhalten. Darüber hinaus können Sie bei der Verwendung von PresharedKeys die Berechnung von IKE-Vorgängen nicht an angehängte Hardware abgeben.

So konfigurieren Sie IKE mit PresharedKeys

Die IKE-Implementierung bietet Algorithmen, deren Schlüssel unterschiedlich lang sind. Die von Ihnen gewählte Schlüssellänge wird von der Standortsicherheit vorgegeben. Im Allgemeinen bieten längere Schlüssel größere Sicherheit als kürzere Schlüssel.

In diesen Verfahren werden die Systeme enigma und partym verwendet. Ersetzen Sie enigma und partym durch die Namen Ihrer Systeme.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Kopieren Sie auf jedem System die Datei /etc/inet/ike/config.sample nach /etc/inet/ike/config.

3. Geben Sie die Regeln und globalen Parameter auf jedem System in die Datei ike/config ein.

   Die Regeln und globalen Parameter in dieser Datei müssen zulassen, dass die IPsec-Richtlinie in der Datei ipsecinit.conf auf dem System erfolgreich ist. Die folgenden ike/config-Beispiele arbeiten mit den ipsecinit.conf-Beispielen unter So sichern Sie Datenverkehr zwischen zwei Systemen mit IPsec.

   1. Ändern Sie beispielsweise die Datei /etc/inet/ike/config auf dem System enigma:

      ### ike/config file on enigma, 192.168.116.16 ## Global parameters # ## Phase 1 transform defaults p1_lifetime_secs 14400 p1_nonce_len 40 # ## Defaults that individual rules can override. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 # ## The rule to communicate with partym # Label must be unique { label "enigma-partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 }

      ---

      Hinweis –

      Alle Argumente für den Parameter auth_method müssen sich auf der gleichen Zeile befinden.

      ---

   2. Ändern Sie die Datei /etc/inet/ike/config auf dem System partym:

      ### ike/config file on partym, 192.168.13.213 ## Global Parameters # p1_lifetime_secs 14400 p1_nonce_len 40 # p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 2 ## The rule to communicate with enigma # Label must be unique { label "partym-enigma" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes } p2_pfs 5 }

4. Prüfen Sie auf den einzelnen Systemen die Dateisyntax.

   # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

5. Erzeugen Sie Zufallszahlen für das Schlüsselmaterial.

   Falls Ihr Standort über einen Generator für Zufallszahlen verfügt, verwenden Sie diesen. Auf einem Solaris-System können Sie den Befehl od verwenden. Beispielsweise druckt der folgende Befehl zwei Zeilen mit hexadezimalen Zahlen:

   % od -X -A n /dev/random | head -2 f47cb0f4 32e14480 951095f8 2b735ba8 0a9467d0 8f92c880 68b6a40e 0efe067d

   Eine Beschreibung des Befehls od finden Sie unter So erzeugen Sie Zufallszahlen auf einem Solaris-System und in der Manpage od(1).

   ---

   Hinweis –

   Andere Betriebssysteme erfordern Schlüsselmaterial im ASCII-Format. Wie Sie einen identischen Schlüssel im hexadezimalen und im ASCII-Format erzeugen, finden Sie unter Beispiel 23–1.

   ---

6. Erzeugen Sie einen Schlüssel aus der Ausgabe in Schritt 5.

   f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

   Der Authentifizierungsalgorithmus in diesem Verfahren ist SHA–1 (wie in Schritt 3 gezeigt). Die Größe des Hash (d. h., die Größe der Ausgabe des Authentifizierungsalgorithmus) schreibt die empfohlene Mindestmenge für einen PresharedKey vor. Die Ausgabe des SHA–1-Algorithmus beträgt 160 Bit oder 40 Zeichen. Der Beispielschlüssel ist 56 Zeichen lang, wodurch IKE zusätzliches Schlüsselmaterial verwenden kann.

7. Erstellen Sie auf jedem System eine /etc/inet/secret/ike.preshared-Datei.

   Geben Sie den PresharedKey in jede Datei ein.

   1. Auf dem System enigma enthält die ike.preshared-Datei dann Folgendes:

      # ike.preshared on enigma, 192.168.116.16 #… { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.13.213 # enigma and partym's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }

   2. Auf dem System partym enthält die ike.preshared-Datei dann Folgendes:

      # ike.preshared on partym, 192.168.13.213 #… { localidtype IP localid 192.168.13.213 remoteidtype IP remoteid 192.168.116.16 # partym and enigma's shared key in hex (192 bits) key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e }

   ---

   Hinweis –

   Die PresharedKeys auf den Systemen müssen identisch sein.

   ---

Beispiel 23–1 Erzeugen von identischem Schlüsselmaterial für zwei Systeme mit unterschiedlichen Betriebssystemen

Solaris IPsec kann mit anderen Betriebssystemen zusammenarbeiten. Falls Ihr System mit einem System kommuniziert, das PresharedKeys im ASCII-Format benötigt, müssen Sie einen Schlüssel in zwei Formaten, hexadezimal und ASCII, erstellen.

Im folgenden Beispiel möchte der Solaris-Systemadministrator 56 Zeichen für das Schlüsselmaterial verwenden. Der Administrator verwendet den folgenden Befehl, um einen hexadezimalen Schlüssel aus einem ASCII-Passwortsatz zu erzeugen. Mit der Option -tx1 werden die Byte nacheinander auf allen Solaris-Systemen gedruckt.

# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

Durch Entfernen der Offsets und Verketten der hexadezimalen Ausgabe wird der hexadezimalen Schlüssel für das Solaris-System erstellt: 7061706965726d616368652077697468206361736865777320616e64 . Der Administrator fügt diesen Wert in die Datei ike.preshared auf dem Solaris-System ein.

# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

Auf dem System, das PresharedKeys im ASCII-Format erfordert, bildet der Passwortsatz den PresharedKey. Der Solaris-Systemadministrator sendet dem anderen Administrator telefonisch den Passwortsatz papiermache with cashews and.

So werden IKE PresharedKeys aktualisiert

Bei diesem Verfahren wird davon ausgegangen, dass Sie einen vorhandenen PresharedKey in regelmäßigen Intervallen ersetzen möchten.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Erzeugen Sie Zufallszahlen und konstruieren Sie einen Schlüssel in der erforderlichen Länge.

   Ausführliche Informationen finden Sie im Abschnitt So erzeugen Sie Zufallszahlen auf einem Solaris-System. Informationen zum Erzeugen von Schlüsselmaterial für ein Solaris-System, das mit einem Betriebssystem kommuniziert, das Schlüsselmaterial im ASCII-Format benötigt, finden Sie in Beispiel 23–1.

3. Ersetzen Sie den aktuellen Schlüssel durch einen neuen Schlüssel.

   Bei den Hosts enigma und partym ersetzen Sie den Wert von key in der Datei /etc/inet/secret/ike.preshared durch eine Zahl der gleichen Länge.

4. Lesen Sie den neuen Schlüssel in den Systemkern ein.

   • Wenn Sie mindestens mit Solaris 10 4/09 arbeiten, aktualisieren Sie den ike-Service.

     # svcadm refresh ike

   • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, muss der in.iked-Daemon beendet und neu gestartet werden.

     1. Überprüfen Sie die Privilegstufe des in.iked-Daemons.

        # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled

        Sie können das Schlüsselmaterial ändern, wenn dieser Befehl eine Privilegstufe von 0x1 oder 0x2 zurückgibt. Bei der Privilegstufe 0x0 ist das Ändern oder Anzeigen von Schlüsselmaterial nicht gestattet. Standardmäßig wird der in.iked-Daemon mit der Privilegstufe 0x0 ausgeführt.

     2. Lautet die Privilegstufe 0x0, brechen Sie den Daemon ab und starten ihn neu.

        Wenn der Daemon neu startet, liest er die neue Version der ike.preshared-Datei ein.

        # pkill in.iked # /usr/lib/inet/in.iked

     3. Lautet die Privilegstufe 0x1 oder 0x2, lesen Sie die neue Version der ike.predshared-Datei ein.

        # ikeadm read preshared

So rufen Sie IKE PresharedKeys auf

Standardmäßig verhindert der Befehl ikeadm die Anzeige der tatsächlichen Schlüssel in einem Speicherauszug einer Phase-1-SA. Die Anzeige der Schlüssel ist bei der Fehlersuche hilfreich.

Um die tatsächlichen Schlüssel anzuzeigen, müssen Sie die Privilegstufe für diesen Daemon erhöhen. Eine Beschreibung der Privilegstufe finden Sie unter IKE-Verwaltungsbefehl.

Wenn Sie dieses Verfahren in einer Version vor Solaris 10 4/09 durchführen möchten, schauen Sie sich die Hinweise unter Beispiel 23–2 an.

Bevor Sie beginnen

IKE ist konfiguriert, und der ike-Service wird ausgeführt.

1. Rufen Sie die IKE PresharedKeys auf.

   # ikeadm ikeadm> dump preshared

2. Wenn ein Fehler auftritt, erhöhen Sie die Privilegstufe des in.iked-Daemons.

   1. Erhöhen Sie die Privilegstufe des in.iked-Daemons im SMF-Repository.

      # svcprop -p config/admin_privilege ike base # svccfg -s ike setprop config/admin_privilege=keymat

   2. Erhöhen Sie die Privilegstufe des ausgeführten in.iked-Daemons.

      # svcadm refresh ike ; svcadm restart ike

   3. (Optional) Überprüfen Sie, ob die Privilegstufe keymat lautet.

      # svcprop -p config/admin_privilege ike keymat

   4. Zeigen Sie die Schlüssel an, indem Sie Schritt 1 erneut ausführen.

3. Legen Sie für den IKE-Daemon wieder die Basis-Privilegstufe fest.

   1. Legen Sie nach der Betrachtung der Schlüssel wieder die ursprüngliche Privilegstufe fest.

      # svccfg -s ike setprop config/admin_privilege=base

   2. Aktualisieren Sie die Ansicht, und starten Sie IKE anschließend neu.

      # svcadm refresh ike ; svcadm restart ike

Beispiel 23–2 Überprüfen von IKE PresharedKeys in einer Version vor Solaris 10 4/09

Im folgenden Beispiel betrachtet der Administrator Schlüssel auf einem System mit einer älteren Solaris-Version. Der Administrator möchte sich vergewissern, dass die Schlüssel im System identisch mit den Schlüsseln im Kommunikationssystem sind. Nachdem der Administrator festgestellt hat, dass die Schlüssel der beiden Systeme identisch sind, stellt er die Privilegstufe 0 wieder her.

• Zuerst bestimmt der Administrator die Privilegstufe des in.iked-Daemons.

  adm1 # /usr/sbin/ikeadm get priv Current privilege level is 0x0, base privileges enabled

• Da die Privilegstufe nicht 0x1 bzw. 0x2 lautet, hält der Administrator den in.iked-Daemon an und erhöht anschließend die Privilegstufe auf 2.

  adm1 # pkill in.iked adm1 # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2

• Der Administrator zeigt die Schlüssel an.

  adm1 # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (adm1). REMIP: AF_INET: port 0, 192.168.13.213 (com1).

• Der Administrator meldet sich am Kommunikationssystem an und stellt fest, dass die Schlüssel identisch sind.

• Anschließend setzt der Administrator die Privilegien wieder auf die Basisstufe zurück.

  # ikeadm set priv base

So fügen Sie einen IKE PresharedKey für einen neuen Richtlinieneintrag in ipsecinit.conf ein

Wenn Sie IPsec-Richtlinieneinträge hinzufügen, während IPsec und IKE ausgeführt werden, müssen Sie die neue Richtlinie und die neuen IKE-Regeln in den Systemkern einlesen. Wenn Sie mindestens mit Solaris 10 4/09 arbeiten, starten Sie den policy-Service neu und aktualisieren den ike-Service, nachdem Sie die neuen Schlüssel hinzugefügt haben.

Wenn Sie dieses Verfahren in einer Version vor Solaris 10 4/09 durchführen möchten, schauen Sie sich die Hinweise unter Beispiel 23–3 an.

Bevor Sie beginnen

Bei diesem Verfahren wird das folgende Setup vorausgesetzt:

• Das System enigma ist wie unter So konfigurieren Sie IKE mit PresharedKeys beschrieben eingerichtet.

• Das System enigma schützt seinen Datenverkehr mit einem neuen System ada.

• Der in.iked-Daemon wird auf beiden Systemen ausgeführt.

• Die Schnittstellen der Systeme sind auf beiden Systemen als Einträge in der Datei /etc/hosts vorhanden. Ein Beispiel wäre der folgende Eintrag.

  192.168.15.7 ada 192.168.116.16 enigma

  Dieses Verfahren arbeitet auch mit einer IPv6-Adresse in der Datei /etc/inet/ipnodes. Ab Solaris 10 6/07 werden IPv6-Einträge in der Datei /etc/hosts abgelegt.

• Sie haben auf beiden Systemen einen neuen Richtlinieneintrag in die Datei /etc/inet/ipsecinit.conf eingefügt. Die Einträge sind ähnlich den Folgenden:

  # ipsecinit.conf file for enigma {laddr enigma raddr ada} ipsec {auth_algs any encr_algs any sa shared}

  # ipsecinit.conf file for ada {laddr ada raddr enigma} ipsec {auth_algs any encr_algs any sa shared}

• In der aktuellen Version haben Sie die Syntax der Datei /etc/inet/ipsecinit.conf auf beiden Systemen mit folgendem Befehl überprüft:

  # ipsecconf -c -f /etc/inet/ipsecinit.conf

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Erstellen Sie auf diesem System Zufallszahlen und einen Schlüssel mit 64 bis 448 Bit.

   Ausführliche Informationen finden Sie im Abschnitt So erzeugen Sie Zufallszahlen auf einem Solaris-System. Informationen zum Erzeugen von Schlüsselmaterial für ein Solaris-System, das mit einem Betriebssystem kommuniziert, das Schlüsselmaterial im ASCII-Format benötigt, finden Sie in Beispiel 23–1.

3. Senden Sie den Schlüssel an den Administrator des remoten Systems.

   Beide Administratoren müssen den gleichen PresharedKey zum gleichen Zeitpunkt hinzufügen. Ihr Schlüssel ist nur so sicher wie die Sicherheit Ihres Übertragungsmechanismus. Wir empfehlen einen außerbandigen Mechanismus, z. B. einen Einschreibebrief oder eine geschützte Faxübertragung. Sie können die beiden Systeme auch über eine ssh-Sitzung verwalten.

4. Erstellen Sie eine Regel für IKE, um die Schlüssel für enigma und ada zu verwalten.

   1. Fügen Sie auf dem System enigma der Datei /etc/inet/ike/config die folgende Regel hinzu:

      ### ike/config file on enigma, 192.168.116.16   ## The rule to communicate with ada {label "enigma-to-ada" local_addr 192.168.116.16 remote_addr 192.168.15.7 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 }

   2. Fügen Sie auf dem System ada die folgende Regel hinzu:

      ### ike/config file on ada, 192.168.15.7   ## The rule to communicate with enigma {label "ada-to-enigma" local_addr 192.168.15.7 remote_addr 192.168.116.16 p1_xform {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish} p2_pfs 5 }

5. Stellen Sie sicher, dass die IKE PresharedKeys beim erneuten Booten zur Verfügung stehen.

   1. Fügen Sie auf dem System enigma der Datei /etc/inet/secret/ike.preshared die folgenden Informationen hinzu:

      # ike.preshared on enigma for the ada interface #  { localidtype IP localid 192.168.116.16 remoteidtype IP remoteid 192.168.15.7 # enigma and ada's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }

   2. Fügen Sie auf dem System ada der Datei ike.preshared die folgenden Informationen hinzu:

      # ike.preshared on ada for the enigma interface #  { localidtype IP localid 192.168.15.7 remoteidtype IP remoteid 192.168.116.16 # ada and enigma's shared key in hex (32 - 448 bits required) key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d }

6. Starten Sie auf den einzelnen Systemen den Service für die IPsec-Richtlinie neu, damit die neue Schnittstelle ebenfalls geschützt wird.

   # svcadm restart policy

7. Aktualisieren Sie auf den einzelnen Systemen den ike-Service.

   # svcadm refresh ike

8. Prüfen Sie, ob die Systeme miteinander kommunizieren können.

   Lesen Sie dazu So prüfen Sie, ob die IKE PresharedKeys identisch sind.

Beispiel 23–3 Hinzufügen eines IKE PresharedKeys für einen neuen IPsec-Richtlinieneintrag

Im folgenden Beispiel fügt der Administrator einen PresharedKey einem System hinzu, auf dem nicht die aktuellste Solaris-Version ausgeführt wird. Der Administrator befolgt das vorstehende Verfahren zur Änderung der Dateien ike/config und ike.preshared, zur Erstellung von Schlüsseln und zur Herstellung einer Verbindung zum Remote-System. Zum Einlesen der neuen IPsec-Richtlinie und der IKE-Regeln in den Systemkern verwendet der Administrator unterschiedliche Befehle.

• Vor der Erstellung des neuen Schlüssels legt der Administrator die Privilegstufe des in.iked-Daemons auf 2 fest.

  # pkill in.iked # /usr/lib/inet/in.iked -p 2 Setting privilege level to 2

• Nachdem der Schlüssel an das andere System versendet und dem System hinzugefügt wurde, wählt der Administrator eine niedrigere Privilegstufe aus.

  # ikeadm set priv base

• Anschließend liest der Administrator die neue IPsec-Richtlinie in den Systemkern ein.

  # ipsecconf -a /etc/inet/ipsecinit.conf

• Zum Schluss werden die neuen IKE-Regeln in den Systemkern eingelesen.

  # ikeadm read rules

So prüfen Sie, ob die IKE PresharedKeys identisch sind

Wenn die PresharedKeys auf den kommunizierenden Systemen nicht identisch sind, können die Systeme nicht authentifiziert werden.

Bevor Sie beginnen

IPsec wurde konfiguriert und ist zwischen den zu testenden Systemen aktiviert. Sie führen die aktuelle Version (Solaris 10) aus.

Wenn Sie dieses Verfahren in einer Version vor Solaris 10 4/09 durchführen möchten, schauen Sie sich die Hinweise unter Beispiel 23–2 an.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh für eine sichere Remoteanmeldung.

   ---

2. Prüfen Sie auf den einzelnen Systemen die Privilegstufe des in.iked-Daemons.

   # svcprop -p config/admin_privilege ike base

   • Falls die Privilegstufe keymat lautet, fahren Sie mit Schritt 3 fort.

   • Falls die Privilegstufe base oder modkeys lautet, erhöhen Sie die Stufe.

     Aktualisieren Sie anschließend das System, und starten Sie den ike-Service neu.

     # svccfg -s ike setprop config/admin_privilege=keymat # svcadm refresh ike ; svcadm restart ike # svcprop -p config/admin_privilege ike keymat

3. Zeigen Sie die PresharedKey-Informationen auf beiden Systemen an.

   # ikeadm dump preshared PSKEY: Preshared key (24 bytes): f47cb…/192 LOCIP: AF_INET: port 0, 192.168.116.16 (enigma). REMIP: AF_INET: port 0, 192.168.13.213 (partym).

4. Vergleichen Sie die beiden Speicherauszüge.

   Sind die PresharedKeys nicht identisch, ersetzen Sie in der Datei /etc/inet/secret/ike.preshared einen Schlüssel durch den anderen.

5. Ändern Sie die Privilegstufe nach Abschluss der Prüfung wieder in den jeweiligen Standardwert der Systeme.

   # svccfg -s ike setprop config/admin_privilege=base # svcadm restart ike

Konfiguration von IKE mit PublicKey-Zertifikaten (Übersicht der Schritte)

Die folgende Tabelle enthält Verweise auf Verfahren, in denen beschrieben wird, wie PublicKey-Zertifikaten für IKE erzeugt werden. Außerdem enthalten die Verfahren Informationen zum Beschleunigen und Speichern der Zertifikate auf angehängter Hardware.

Konfiguration von IKE mit PublicKey-Zertifikaten

Mit PublicKey-Zertifikaten müssen kommunizierende Systeme kein geheimes außerbandiges Schlüsselmaterial mehr verwenden. Im Gegensatz zu PresharedKeys kann ein PublicKey-Zertifikat auf einem mobilen Computer oder auf einem System verwendet werden, dass neu nummeriert werden kann.

PublicKey-Zertifikate können auch auf angehängter Hardware gespeichert werden. Informationen hierzu finden Sie unter Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte).

So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten

Selbst-designierte Zertifikate erfordern weniger Aufwand als öffentliche Zertifikate von einer CA, lassen sich jedoch nicht einfach skalieren.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Fügen Sie ein selbst-signiertes Zertifikat in die Datenbank ike.privatekeys ein.

   # ikecert certlocal -ks|-kc -m keysize -t keytype \ -D dname -A altname \ [-S validity-start-time] [-F validity-end-time] [-T token-ID]

   -ks

   Erstellt ein selbst-signiertes Zertifikat.

   -kc

   Erstellt eine Zertifikatanforderung. Informationen hierzu finden Sie unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden.

   -m Schlüsselgröße

   Die Größe des Schlüssels. Schlüsselgröße kann 512, 1024, 2048, 3072 oder 4096 annehmen.

   -t Schlüsseltyp

   Gibt den zu verwendenden Algorithmustyp an. Schlüsseltyp kann rsa-sha1, rsa-md5 oder dsa-sha1 annehmen.

   -D dname

   Der X.509-Distinguished Name (DN) für das Zertifikatssubjekt. dname hat in der Regel folgende Form: C=Land, O= Organisation, OU= Organisationseinheit, CN= allgemeiner Name. Gültige Tags sind C, O, OU und CN.

   -A altname

   Der Alternativname für das Zertifikat. altname hat im allgemeinen das Format Tag=Wert. Gültige Tags sind IP, DNS, email und DN.

   -S Gültigkeit-Anfang

   Ist das absolute oder relative Anfangsdatum der Zertifikatsgültigkeit.

   -F Gültigkeit-Ende

   Ist das absolute oder relative Enddatum der Zertifikatsgültigkeit.

   -T Token-ID

   Ermöglicht, dass ein PKCS&;#11-Hardwaretoken die Schlüssel erzeugt. Die Zertifikate werden dann auf der Hardware gespeichert.

   1. Der Befehl auf dem System partym sieht in etwa wie folgt aus:

      # ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ -A IP=192.168.13.213 Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/0. Enabling external key providers - done. Acquiring private keys for signing - done. Certificate: Proceeding with the signing operation. Certificate generated successfully (…/publickeys/0) Finished successfully. Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----

   2. Der Befehl auf dem System enigma sieht in etwa wie folgt aus:

      # ikecert certlocal -ks -m 1024 -t rsa-md5 \ -D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \ -A IP=192.168.116.16 Creating software private keys. … Certificate added to database. -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE-----

3. Speichern Sie das Zertifikat und senden Sie es an das remote System.

   Sie können das Zertifikat in eine E-Mail einfügen.

   1. So können Sie das folgende partym-Zertifikat an den Administrator von enigma senden:

      To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX … 6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU -----END X509 CERTIFICATE-----

   2. Der Administrator von enigma sendet Ihnen das folgende enigma-Zertifikat:

      To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV … jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A== -----END X509 CERTIFICATE-----

4. </remark>Fügen Sie auf jedem System das empfangene Zertifikat ein.

   1. Kopieren Sie den PublicKey aus der E-Mail des Administrators.

   2. Geben Sie den Befehl ikecert certdb -a ein, und drücken Sie die Eingabetaste.

      Wenn Sie die Eingabetaste drücken, werden keine Eingabeaufforderungen angezeigt.

      # ikecert certdb -a Press the Return key

   3. Fügen Sie den PublicKey ein, und drücken Sie die Eingabetaste. Drücken Sie dann Strg-D, um den Eintrag zu beenden.

      -----BEGIN X509 CERTIFICATE----- MIIC… … ----END X509 CERTIFICATE----- Press the Return key <Control>-D

5. Prüfen Sie gemeinsam mit dem anderen Administrator, dass das Zertifikat von diesem Administrator stammt.

   Beispielsweise können Sie mit dem anderen Administrator telefonieren und die Werte des PublicKey-Hash vergleichen. Das PublicKey-Hash für das gemeinsam genutzte Zertifikat muss auf beiden Systemen gleich sein.

   1. Listen Sie das gespeicherte Zertifikat auf Ihrem System auf.

      So befindet sich das öffentliche Zertifikat z. B. auf dem System partym in Slot 1 und das private Zertifikat in Slot 0.

      partym # ikecert certdb -l Certificate Slot Name: 0 Type: rsa-md5 Private Key Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2 Certificate Slot Name: 1 Type: rsa-md5 Public Certificate (Private key in certlocal slot 0) Points to certificate's private key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

   2. Vergleichen Sie diesen Wert mit dem PublicKey-Hash auf dem System enigma.

      Sie können den PublicKey-Hash über das Telefon vorlesen.

      enigma # ikecert certdb -l Certificate Slot Name: 4 Type: rsa-md5 Private Key Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax> Key Size: 1024 Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0 Certificate Slot Name: 5 Type: rsa-md5 Public Certificate (Private key in certlocal slot 4) Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym> Key Size: 1024 Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

6. Richten Sie auf den Systemen eine Vertrauensstellung für die beide Zertifikate ein.

   Ändern Sie die Datei /etc/inet/ike/config so, dass die Zertifikate erkannt werden.

   Der Administrator des remoten Systems stellt die Werte für die Parameter cert_trust, remote_addr und remote_id zur Verfügung.

   1. Auf dem System partym enthält die ike/config-Datei Folgendes:

      # Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert # Verified remote address and remote ID # Verified public key hash per telephone call from administrator cert_trust "192.168.13.213" Local system's certificate Subject Alt Name cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name ## Parameters that may also show up in rules. p1_xform { auth_method preshared oakley_group 5 auth_alg sha encr_alg des } p2_pfs 5 { label "US-partym to JA-enigmax" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

   2. Geben Sie auf dem System enigma die enigma-Werte für lokale Parameter in die Datei ike/config ein.

      Für die remoten Parameter verwenden Sie partym-Werte. Achten Sie darauf, dass der Wert für das Schlüsselwort label einmalig ist. Der Wert muss sich von dem label-Wert des remoten Systems unterscheiden.

      … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 …

Beispiel 23–4 Prüfen Sie, ob das Zertifikat vom anderen Administrator gültig ist

In diesem Beispiel verwenden die Administratoren den „Subject Name“ um sicherzustellen, dass die Zertifikate identisch sind.

Der erste Administrator speichert die Ausgabe des Erzeugens und Auflistens des Zertifikats in einer Datei. Da die Ausgabe des ikecert-Befehls in den Standardfehler druckt, leitet der Administrator den Standardfehler an die Datei um.

sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

Der Administrator überprüft den Inhalt der Datei.

sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Dann sendet der Administrator die Datei in einer E-Mail an den zweiten Administrator.

Der zweite Administrator fügt die Datei in ein sicheres Verzeichnis ein und importiert dann das Zertifikat aus der Datei.

sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

Der Befehl ikecert importiert nur den Text zwischen den Zeilen -----BEGIN und -----END. Der Administrator überprüft, ob das lokale Zertifikat den gleichen öffentlichen Key-Hash wie in der Datei co2sys aufweist.

sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

Um sicherzustellen, dass der erste Administrator diese E-Mail gesendet hat, telefoniert der zweite Administrator, um die Richtigkeit des „Subject Name“ des Zertifikats zu bestätigen.

Beispiel 23–5 Einrichten von Anfangs- und Enddatum für die Gültigkeit eines Zertifikats

In diesem Beispiel gibt der Administrator des Systems partym vor, wie lange ein Zertifikat gültig ist. Das Zertifikat ist um 2 1/2 Tage zurückdatiert und gilt für vier Jahre und sechs Monate ab dem Erstellungsdatum.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

Der Administrator des Systems enigma gibt die Daten an, innerhalb denen das Zertifikat gültig ist. Das Zertifikat wurde um zwei Tage zurückdatiert und gilt bis Mitternacht am 31. Dezember 2010.

# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden

Öffentliche Zertifikate einer Zertifikatsautorität (CA) machen eine Aushandlung mit einer außenstehenden Organisation erforderlich. Diese Zertifikate können leicht skaliert werden, so dass zahlreiche miteinander kommunizierende Systeme geschützt werden können.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Geben Sie den Befehl ikecert certlocal -kc ein, um ein Zertifikat anzufordern.

   Eine Beschreibung der Argumente dieses Befehls finden Sie in Schritt 2 unter So konfigurieren Sie IKE mit selbst-signierten PublicKey-Zertifikaten.

   # ikecert certlocal -kc -m keysize -t keytype \ -D dname -A altname

   1. Der folgende Befehl erstellt eine Zertifikat-Anforderung auf dem System partym:

      # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \ > -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym" Creating software private keys. Writing private key to file /etc/inet/secret/ike.privatekeys/2. Enabling external key providers - done. Certificate Request: Proceeding with the signing operation. Certificate request generated successfully (…/publickeys/0) Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w … lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X -----END CERTIFICATE REQUEST-----

   2. Der folgende Befehl erstellt eine Zertifikat-Anforderung auf dem System enigma:

      # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \ > -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax" Creating software private keys. … Finished successfully. -----BEGIN CERTIFICATE REQUEST----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … 8qlqdjaStLGfhDOO -----END CERTIFICATE REQUEST-----

3. Übermitteln Sie die Zertifikat-Anforderung an eine PKI-Organisation.

   Die PKI-Organisation teilt Ihnen mit, wie die Zertifikat-Anforderung übermittelt werden soll. Die meisten Organisationen verfügen über eine Website mit einem Übertragungsformular. Das Formular fordert einen Beweis, dass die Übertragung legitim ist. In der Regel fügen Sie Ihre Zertifikat-Anforderung in das Formular ein. Nachdem Ihre Anforderung von der Organisation überprüft wurde, stellt sie die folgenden zwei Zertifikatsobjekte sowie eine Liste zurückgenommenen Zertifikate aus:

   • Ihr PublicKey-Zertifikat – Dieses Zertifikat basiert auf der Anforderung, die Sie an die Organisation übermittelt haben. Die von Ihnen übermittelte Anforderung ist Teil dieses PublicKey-Zertifikats. Das Zertifikat identifiziert Sie eindeutig.

   • Eine Zertifikatsautorität – Die Signatur der Organisation. Die CA prüft, ob Ihr PublicKey-Zertifikat echt und unverfälscht ist.

   • Eine Zertifikat-Rücknahmeliste (Certificate Revocation List, CRL) – Die aktuelle Liste der Zertifikate, die von der Organisation zurückgenommen wurden. Die CRL wird nicht separat als ein Zertifikatsobjekt gesendet, wenn der Zugriff auf die CRL in das PublicKey-Zertifikat eingebettet ist.

     Ist ein URI für die CRL in das PublicKey-Zertifikat eingebettet, kann IKE die CRL automatisch für Sie abrufen. Entsprechend gilt, ist ein DN-Eintrag (Verzeichnisname auf einem LDAP-Server) in das PublicKey-Zertifikat eingebettet, kann IKE die CRL vom angegebenen LDAP-Server abrufen und zwischenspeichern.

     Ein Beispiel eines eingebetteten URI und eines eingebetteten DN-Eintrags in einem PublicKey-Zertifikat finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

4. Fügen Sie Ihrem System alle Zertifikate hinzu.

   Mit der Option -a des Befehls ikecert certdb -a fügen Sie das eingefügte Objekt der entsprechenden Zertifikatdatenbank Ihres Systems hinzu. Weitere Informationen finden Sie unter IKE mit PublicKey-Zertifikaten.

   1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   2. Fügen Sie das PublicKey-Zertifikat hinzu, das Sie von der PKI -Organisation empfangen haben.

      # ikecert certdb -a Press the Return key Paste the certificate: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   3. Fügen Sie die CA von der PKI-Organisation hinzu.

      # ikecert certdb -a Press the Return key Paste the CA: -----BEGIN X509 CERTIFICATE----- … -----END X509 CERTIFICATE---- Press the Return key <Control>-D

   4. Wenn die PKI-Organisation eine Liste der zurückgenommenen Zertifikate gesendet hat, fügen Sie die CRL zur certrldb-Datenbank hinzu:

      # ikecert certrldb -a Press the Return key Paste the CRL: -----BEGIN CRL----- … -----END CRL---- Press the Return key <Control>-D

5. Geben Sie das Schlüsselwort cert_root ein, um die PKI-Organisation in der Datei /etc/inet/ike/config zu identifizieren.

   Verwenden Sie den von der PKI-Organisation angegebenen Namen.

   1. Die Datei ike/config auf dem System partym könnte wie folgt aussehen:

      # Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" ## Parameters that may also show up in rules. p1_xform { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des } p2_pfs 2 { label "US-partym to JA-enigmax - Example PKI" local_id_type dn local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" local_addr 192.168.13.213 remote_addr 192.168.116.16 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

      ---

      Hinweis –

      Alle Argumente für den Parameter auth_method müssen sich auf der gleichen Zeile befinden.

      ---

   2. Erstellen Sie eine ähnliche Datei auf dem System enigma.

      Beachten Sie bei der Datei enigma ike/config Folgendes:

      • Fügen Sie den gleichen cert_root-Wert hinzu.

      • Verwenden Sie enigma-Werte für lokale Parameter.

      • Verwenden Sie partym-Werte für remote Parameter.

      • Erstellen Sie einen einmaligen Wert für das Schlüsselwort label. Der Wert muss sich von dem label-Wert des remoten Systems unterscheiden.

      … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 …

6. Weisen Sie IKE an, wie die CRLs verarbeitet werden sollen.

   Wählen Sie die geeignete Option:

   • Keine CRL verfügbar

     Wenn die PKI-Organisation keine CRL zur Verfügung stellt, fügen Sie das Schlüsselwort ignore_crls zur ike/config -Datei hinzu.

     # Trusted root cert … cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,… ignore_crls …

     Das Schlüsselwort ignore_crls weist IKE an, nicht nach CRLs zu suchen.

   • CRL verfügbar

     Wenn die PKI-Organisation einen zentralen Verteilungspunkt für CRLs bereitstellt, können Sie in der Datei ike/config auf diesen Speicherort verweisen.

     Beispiele finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

Beispiel 23–6 Verwenden von rsa_encrypt bei der Konfiguration von IKE

Wenn Sie auth_method rsa_encrypt in der ike/config-Datei angeben, müssen Sie das Zertifikat des Peers zur publickeys-Datenbank hinzufügen.

1. Senden Sie das Zertifikat an den Administrator des remoten Systems.

   Sie können das Zertifikat in eine E-Mail einfügen.

   Der Administrator von partym sendet Ihnen die folgende E-Mail:

   To: admin@ja.enigmaexample.com From: admin@us.partyexample.com Message: -----BEGIN X509 CERTIFICATE----- MII… ----END X509 CERTIFICATE-----

   Der Administrator von enigma sendet die folgende E-Mail:

   To: admin@us.partyexample.com From: admin@ja.enigmaexample.com Message: -----BEGIN X509 CERTIFICATE----- MII … -----END X509 CERTIFICATE-----

2. Fügen Sie das per E-Mail gesendete Zertifikat auf beiden Systemen zur lokalen publickeys-Datenbank hinzu.

   # ikecert certdb -a Press the Return key -----BEGIN X509 CERTIFICATE----- MII… -----END X509 CERTIFICATE----- Press the Return key <Control>-D

Die Authentifizierungsmethode für die RSA-Verschlüsselung verbirgt Identitäten in IKE vor möglichen Lauschangriffen. Da die rsa_encrypt-Methode die Identität des Peers verbirgt, kann IKE das Zertifikat des Peers nicht abrufen. Aus diesem Grund erfordert die rsa_encrypt-Methode, dass die IKE-Peers die PublicKeys des jeweils anderen Systems kennen.

Wenn Sie den auth_method rsa_encrypt in der /etc/inet/ike/config-Datei angeben, müssen Sie das Zertifikat des Peers zur publickeys-Datenbank hinzufügen. Die publickeys-Datenbank enthält dann drei Zertifikate für jedes kommunizierenden Systempaar:

• Ihr PublicKey-Zertifikat

• Das CA-Zertifikat

• Das PublicKey-Zertifikat des Peer

Fehlerbehebung – Die IKE-Nutzlast, zu der auch die drei Zertifikate gehören, könnte zu groß werden, so dass eine Verschlüsselung durch rsa_encrypt nicht mehr möglich ist. Fehlermeldungen wie „Autorisierung fehlgeschlagen“ und „Fehlerhafte Nutzlast“ deuten darauf hin, dass die rsa_encrypt-Methode nicht die gesamte Nutzlast verschlüsseln konnte. Reduzieren Sie die Nutzlastgröße mit einer Methode wie z. B. rsa_sig, die nur zwei Zertifikate erfordert.

So erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware

Das Erzeugen von PublicKey-Zertifikaten und das Speichern dieser Zertifikate auf angehängter Hardware ähnelt dem Erzeugen von PublicKey-Zertifikaten und dem Speichern dieser Zertifikate auf Ihrem System. Auf der Hardware müssen die Befehle ikecert certlocal und ikecert certdb die Hardware identifizieren. Die Option -T mit der Token-ID identifiziert die Hardware gegenüber den Befehlen.

Bevor Sie beginnen

• Die Hardware muss konfiguriert sein.

• Die Hardware verwendet die /usr/lib/libpkcs11.so-Bibliothek, es sei denn, das Schlüsselwort pkcs11_path in der /etc/inet/ike/config-Datei verweist auf eine andere Bibliothek. Die Bibliothek muss gemäß dem folgenden Standard implementiert sein: RSA Security Inc. PKCS&;#11 Cryptographic Token Interface (Cryptoki), das heißt, eine PKCS&;#11-Bibliothek.

  Informationen zum Setup finden Sie unter So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 4000-Board.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Erzeugen Sie ein selbst-signiertes Zertifikat oder eine Zertifikat-Anforderung, und geben Sie die Token-ID an.

   Wählen Sie eine der folgenden Optionen:

   ---

   Hinweis –

   Für RSA unterstützt das Sun Crypto Accelerator 4000-Board Schlüssel bis zu 2048 Bit. Für DSA unterstützt dieses Board Schlüssel bis zu 1024 Bit.

   ---

   • Bei einem selbst-signiertem Zertifikate verwenden Sie die folgende Syntax.

     # ikecert certlocal -ks -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

     Das Argument für die Option -T ist die Token-ID des angehängten Sun Crypto Accelerator 4000-Boards.

   • Bei einer Zertifikat-Anforderung verwenden Sie die folgende Syntax.

     # ikecert certlocal -kc -m 1024 -t rsa-md5 \ > -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \ > -a -T dca0-accel-stor IP=192.168.116.16 Creating hardware private keys. Enter PIN for PKCS#11 token: Type user:password

   Eine Beschreibung der Argumente für den Befehl ikecert finden Sie in der Manpage ikecert(1M).

3. Geben Sie an der Eingabeaufforderung für eine PIN den Sun Crypto Accelerator 4000-Benutzer, einen Doppelpunkt und das Passwort des Benutzers ein.

   Hat das Sun Crypto Accelerator 4000-Board beispielsweise den Benutzer ikemgr, dessen Passwort rgm4tigt lautet, geben Sie Folgendes ein:

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt

   ---

   Hinweis –

   Die PIN-Antwort wird auf dem Datenträger als Reintext gespeichert.

   ---

   Nachdem Sie das Passwort eingegeben haben, druckt das Zertifikat Folgendes:

   Enter PIN for PKCS#11 token: ikemgr:rgm4tigt -----BEGIN X509 CERTIFICATE----- MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu … oKUDBbZ9O/pLWYGr -----END X509 CERTIFICATE-----

4. Senden Sie Ihr Zertifikat an die andere Partei.

   Wählen Sie eine der folgenden Optionen:

   • Senden Sie das selbst-signierte Zertifikat an das remote System.

     Sie können das Zertifikat in eine E-Mail einfügen.

   • Senden Sie die Zertifikat-Anforderung an eine Organisation, die PKI verarbeitet.

     Folgen Sie den Anweisungen der PKI-Organisation zur Übermittlung der Zertifikat-Anforderung. Ausführliche Anweisungen finden Sie in Schritt 3 unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden.

5. Ändern Sie auf Ihrem System die Datei /etc/inet/ike/config, so dass die Zertifikate erkannt werden.

   Wählen Sie eine der folgenden Optionen.

   • Selbst-signiertes Zertifikat

     Verwenden Sie die vom Administrator des remoten Systems bereitgestellten Werte für die Parameter cert_trust, remote_id und remote_addr. Auf dem System enigma enthält die ike/config-Datei Folgendes:

     # Explicitly trust the following self-signed certs # Use the Subject Alternate Name to identify the cert cert_trust "192.168.116.16" Local system's certificate Subject Alt Name cert_trust "192.168.13.213" Remote system's certificate Subject Alt name # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

   • Zertifikat-Anforderung

     Geben Sie den von der PKI-Organisation bereitgestellten Namen als Wert für das Schlüsselwort cert_root ein. Die Datei ike/config könnte auf dem System enigma wie folgt aussehen:

     # Trusted root cert # This certificate is from Example PKI # This is the X.509 distinguished name for the CA that it issues. cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI" # Solaris 10 1/06 release: default path does not have to be typed in #pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection # Solaris 10 release: use this path #pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so" … { label "JA-enigmax to US-partym - Example PKI" local_id_type dn local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" local_addr 192.168.116.16 remote_addr 192.168.13.213 p1_xform {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes} }

6. Speichern Sie die Zertifikate der anderen Partei auf der angehängten Hardware.

   Antworten Sie auf die PIN-Anforderung, wie Sie in Schritt 3 geantwortet haben.

   ---

   Hinweis –

   Sie müssen die PublicKey-Zertifikate auf der angehängten Hardware speichern, die Ihren PrivateKey erstellt hat.

   ---

   • Selbst-signiertes Zertifikat.

     Fügen Sie das selbst-signierte Zertifikat des remoten Systems hinzu. In diesem Beispiel wird das Zertifikat in der Datei DCA.ACCEL.STOR.CERT gespeichert.

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     Wenn das selbst-signierte Zertifikat rsa_encrypt als Wert für den Parameter auth_method verwendet, fügen Sie das Zertifikat des Peers zum Hardwarespeicher hinzu.

   • Zertifikate von einer PKI-Organisation.

     Fügen Sie die von der Organisation als Antwort auf Ihre Zertifikate-Anforderung erzeugten Zertifikate und die Zertifikatsautorität (CA) hinzu.

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT Enter PIN for PKCS#11 token: Type user:password

     # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT Enter PIN for PKCS#11 token: Type user:password

     Informationen zum Hinzufügen der Zertifikat-Rücknahmeliste (CRL) von der PKI-Organisation finden Sie unter So verarbeiten Sie eine Zertifikat-Rücknahmeliste.

So verarbeiten Sie eine Zertifikat-Rücknahmeliste

Eine Zertifikat-Rücknahmeliste (Certificate Revocation List, CRL) enthält veraltete und sicherheitsgefährdete Zertifikate einer Zertifikatsautorität. Es gibt vier Möglichkeiten, CRLs zu verarbeiten.

• Sie müssen IKE anweisen, CRLs zu ignorieren, wenn Ihre CA-Organisation keine CRLs ausgibt. Diese Option wird in Schritt 6 unter So konfigurieren Sie IKE mit Zertifikaten, die von einer CA signiert wurden gezeigt.

• Sie können IKE anweisen, über einen URI (Uniform Resource Indicator), dessen Adresse in das PublicKey-Zertifikat von der CA eingebettet ist, auf die CRLs zugreifen.

• Sie können IKE anweisen, über einen LDAP-Server, dessen DN-Eintrag (Verzeichnisname) in das PublicKey-Zertifikat von der CA eingebettet ist, auf die CRLs zugreifen.

• Sie können die CRL als ein Argument für den Befehl ikecert certrldb angeben. Siehe Beispiel 23–7.

Im folgenden Verfahren wird beschrieben, wie Sie IKE anweisen, CRLs von einem zentralen Verteilungspunkt aus zu verwenden.

1. Zeigen Sie die von der CA empfangenen Zertifikate an.

   # ikecert certdb -lv certspec

   -l

   Listet die Zertifikate in der IKE-Zertifikatsdatenbank auf.

   -v

   Listet die Zertifikate im ausführlichen Modus auf. Verwenden Sie diese Option nur nach sorgfältigen Überlegungen.

   certspec

   Ein Muster, das Entsprechungen für ein Zertifikat in der IKE-Zertifikatsdatenbank findet.

   Das folgende Zertifikat wurde beispielsweise von Sun Microsystems herausgegeben. Bestimmte Einzelheiten wurden geändert.

   # ikecert certdb -lv example-protect.sun.com Certificate Slot Name: 0 Type: dsa-sha1 (Private key in certlocal slot 0) Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com> Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> SerialNumber: 14000D93 Validity: Not Valid Before: 2002 Jul 19th, 21:11:11 GMT Not Valid After: 2005 Jul 18th, 21:11:11 GMT Public Key Info: Public Modulus (n) (2048 bits): C575A…A5 Public Exponent (e) ( 24 bits): 010001 Extensions: Subject Alternative Names: DNS = example-protect.sun.com Key Usage: DigitalSignature KeyEncipherment [CRITICAL] CRL Distribution Points: Full Name: URI = #Ihttp://www.sun.com/pki/pkismica.crl#i DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc> CRL Issuer: Authority Key ID: Key ID: 4F … 6B SubjectKeyID: A5 … FD Certificate Policies Authority Information Access

   Beachten Sie den Eintrag CRL Distribution Points. Der URI-Eintrag kennzeichnet, dass die CRL dieser Organisation im Web verfügbar ist. Der DN-Eintrag gibt an, dass die CRL auf einem LDAP-Server zur Verfügung steht. Nachdem IKE einmal auf die CRL zugegriffen hat, wird sie zur weiteren Verwendung zwischengespeichert.

   Um auf die CRL zuzugreifen, müssen Sie einen Verteilungspunkt erreichen.

2. Wählen Sie eine der folgenden Methoden, um auf die CRL an einem zentralen Verteilungspunkt zuzugreifen.

   • Mithilfe des URI.

     Fügen Sie das Schlüsselwort use_http zur Datei /etc/inet/ike/config des Hosts hinzu. Die Datei ike/config ähnelt dann Folgendem:

     # Use CRL from organization's URI use_http …

   • Mithilfe eines Web-Proxy.

     Fügen Sie das Schlüsselwort proxy zur ike/config-Datei hinzu. Das Schlüsselwort proxy akzeptiert eine URL als Argument, wie in dem folgenden Beispiel:

     # Use own web proxy proxy "http://proxy1:8080"

   • Mithilfe eines LDAP-Servers.

     Geben Sie den LDAP-Server als Argument für das Schlüsselwort ldap-list in die /etc/inet/ike/config-Datei des Hosts ein. Ihre Organisation stellt den Namen des LDAP-Servers zur Verfügung. Der Eintrag in der ike/config-Datei würde Folgendem ähneln:

     # Use CRL from organization's LDAP ldap-list "ldap1.sun.com:389,ldap2.sun.com" …

   IKE ruft die CRL ab und speichert die CRL zwischen, bis das Zertifikat abgelaufen ist.

Beispiel 23–7 Einfügen einer CRL in die lokale certrldb-Datenbank

Wenn die CRL einer PKI-Organisation nicht an einem zentralen Verteilungspunkt zur Verfügung steht, können Sie die CRL der zur lokalen certrldb-Datenbank manuell hinzufügen. Folgen Sie den Anweisungen der PKI-Organisation zum Extrahieren der CRL in eine Datei, dann fügen Sie die CRL mit dem Befehl ikecert certrldb -a zur Datenbank hinzu.

# ikecert certrldb -a < Sun.Cert.CRL

Konfiguration von IKE für mobile Systeme (Übersicht der Schritte)

Die folgende Tabelle enthält Verweise auf Verfahren, in denen beschrieben wird, wie IKE so konfiguriert wird, dass Systeme verarbeitet werden können, die sich remote bei einem zentralen Standort anmelden.

Konfiguration von IKE für mobile Systeme

Wenn Heimbüros und mobile Laptops ordnungsgemäß konfiguriert wurden, können IPsec und IKE die Kommunikation mit den Computern am Unternehmenssitz schützen. Eine umfassende IPsec-Richtlinie, kombiniert mit einer PublicKey-Authentifizierungsmethode, bietet Offsite-Systemen die Möglichkeit, ihren Datenverkehr mit einem zentralen System zu schützen.

So konfigurieren Sie IKE für Offsite-Systeme

IPsec und IKE erfordern eine einmalige ID, um Quelle und Ziel eindeutig identifizieren zu können. Bei offsite oder mobilen Systemen, die nicht über eine einmalige IP-Adresse verfügen, müssen Sie einen anderen ID-Typ verwenden. Beispielsweise kann ein System eindeutig mit ID-Typen wie DNS, DN oder E-Mail identifiziert werden.

Offsite oder mobile Systeme, die über einmalige IP-Adressen verfügen, werden dennoch besser mit einem anderen ID-Typ konfiguriert. Wenn die Systeme z. B. versuchen, über eine NAT-Box eine Verbindung mit einem zentralen Standort herzustellen, werden deren einmalige Adressen nicht verwendet. Eine NAT-Box weist eine zufällige IP-Adresse zu, die das zentrale System nicht erkennen würde.

PresharedKeys können ebenfalls nicht als Authentifizierungsmechanismus für mobile Systeme eingesetzt werden, da sie feststehende IP-Adressen benötigen. Selbst-signierte Zertifikate oder Zertifikate von einer PKI ermöglichen mobilen Systemen jedoch die Kommunikation mit einem zentralen Standort.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Konfigurieren Sie das zentrale System, so dass es mobile Systeme erkennt.

   1. Richten Sie die /etc/hosts-Datei ein.

      Das zentrale System muss bestimmte Adressen für mobile Systeme nicht erkennen.

      # /etc/hosts on central central 192.xxx.xxx.x

   2. Richten Sie die ipsecinit.conf-Datei ein.

      Das zentrale System benötigt eine Richtlinie, die einen breiten Bereich an IP-Adressen zulässt. Später stellen Zertifikate in der IKE-Richtlinie sicher, dass Systeme, die eine Verbindung herzustellen versuchen, hierzu berechtigt sind.

      # /etc/inet/ipsecinit.conf on central # Keep everyone out unless they use this IPsec policy: {} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Richten Sie die ike.config-Datei ein.

      DNS identifiziert das zentrale System. Zur Authentifizierung des Systems werden Zertifikate verwendet.

      ## /etc/inet/ike/ike.config on central # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # List self-signed certificates - trust server and enumerated others #cert_trust "DNS=central.domain.org" #cert_trust "DNS=mobile.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=root@central.domain.org" #cert_trust "email=user1@mobile.domain.org" # # Rule for mobile systems with certificate { label "Mobile systems with certificate" local_id_type DNS # Any mobile system who knows my DNS or IP can find me. local_id "central.domain.org" local_addr 192.xxx.xxx.x # Root certificate ensures trust, # so allow any remote_id and any remote IP address. remote_id "" remote_addr 0.0.0.0/0 p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } }

3. Melden Sie sich bei jedem mobilen System an und konfigurieren Sie das System so, dass es das zentrale System findet.

   1. Richten Sie die /etc/hosts-Datei ein.

      Die /etc/hosts-Datei benötigt keine Adresse für das mobile System, kann aber eine bereitstellen. Die Datei muss eine öffentliche IP-Adresse für das zentrale System enthalten.

      # /etc/hosts on mobile mobile 10.x.x.xx central 192.xxx.xxx.x

   2. Richten Sie die ipsecinit.conf-Datei ein.

      Das mobile System muss das zentrale System über die öffentliche IP-Adresse finden können. Die Systeme müssen mit der gleichen IPsec-Richtlinie konfiguriert sein.

      # /etc/inet/ipsecinit.conf on mobile # Find central {raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

   3. Richten Sie die ike.config-Datei ein.

      Als Bezeichner darf keine IP-Adresse verwendet werden. Für mobile Systeme sind die folgenden Bezeichner gültig:

      • DN=ldap-Verzeichnisname

      • DNS=Adresse-des-Domänennamenservers

      • email=E-Mail-Adresse

      Zur Authentifizierung des mobilen Systems werden Zertifikate verwendet.

      ## /etc/inet/ike/ike.config on mobile # Global parameters # # Find CRLs by URI, URL, or LDAP # Use CRL from organization's URI use_http # # Use web proxy proxy "http://somecache.domain:port/" # # Use LDAP server ldap_server "ldap-server1.domain.org,ldap2.domain.org:port" # # List CA-signed certificates cert_root "C=US, O=Domain Org, CN=Domain STATE" # # Self-signed certificates - trust me and enumerated others #cert_trust "DNS=mobile.domain.org" #cert_trust "DNS=central.domain.org" #cert_trust "DN=CN=Domain Org STATE (CLASS), O=Domain Org #cert_trust "email=user1@domain.org" #cert_trust "email=root@central.domain.org" # # Rule for off-site systems with root certificate { label "Off-site mobile with certificate" local_id_type DNS # NAT-T can translate local_addr into any public IP address # central knows me by my DNS local_id "mobile.domain.org" local_addr 0.0.0.0/0 # Find central and trust the root certificate remote_id "central.domain.org" remote_addr 192.xxx.xxx.x p2_pfs 5 p1_xform {auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 } }

4. Lesen Sie die IKE-Konfiguration in den Systemkern ein.

   • Wenn Sie mit mindestens Solaris 10 4/09 arbeiten, aktivieren Sie den ike-Service.

     # svcadm enable svc:/network/ipsec/ike

   • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, muss das System neu gestartet werden.

     # init 6

     Alternativ stoppen und starten Sie den in.iked-Daemon.

Beispiel 23–8 Konfiguration eines zentralen Computers zum Akzeptieren von IPsec-Verkehr von einem mobilen System

IKE kann Aushandlungen hinter einer NAT-Box initiieren. Das ideale Setup für IKE sieht jedoch keine zwischengeschaltete NAT-Box vor. Im folgenden Beispiel wurden die Root-Zertifikate von einer CA ausgegeben und auf dem mobilen und dem zentralen System eingepflegt. Ein zentrales System akzeptiert IPsec-Aushandlungen von einem System hinter einer NAT-Box. main1 ist ein Unternehmenssystem, das Verbindungen von Offsite-Systemen akzeptiert. Informationen zum Einrichten von Offsite-Systemen finden Sie in Beispiel 23–9.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}

Beispiel 23–9 Konfiguration eines Systems hinter einer NAT-Box mit IPsec

Im folgenden Beispiel wurden die Root-Zertifikate von einer CA ausgegeben und auf dem mobilen sowie auf dem zentralen System eingepflegt. mobile1 stellt von zu Hause aus eine Verbindung mit dem Unternehmenshauptsitz her. Das Internet Service-Providers (ISP)-Netzwerk verwendet eine NAT-Box, damit der ISP mobile1 eine private Adresse zuordnen kann. Die NAT-Box übersetzt die private Adresse dann in eine öffentliche IP-Adresse, die gemeinsam mit anderen ISP-Netzwerkknoten genutzt wird. Das Hauptbüro des Unternehmens befindet sich nicht hinter einer NAT-Box. Informationen zur Einrichtung des Computers in der Unternehmenszentrale finden Sie unter Beispiel 23–8.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Beispiel 23–10 Akzeptieren selbst-signierter Zertifikate von einem mobilen System

Im folgenden Beispiel wurden selbst-signierte Zertifikate ausgegeben, die sich auf dem mobilen und auf dem zentralen System befinden. main1 ist ein Unternehmenssystem, das Verbindungen von Offsite-Systemen akzeptiert. Wie Sie die Offsite-Systeme einrichten, erfahren Sie in Beispiel 23–11.

## /etc/hosts on main1
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Beispiel 23–11 Verwenden von selbst-signierten Zertifikaten zum Aufnehmen einer Verbindung mit einem zentralen System

Im folgenden Beispiel versucht mobile1, eine Verbindung von zu Hause aus mit dem Hauptbüro des Unternehmens herzustellen. Die Zertifikate wurden ausgegeben und befinden sich auf dem mobilen und auf dem zentralen System. Das ISP-Netzwerk verwendet eine NAT-Box, damit der ISP mobile1 eine private Adresse zuordnen kann. Die NAT-Box übersetzt die private Adresse dann in eine öffentliche IP-Adresse, die gemeinsam mit anderen ISP-Netzwerkknoten genutzt wird. Das Hauptbüro des Unternehmens befindet sich nicht hinter einer NAT-Box. Informationen zum Einrichten der Computer am Unternehmenshauptsitz finden Sie in Beispiel 23–10.

## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

Konfiguration von IKE zum Suchen angehängter Hardware (Übersicht der Schritte)

In der folgenden Tabelle wird auf Verfahren verwiesen, in denen beschrieben wird, wie IKE über angehängte Hardware informiert wird. IKE muss über angehängte Hardware informiert sein, bevor IKE die Hardware verwenden kann. Um die Hardware zu verwenden, folgen Sie den Hardware-Verfahren unter Konfiguration von IKE mit PublicKey-Zertifikaten.

Sie müssen IKE nicht über On-Chip-Hardware informieren. Der UltraSPARC® T2-Prozessor beinhaltet beispielsweise kryptografische Beschleunigung. Sie müssen IKE nicht konfigurieren, damit die On-Chip-Accelerators gefunden werden.

Konfiguration von IKE zum Suchen angehängter Hardware

Public Key-Zertifikate können auch auf angehängter Hardware gespeichert werden. Das Sun Crypto Accelerator 1000-Board stellt nur Speicherkapazität zur Verfügung. Das Sun Crypto Accelerator 4000- und Sun Crypto Accelerator 6000-Board bietet Speicherkapazität und ermöglicht das Abgeben von Public Key-Vorgängen vom System auf das Board.

So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 1000-Board

Bevor Sie beginnen

Bei dem folgenden Verfahren wird davon ausgegangen, dass ein Sun Crypto Accelerator 1000-Board an das System angehängt ist. Außerdem muss die Software für das Board installiert und konfiguriert sein. Anweisungen finden Sie im Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Prüfen Sie, ob die PKCS&;#11-Bibliothek verlinkt ist.

   Geben Sie den folgenden Befehl ein, um festzustellen, ob eine PKCS&;#11-Bibliothek verlinkt ist:

   # ikeadm get stats Phase 1 SA counts: Current: initiator: 0 responder: 0 Total: initiator: 0 responder: 0 Attempted: initiator: 0 responder: 0 Failed: initiator: 0 responder: 0 initiator fails include 0 time-out(s) PKCS#11 library linked in from /usr/lib/libpkcs11.so #

3. Solaris 10 1/06: Ab diesem Release können Sie Schlüssel im Softtoken-Schlüsselspeicher speichern.

   Informationen zum Schlüsselspeicher, der über das Solaris Cryptographic Framework bereitgestellt wird, finden Sie in der Manpage cryptoadm(1M) Ein Beispiel zur Verwendung des Schlüsselspeichers finden Sie in Example 23–12.

So konfigurieren Sie IKE zur Suche nach dem Sun Crypto Accelerator 4000-Board

Bevor Sie beginnen

Bei dem folgenden Verfahren wird davon ausgegangen, dass ein Sun Crypto Accelerator 4000-Board an das System angehängt ist. Außerdem muss die Software für das Board installiert und konfiguriert sein. Anweisungen finden Sie im Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide.

Falls Sie ein Sun Crypto Accelerator 6000-Board verwenden, lesen Sie den Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide , um Anweisungen zu erhalten.

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Prüfen Sie, ob die PKCS&;#11-Bibliothek verlinkt ist.

   IKE verarbeitet die Schlüsselerzeugung und -speicherung auf dem Sun Crypto Accelerator 4000-Board mithilfe der Programmroutinen der Bibliothek. Geben Sie den folgenden Befehl ein, um festzustellen, ob eine PKCS&;#11-Bibliothek verlinkt ist:

   $ ikeadm get stats … PKCS#11 library linked in from /usr/lib/libpkcs11.so $

   ---

   Hinweis –

   Für RSA unterstützt das Sun Crypto Accelerator 4000-Board Schlüssel bis zu 2048 Bit. Für DSA unterstützt dieses Board Schlüssel bis zu 1024 Bit.

   ---

3. Suchen Sie die Token-ID für das angehängte Sun Crypto Accelerator 4000-Board.

   $ ikecert tokens Available tokens with library "/usr/lib/libpkcs11.so": "Sun Metaslot "

   Die Bibliothek gibt eine Token-ID mit 32 Zeichen zurück. Die Token-ID wird auch als Schlüsselspeichername bezeichnet. In diesem Beispiel können Sie das Token Sun Metaslot mit den ikecert-Befehlen zum Speichern und Beschleunigen der IKE-Schlüssel verwenden.

   Anweisungen zum Arbeiten mit dem Token finden Sie unter So erzeugen Sie PublicKey-Zertifikate und speichern sie auf angehängter Hardware.

   Die einführenden Leerzeichen werden von dem Befehl ikecert automatisch aufgefüllt.

Beispiel 23–12 Suchen und Verwenden von Metaslot-Token

Token können auf einem Datenträger, auf einem angehängten Board oder im Softtoken-Schlüsselspeicher des Solaris Encryption Framework gespeichert werden. Die Token-ID des Softtoken-Schlüsselspeichers könnte wie folgt aussehen:

$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

Informationen zum Erstellen eines Passwortsatzes für den Softtoken-Schlüsselspeicher finden Sie in der Manpage pktool(1).

Mit einem Befehl ähnlich dem Folgenden fügen Sie das Zertifikat zum Softtoken-Schlüsselspeicher hinzu. Sun.Metaslot.cert ist eine Datei mit dem CA-Zertifikat.

# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

Ändern der IKE-Übertragungsparameter (Übersicht der Schritte)

In der folgenden Tabelle wird auf Verfahren zur Konfiguration der Übertragungsparameter verwiesen.

Ändern der IKE-Übertragungsparameter

Wenn IKE Schlüssel aushandelt, wirkt sich die Übertragungsgeschwindigkeit auf den Erfolg der Aushandlung aus. Normalerweise müssen Sie die Standardwerte für die IKE-Übertragungsparameter nicht ändern. Eventuell müssen die Übertragungswerte jedoch geändert werden, um die Schlüsselaushandlung bei extrem frequentierten Leitungen zu optimieren oder um ein Problem zu reproduzieren.

Bei einer längeren Aushandlung kann IKE die Schlüssel aus über unzuverlässige Übertragungsleitungen aushandeln. Sie verlängern bestimmte Parameter, so dass schon die ersten Versuche erfolgreich sind. Wenn der erste Versuch nicht erfolgreich ist, können Sie nachfolgenden Versuchen mehr Zeit gewähren, damit sie erfolgreich abgeschlossen werden.

Bei einer kürzeren Dauer können Sie von den Vorteilen zuverlässiger Übertragungsleitungen profitieren. Sie können schneller einen Wiederholversuch bei fehlgeschlagenen Aushandlungen einleiten, um so die Aushandlung insgesamt zu beschleunigen. Bei der Suche nach der Ursache eines Problems können Sie auch die Aushandlung beschleunigen, um schnell einen Fehler zu erzeugen. Eine kürzere Aushandlung bedeutet auch, dass die Phase 1 SAs über deren gesamte Lebendauer genutzt werden können.

So ändern Sie die Dauer der Phase 1 IKE-Schlüsselaushandlung

1. Nehmen Sie über die Systemkonsole die Rolle eines Primäradministrators an, oder melden Sie sich als Superuser an.

   Die Rolle des Primäradministrators enthält das Primary Administrator-Profil. Informationen zum Erstellen von Rollen und Zuweisen von Rollen zu Benutzern finden Sie in Kapitel 2, Working With the Solaris Management Console (Tasks) in System Administration Guide: Basic Administration.

   ---

   Hinweis –

   Eine remote Anmeldung führt zu sicherheitskritischem Datenverkehr, der abgehört werden könnte. Auch wenn Sie eine remote Anmeldung schützen, wird die Sicherheit des Systems auf die Sicherheit der remoten Anmeldesitzung reduziert. Verwenden Sie den Befehl ssh, um sich sicher remote anzumelden.

   ---

2. Ändern Sie die Standardwerte der globalen Übertragungsparameter auf jedem System.

   Ändern Sie die Phase 1 Parameter für die Aushandlungsdauer in der Datei /etc/inet/ike/config auf jedem System.

   ### ike/config file on system ## Global parameters # ## Phase 1 transform defaults # #expire_timer 300 #retry_limit 5 #retry_timer_init 0.5 (integer or float) #retry_timer_max 30 (integer or float)

   expire_timer

   Die Zeit in Sekunden, die eine noch nicht abgeschlossene IKE Phase I-Aushandlung weiter ausgeführt werden darf, bis der Aushandlungsversuch gelöscht wird. Standardmäßig werden die Versuche über 30 Sekunden ausgeführt.

   retry_limit

   Die Anzahl an wiederholten Übertragungen, bevor die IKE-Aushandlung abgebrochen wird. Standardmäßig versucht IKE fünf Übertragungen.

   retry_timer_init

   Das Erstintervall zwischen den Übertragungsversuchen. Dieses Intervall wird verdoppelt, bis der Wert von retry_timer_max erreicht ist. Das Erstintervall beträgt 0,5 Sekunden.

   retry_timer_max

   Das maximale Intervall zwischen den Übertragungsversuchen. Das Intervall für die Übertragungsversuche wächst bis zu diesem Wert an. Standardmäßig beträgt der Grenzwert 30 Sekunden.

3. Lesen Sie die geänderte Konfiguration in den Systemkern ein.

   • Wenn Sie mindestens mit Solaris 10 4/09 arbeiten, aktualisieren Sie den ike-Service.

     # svcadm refresh svc:/network/ipsec/ike

   • Wenn Sie eine ältere Version als Solaris 10 4/09 verwenden, starten Sie das System neu.

     # init 6

     Alternativ stoppen und starten Sie den in.iked-Daemon.

Beispiel 23–13 Verlängern der IKE Phase 1-Aushandlungszeiten

Im folgenden Beispiel ist ein System über eine stark frequentierte Übertragungsleitung mit seinem Peer verbunden. Die ursprünglichen Einstellungen in der Datei sind mit Kommentarzeichen versehen. Die neuen Einstellungen verlängern die Aushandlungszeit.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180

Beispiel 23–14 Verkürzen der IKE Phase 1-Aushandlungszeiten

Im folgenden Beispiel ist ein System über eine Hochgeschwindigkeitsleitung mit wenig Verkehr mit seinem Peer verbunden. Die ursprünglichen Einstellungen in der Datei sind mit Kommentarzeichen versehen. Die neuen Einstellungen verkürzen die Aushandlungszeit.

### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20