The Cable GuyDas authentifizierte Internetprotokoll

Joseph Davies

In Teilen dieses Artikels wird eine Vorabversion von Windows Server 2008 erörtert. Änderungen an diesen Einzelheiten sind vorbehalten.

Windows Vista und Windows Server 2008 (derzeit in der Betatestversion) unterstützen beide das authentifizierte Internetprotokoll (Authenticated Internet Protocol, AuthIP), eine verbesserte Version des Internetschlüsselaustausch (Internet Key Exchange, IKE)-Protokolls. Sowohl AuthIP als auch IKE sind Protokolle, die zum Festlegen von Schlüsselerstellungsmaterial und Aushandeln von Sicherheitsparametern für die geschützte Kommunikation mithilfe von

Internetprotokollsicherheit (Internet Protocol Security, IPsec) verwendet werden. AuthIP stellt vereinfachte IPSec-Richtlinienkonfiguration und -wartung in vielen Konfigurationen bereit und bietet zusätzliche Flexibilität für die IPSec-Peerauthentifizierung. In diesem Artikel werden die Protokolldetails von AuthIP und Koexistenzverhaltensweisen zwischen IPSec-Peers beschrieben, die entweder AuthIP und IKE oder nur IKE unterstützen.

Übersicht über IKE

Aushandlungsbeispiele

Um das Koexistenzverhalten zu demonstrieren, wird untersucht, was zwischen Windows Vista und Windows XP-basierenden IPSec-Peers bei dem Versuch der IPsec-Schutzaushandlung geschieht.

Beispiel 1: Zwei Windows Vista-basierte IPSec-Peers im Anforderungsmodus

In diesem Beispiel ist ein Windows Vista-basierter IPSec-Peer (Peer 1) der Initiator, und der Antwortdienst wird auf Windows Vista (Peer 2) ausgeführt. Beide Peers sind mit dem Anforderungsmodus sowohl für die eingehende als auch die ausgehende Kommunikation konfiguriert. Im Anforderungsmodus fordert ein IPSec-Peer IPSec-Schutz an, braucht ihn aber nicht. Folgende Nachrichten werden ausgetauscht:

1. Peer 1 sendet ein Klartext-TCP-Synchronisierungssegment (SYN), wodurch eine TCP-Verbindung mit Peer 2 initiiert wird.
2. Peer 2 sendet ein TCP-SYN-Bestätigungssegment (Acknowledgment, ACK).
3. Peer 1 sendet ein TCP-ACK-Segment.
4. Peer 1 sendet eine AuthIP-basierte ISAKMP-Nachricht, die die AuthIP-Hauptmodusaushandlung initiiert.
5. Peer 1 sendet eine IKE-basierte ISAKMP-Nachricht, die die IKE-Hauptmodusaushandlung initiiert.
6. Peer 2 antwortet mit einer AuthIP-basierten ISAKMP-Nachricht, womit die AuthIP-Hauptmodusaushandlung fortgesetzt wird.
7. Peer 1 und 2 schließen die AuthIP-Aushandlung im Hauptmodus, Schnellmodus und erweiterten Modus (optional) ab.
8. Nachfolgende, über die TCP-Verbindung gesendete Segmente sind durch IPSec geschützt.

Die genaue Reihenfolge der Nachrichten 1 bis 5 hängt von der Netzwerklatenz ab. Die in diesem Artikel beschriebenen Beispiele sind für ein Netzwerk mit sehr niedriger Latenz gedacht, in dem der TCP-Handshake (Nachricht 1 bis 3) abgeschlossen wird, bevor Peer 1 die anfänglichen ISAKMP-Nachrichten (Nachricht 4 und 5) senden kann. In einem Netzwerk höherer Latenz würde Peer 1 das Klartext-TCP-SYN-Segment, die AuthIP-basierte ISAKMP-Nachricht und dann die IKE-basierte ISAKMP-Nachricht als die ersten drei Nachrichten des Nachrichtenaustauschs senden.

Beispiel 2: Windows Vista-basierter IPSec-Peer im Anforderungsmodus und ein Windows XP-basierter IPSec-Peer im Anforderungsmodus

In diesem Beispiel ist ein Windows Vista-basierter IPSec-Peer (Peer 1) der Initiator, und der Antwortdienst wird auf Windows XP (Peer 2) ausgeführt. Beide Peers sind mit dem Anforderungsmodus sowohl für die eingehende als auch die ausgehende Kommunikation konfiguriert. Folgende Nachrichten werden ausgetauscht:

1. Peer 1 sendet ein Klartext-TCP-SYN-Segment, wodurch eine TCP-Verbindung mit Peer 2 initiiert wird.
2. Peer 2 sendet ein TCP-SYN-ACK-Segment.
3. Peer 1 sendet ein TCP-ACK-Segment.
4. Peer 1 sendet eine AuthIP-basierte ISAKMP-Nachricht, die die AuthIP-Hauptmodusaushandlung initiiert.
5. Peer 1 sendet eine IKE-basierte ISAKMP-Nachricht, die die IKE-Hauptmodusaushandlung initiiert.
6. Peer 2 antwortet mit einer IKE-basierten ISAKMP-Nachricht, womit die IKE-Hauptmodusaushandlung fortgesetzt wird.
7. Peer 1 und 2 schließen die IKE-Hauptmodus- und Schnellmodusaushandlung ab.
8. Nachfolgende, über die TCP-Verbindung gesendete Segmente sind durch IPSec geschützt.

Beispiel 3: Windows Vista-basierter IPSec-Peer im Anforderungsmodus und ein Windows XP-basierter IPSec-Peer im Abfragemodus

In diesem Beispiel ist ein Windows Vista-basierter IPSec-Peer (Peer 1) der Initiator, und der Antwortdienst wird auf Windows XP (Peer 2) ausgeführt. Peer 1 ist mit dem Anforderungsmodus für die ausgehende Kommunikation konfiguriert, und Peer 2 ist mit dem Abfragemodus für die eingehende Kommunikation konfiguriert. Im Abfragemodus ist für IPSec-Peer IPSec-Schutz erforderlich, und ungeschützte Pakete werden automatisch verworfen. Folgende Nachrichten werden ausgetauscht:

1. Peer 1 sendet ein Klartext-TCP-SYN-Segment, wodurch eine TCP-Verbindung initiiert wird, die von Peer 2 automatisch verworfen wird.
2. Peer 1 sendet eine AuthIP-basierte ISAKMP-Nachricht, wodurch die AuthIP-Hauptmodusaushandlung initiiert wird, die von Peer 2 automatisch verworfen wird.
3. Peer 1 sendet eine IKE-basierte ISAKMP-Nachricht, die die IKE-Hauptmodusaushandlung initiiert.
4. Peer 2 antwortet mit einer IKE-basierten ISAKMP-Nachricht, womit die IKE-Hauptmodusaushandlung fortgesetzt wird.
5. Peer 1 und Peer 2 schließen die IKE-Hauptmodus- und Schnellmodusaushandlung ab.
6. Peer 1 überträgt das TCP-SYN-Segment (mit IPSec geschützt) neu.
7. Peer 2 sendet das TCP-SYN-ACK-Segment (mit IPSec geschützt).
8. Peer 1 sendet das TCP-ACK-Segment (mit IPSec geschützt).

IKE ist ein in RFC 2409 (ietf.org/rfc/rfc2409.txt) definierter Internetstandard, der eine Methode zum Festlegen von IPSec-Sicherheitszuordnungen (Security Association, SA) definiert. Eine SA ist eine Kombination aus einer gegenseitig annehmbaren Richtlinie und Schlüsseln, durch die Sicherheitsdienste und Methoden definiert werden, die zum Schutz der Kommunikation zwischen IPSec-Peers beitragen. Speziell werden in IKE das Internet Security Association and Key Management-Protokoll (ISAKMP) in RFC 2408 und das Oakley Key Determination-Protokoll (RFC 2412) verbunden. IKE verwendet das Oakley Key Determination-Protokoll zum Generieren von geheimem Schlüsselmaterial für die geschützte Kommunikation.

IKE verwendet ISAKMP zum Aushandeln von SAs. ISAKMP umfasst Einrichtungen zum Identifizieren und Authentifizieren von Peers, zum Verwalten von SAs und zum Austauschen von Schlüsselmaterial. ISAKMP ist ein Framework zum Aushandeln geschützter Kommunikation, die unabhängig von bestimmten Schlüsselaustauschprotokollen, Verschlüsselungs- und Integritätsalgorithmen sowie Authentifizierungsmethoden ist.

IPSec-Peers verwenden IKE zum Durchführen der Hauptmodus- und Schnellmodusaushandlung. Bei der Hauptmodusaushandlung wird die ISAKMP-Sicherheitszuordnung erstellt, durch die Sicherheitsaushandlungen geschützt werden. Während der Hauptmodusaushandlung tauschen der Initiator und der Antwortdienst eine Reihe von ISAKMP-Nachrichten aus, um die Verschlüsselungs- und Hashalgorithmen für die ISAKMP-Sicherheitszuordnung auszuhandeln, Schlüsselermittlungsmaterial auszutauschen und einander zu identifizieren und authentifizieren.

In der Schnellmodusaushandlungsphase werden die beiden IPSec-Sicherheitszuordnungen erstellt (eine SA für eingehende Daten und eine andere für ausgehende Daten), wodurch die zwischen zwei IPsec-Peers gesendeten Daten geschützt werden. Während der Schnellmodusaushandlung tauschen der Initiator und der Antwortdienst eine Reihe verschlüsselter ISAKMP-Nachrichten aus, um die Verschlüsselungs- und Hashalgorithmen sowohl für die eingehenden als auch die ausgehenden IPSec-SAs auszuhandeln.

Weitere Informationen zur IKE-basierten Hauptmodus- und Schnellmodusaushandlung finden Sie unter „IKE-Aushandlung für IPsec-Sicherheitszuordnungen“ unter microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Übersicht über AuthIP

AuthIP ist eine verbesserte Version von IKE, die zusätzliche Flexibilität mit Support für die benutzerbasierte Authentifizierung, Authentifizierung mit mehreren Anmeldeinformationen, verbesserte Authentifizierungsmethodenaushandlung und asymmetrische Authentifizierung bietet. Genau wie IKE unterstützt AuthIP die Hauptmodus- und Schnellmodusaushandlung. AuthIP unterstützt auch den erweiterten Modus, ein Teil der IPSec-Peeraushandlung, in dem eine zweite Authentifizierungsrunde durchgeführt werden kann. Der (optionale) erweiterte Modus kann für mehrere Authentifizierungen verwendet werden. Mit dem erweiterten Modus können beispielsweise separate computerbasierte und benutzerbasierte Authentifizierungen durchgeführt werden.

Der mehrfache Authentifizierungssupport ist Teil der IPSec-Erzwingung für die Netzwerkzugriffsschutz-Plattform (Network Access Protection, NAP), auf der sich IPSec-Peers mit Computeranmeldeinformationen authentifizieren und darüber hinaus mit einem Integritätszertifikat nachweisen, dass sie kompatibel mit Systemintegritätsanforderungen sind. Weitere Informationen zum Netzwerkzugriffsschutz finden Sie unter microsoft.com/nap. Weitere Informationen zu den Features von AuthIP sind unter „AuthIP in Windows Vista“ unter microsoft.com/technet/community/columns/cableguy/cg0806.mspx verfügbar.

AuthIP-Nachrichten

Sowohl IKE als auch AuthIP verwenden ISAKMP als Schlüsselaustausch- und SA-Aushandlungsprotokoll. ISAKMP-Nachrichten werden über das User Datagram-Protokoll (UDP) gesendet und bestehen aus einem ISAKMP-Header und einer oder mehren ISAKMP-Nutzlasten. Der ISAKMP-Header enthält Informationen zur Nachricht einschließlich des Nachrichtentyps. Abbildung 1 zeigt das Format des ISAKMP-Headers.

Abbildung 1** Format des ISAKMP-Headers **

Im ISAKMP-Header werden das Initiatorcookie und das Antwortcookie auf eine von den IPsec-Peers ausgewählte Zufallszahl eingestellt, die nicht Null ist. Das Feld für die nächste Nutzlast zeigt die erste Nutzlast in der ISAKMP-Nachricht gleich hinter dem ISAKMP-Header an. RFC 2408 führt definierte Werte des Felds für die nächste Nutzlast auf. Die Nutzlasttypen 128–255 sind zur privaten Verwendung reserviert. Die Felder „Hauptversion“ und „Nebenversion“ zeigen die Versionen von ISAKMP auf dem IPSec-Peer an, der die ISAKMP-Nachricht sendet. Für IKE und AuthIP ist die Hauptversion 1 und die Nebenversion 0.

Das Feld „Austauschtyp“ zeigt den Typ des durchgeführten ISAKMP-Austauschs an. Der Austauschtyp diktiert die Struktur und Reihenfolge von ISAKMP-Nutzlasten. RFC 2408 definiert die Werte des Felds „Austauschtyp“. Die Austauschtypen 128–255 sind zur privaten Verwendung reserviert.

Das Feld „Flags“ enthält drei in RFC 2408 definierte Kennzeichen. Das untere Bit (Bit 0) ist das Verschlüsselungsbit, das anzeigt, dass die ISAKMP-Nutzlasten (bei Einstellung auf 1) verschlüsselt oder (bei Einstellung auf 0) nicht verschlüsselt sind. Die Verschlüsselung erfolgt mithilfe des für die ISAKMP-SA ausgehandelten Algorithmus, der durch die Kombination der Felder „Initiatorcookie“ und „Antwortcookie“ identifiziert wird. Das nächste untere Bit (Bit 1) ist das Commit-Bit, das anzeigt, dass der Schlüsselaustausch (bei Einstellung auf 1) synchronisiert oder (bei Einstellung auf 0) nicht synchronisiert wird. Das Commit-Bit soll sicherstellen, dass die SA ihre Aushandlung vor dem Senden verschlüsselter Daten abschließt. Das nächste untere Bit (Bit 2) ist das Authentication Only-Bit, mit dem angezeigt wird, dass die Nachricht die gesamte Notify-Nutzlast des Informationsaustauschtyps enthält (bei Einstellung auf 1) oder nicht (bei Einstellung auf 0) und authentifiziert, aber nicht verschlüsselt wurde.

Das Feld „Nachrichten-ID“ enthält einen eindeutigen Bezeichner für die Nachricht. Mit der Nachrichten-ID werden Konflikte verhindert, wenn beide IPSec-Peers versuchen, gleichzeitig eine IPSec-SA einzurichten. Das Feld „Länge“ zeigt die Länge der gesamten ISAKMP-Nachricht an.

Für IKE enthält die ISAKMP-Nachricht eine Reihe von ISAKMP-Nutzlasten. Die erste Nutzlast wird im Feld für die nächste Nutzlast des ISAKMP-Headers angezeigt. Jede ISAKMP-Nutzlast verfügt über ein eigenes Feld zur Anzeige der nächsten Nutzlast. Das Feld für die nächste Nutzlast ist in der letzten Nutzlast auf 0 eingestellt. Abbildung 2 zeigt das Format von IKE-Nachrichten.

Abbildung 2** Format von IKE Nachrichten **

AuthIP verwendet ISAKMP-Nachrichten mit den Austauschtypen 243 (Hauptmodus), 244 (Schnellmodus), 245 (erweiterter Modus) und 246 (Benachrichtigen) im Feld „Austauschtyp“ im ISAKMP-Header. Ein wichtiger Unterschied bei AuthIP-basierten ISAKMP-Nachrichten besteht darin, dass sie nur eine ISAKMP-Nutzlast enthalten: entweder die Crypto-Nutzlast oder die Notify-Nutzlast. Die Crypto-Nutzlast enthält die eingebetteten Nutzlasten, die für die Aushandlung im Hauptmodus-, Schnellmodus- oder erweiterten Modus verwendet werden. Die Crypto-Nutzlast kann abhängig vom Verschlüsselungsbit im Feld „Flags“ des ISAKMP-Headers einen Satz von Nur-Text- oder verschlüsselten Nutzlasten enthalten. Abbildung 3 zeigt das Format von AuthIP-Nachrichten, die die Crypto-Nutzlast enthalten.

Abbildung 3** Format von AuthIP-Nachrichten, die die Crypto-Nutzlast enthalten **

Koexistenz von AuthIP und IKE

Windows Vista® und Windows Server® 2008 unterstützen sowohl IKE als auch AuthIP. Windows® XP und Windows Server 2003 unterstützen jedoch nur IKE. Ein initiierender IPSec-Peer, der AuthIP und IKE unterstützt und über eine Verbindungssicherheitsrichtlinie verfügt, die sowohl AuthIP als auch IKE verwendet, muss ermitteln, ob der antwortende IPSec-Peer AuthIP oder IKE unterstützt. Dann muss der initiierende IPSec-Peer das passendste Protokoll zum Aushandeln des IPSec-Schutzes verwenden, wobei der Verwendung von AuthIP gegenüber IKE der Vorzug gegeben wird.

Um das Verhandlungsprotokoll des antwortenden IPSec-Peers zu ermitteln, sendet ein initiierender IPSec-Peer, der sowohl AuthIP als auch IKE verwendet, gleichzeitig die folgenden Nachrichten:

• Nachricht 1 – eine AuthIP-Nachricht, die die Hauptmodusaushandlung initiiert
• Nachricht 2 – eine IKE-Nachricht, die die Hauptmodusaushandlung initiiert

Wenn der antwortende Knoten AuthIP unterstützt, muss er auf Nachricht 1 mit einer AuthIP-Nachricht antworten, die die Hauptmodusaushandlung fortsetzt, und Nachricht 2 automatisch verwerfen. Ein antwortender Knoten, der AuthIP nicht unterstützt, verwirft automatisch Nachricht 1, da das in ihr enthaltene Austauschtypfeld einen Wert enthält, den er nicht unterstützt, und antwortet auf Nachricht 2.

Um die IKE-basierte Aushandlung zwischen zwei IPSec-Peers zu verhindern, auf denen Windows Vista oder Windows Server 2008 ausgeführt wird, wenn Nachricht 1 im Netzwerk verworfen wird oder nach Nachricht 2 eintrifft, senden IPSec-Peers, auf denen Windows Vista oder Windows Server 2008 ausgeführt wird, Nachricht 2 mit einer AuthIP-unterstützten Hersteller-ID-ISAKMP-Nutzlast. Die AuthIP-unterstützte Hersteller-ID-Nutzlast zeigt an, dass der IPSec-Peer AuthIP unterstützt.

Wenn daher ein IPSec-Peer, auf dem Windows Vista oder Windows Server 2008 ausgeführt wird, Nachricht 2 mit der AuthIP-unterstützten Hersteller-ID-Nutzlast erhält, wartet er darauf, dass der initiierende IPSec-Peer Nachricht 1 und 2 neu überträgt, und antwortet auf Nachricht 1.

Der initiierende IPSec-Peer fährt mit der Neuübertragung von Nachricht 1 und 2 fort, bis er eine Antwort erhält oder ein Timeout eintritt. Wenn der Initiator eine Antwort erhält, ermittelt er die Funktion des Antwortdiensts im ISAKMP-Header der Antwort. Wenn der Austauschtyp auf 243 eingestellt ist (der Austauschtyp für auf AuthIP-basierte Hauptmodusaushandlung), ist der Antwortdienst AuthIP-fähig. Wenn der Austauschtyp auf 2 eingestellt ist (der Austauschtyp für auf Identitätsschutz und IKE-basierte Hauptmodusaushandlung), ist der Antwortdienst IKE-fähig.

Je nach der Antwort antwortet der Initiator entweder mit der nächsten AuthIP-Nachricht für die AuthIP-Hauptmodusaushandlung oder mit der nächsten IKE-Nachricht für die IKE-Hauptmodusaushandlung. Die IPSec-Peers müssen für die Gültigkeitsdauer der SA dasselbe Protokoll verwenden, das zum Aushandeln der ISAKMP-SA verwendet wurde.

Joseph Davies ist technischer Redakteur bei Microsoft und Autor der monatlich erscheinenden TechNet-Rubrik „The Cable Guy“ unter Microsoft.com/technet/community/columns/cableguy.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.