Verständnis der EAP-FAST- und Verkettungsimplementierungen auf AnyConnect NAM und ISE

Einleitung

In diesem Dokument werden Details zur EAP-FAST-Implementierung auf dem Cisco AnyConnect Network Access Manager (NAM) und der Identity Services Engine (ISE) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse des EAP-Frameworks und der EAP-FAST-Methoden
• Grundkenntnisse der Identity Services Engine (ISE)
• Grundkenntnisse von AnyConnect NAM und Profile Editor  
• Grundkenntnisse der Cisco Catalyst Konfiguration für 802.1x-Services

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf folgenden Software-Versionen:

• Windows 7 mit Cisco AnyConnect Secure Mobility Client, Version 3.1 und 4.0
• Cisco Catalyst Switch 3750X mit Software 15.2.1 und höher
• Cisco ISE Version 1.4

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Theorie

Phasen

EAP-FAST ist ein flexibles EAP-Verfahren, das die gegenseitige Authentifizierung eines Supplicanten und eines Servers ermöglicht. Es ähnelt EAP-PEAP, erfordert jedoch in der Regel nicht die Verwendung von Client- oder sogar Serverzertifikaten. Ein Vorteil von EAP-FAST ist die Fähigkeit, mehrere Authentifizierungen (mithilfe mehrerer interner Methoden) zu verketten und kryptografisch miteinander zu verbinden (EAP-Verkettung). Cisco-Implementierungen verwenden diese für die Benutzer- und Geräteauthentifizierung.

EAP-FAST verwendet Protected Access Credentials (PAC), um den TLS-Tunnel (Sitzungswiederaufnahme) schnell einzurichten oder den Benutzer/Rechner zu autorisieren (innere Authentifizierungsmethode überspringen).

EAP-FAST umfasst drei Phasen:

• Phase 0 (PAC-Bereitstellung)
• Phase 1 (TLS-Tunnelaufbau)
• Phase 2 (Authentifizierung)

EAP-FAST unterstützt Gespräche ohne und ohne PAC. PAC-basiert umfasst PAC-Bereitstellung und PAC-basierte Authentifizierung. Die PAC-Bereitstellung kann auf anonymen oder authentifizierten TLS-Sitzungen basieren.

PAC

PAC sind geschützte Zugriffsanmeldedaten, die vom Server generiert und dem Client bereitgestellt werden. Es besteht aus:

• PAC-Schlüssel (zufälliger geheimer Wert, der zur Ableitung der TLS-Master- und Sitzungsschlüssel verwendet wird)
• PAC-undurchsichtig (PAC-Schlüssel + Benutzeridentität - alles mit EAP-FAST-Servermaster-Schlüssel verschlüsselt)
• PAC-Informationen (Serveridentität, TTL-Timer)

Der Server, der die PAC ausgibt, verschlüsselt den PAC-Schlüssel und die PAC-Identität mit dem EAP-FAST-Servermaster-Schlüssel (d. h. PAC undurchsichtig) und sendet die gesamte PAC an den Client. Es speichert keine weiteren Informationen (außer dem Master-Schlüssel, der für alle PACs identisch ist).

Sobald die PAC-Opak-Nachricht empfangen wurde, wird sie mit dem EAP-FAST-Servermaster-Schlüssel entschlüsselt und validiert. Der PAC-Schlüssel wird verwendet, um den TLS-Master und die Sitzungsschlüssel für einen verkürzten TLS-Tunnel abzuleiten.

Neue EAP-FAST-Server-Masterschlüssel werden generiert, wenn der vorherige Masterschlüssel abläuft.   In einigen Fällen kann ein Hauptschlüssel widerrufen werden.

Derzeit werden einige PAC-Typen verwendet:

• Tunnel-PAC: wird für den TLS-Tunnelaufbau verwendet (ohne Client- oder Serverzertifikat). Gesendet in TLS-Client hallo
• Maschine PAC: wird für die Einrichtung des TLS-Tunnels und die sofortige Maschinenautorisierung verwendet. Gesendet in TLS-Client hallo
• Benutzerautorisierungs-PAC: wird für die sofortige Benutzerauthentifizierung verwendet (Überspringen der inneren Methode), wenn vom Server zugelassen. Wird mithilfe von TLV in den TLS-Tunnel gesendet.
• Machine Authorization-PAC: wird für die sofortige Maschinenauthentifizierung verwendet (Überspringen der inneren Methode), wenn vom Server zugelassen. Wird mithilfe von TLV in den TLS-Tunnel gesendet.
• TrustSec-PAC: wird für die Autorisierung bei der Durchführung von Umgebungs- oder Richtlinienaktualisierungen verwendet.

Alle diese PACs werden in der Regel automatisch in Phase 0 bereitgestellt. Einige der PACs (Tunnel, Machine, TrustSec) können auch manuell ausgeliefert werden.

Wenn PACs generiert werden

• Tunnel-PAC: Wird nach erfolgreicher Authentifizierung (innere Methode) bereitgestellt, wenn zuvor nicht verwendet.
• Authorization PAC: Wird nach erfolgreicher Authentifizierung (innere Methode) bereitgestellt, wenn zuvor nicht verwendet.
• Computer-PAC: Wird nach erfolgreicher Computerauthentifizierung (innere Methode) bereitgestellt, wenn zuvor keine Verwendung stattgefunden hat und wenn keine Autorisierungs-PAC verwendet wird. Sie wird bereitgestellt, wenn die Tunnel-PAC abläuft, jedoch nicht, wenn die Autorisierungs-PAC abläuft. Sie wird bereitgestellt, wenn die EAP-Verkettung aktiviert oder deaktiviert ist.

Anmerkung:

Jede PAC-Bereitstellung erfordert eine erfolgreiche Authentifizierung, außer im Anwendungsfall: Autorisierter Benutzer fragt nach der Computer-PAC für einen Computer ohne AD-Konto.

In dieser Tabelle sind die Bereitstellungs- und proaktiven Aktualisierungsfunktionen zusammengefasst:

PAC-Typ	Tunnel v1/v1a/CTS	Maschine	Autorisierung
Bereitstellung von PAC auf Anfrage bei der Bereitstellung	ja	nur bei authentifizierter Bereitstellung	nur bei authentifizierter Bereitstellung und bei Anforderung von Tunnel-PAC
Bereitstellung von PAC auf Anforderung bei der Authentifizierung	ja	ja	nur, wenn sie bei dieser Authentifizierung nicht verwendet wird
Proaktives Update	ja	nein	nein
Wenn nach einer fehlgeschlagenen PAC-basierten Authentifizierung (z. B. wenn PAC abgelaufen ist) auf die PAC-Bereitstellung zurückgegriffen wird	ablehnen und keine neue bereitstellen	ablehnen und keine neue bereitstellen	ablehnen und keine neue bereitstellen
Unterstützung für ACS 4.x PACs	für Tunnel-PAC v1/v1a	ja	nein

EAP-FAST Server Master Key ACS 4.x im Vergleich zu ACS 5x und ISE

Beim Vergleich von ACS 4.x und ISE besteht ein geringfügiger Unterschied in der Handhabung von Master-Schlüsseln.

Funktion	ACS 4.1.2	ACS 5.x/ISE
Hauptschlüssel	Der Master-Schlüssel hat eine TTL, kann aktiv, deaktiviert oder abgelaufen sein.	Der Master-Schlüssel wird automatisch aus dem Seed für jeden konfigurierten Zeitraum generiert. Ein bestimmter Hauptschlüssel ist immer zugänglich und ist dann nie abgelaufen.
PAC-Aktualisierung	Das PAC-Update wird vom Server gesendet, wenn das PAC abgelaufen ist, es sei denn, der für die PAC-Verschlüsselung verwendete Master Key ist abgelaufen.	Das PAC-Update wird vom Server nach der ersten erfolgreichen Authentifizierung gesendet, die in einem bestimmten konfigurierbaren Zeitraum vor dem Ablauf des PAC durchgeführt wird.

Mit anderen Worten: Die ISE behält alle alten Hauptschlüssel bei und generiert standardmäßig einmal pro Woche einen neuen. Da der Hauptschlüssel nicht ablaufen kann, wird nur der PAC-TTL validiert.

Der ISE-Masterschlüssel-Generierungszeitraum wird über Administration -> Settings -> Protocol -> EAP-FAST -> EAP-FAST Settings konfiguriert.

Sitzung fortsetzen

Dies ist eine wichtige Komponente, die die Verwendung von Tunnel-PAC ermöglicht. Es ermöglicht die Neuverhandlung des TLS-Tunnels ohne Verwendung von Zertifikaten.

Für EAP-FAST gibt es zwei Arten von Sitzungswiederaufnahmen: auf dem Serverstatus basierend und auf dem Statusstatus (PAC-basiert).

Serverstatus

Die TLS-Standardmethode basiert auf der auf dem Server zwischengespeicherten TLS-Sitzungs-ID. Der Client, der den TLS-Client Hello sendet, hängt die SessionID an, um die Sitzung fortzusetzen. Die Sitzung wird nur für die PAC-Bereitstellung verwendet, wenn ein anonymer TLS-Tunnel verwendet wird:

Stateless (PAC-basiert)

Die Benutzer-/Computerautorisierungs-PAC wird zum Speichern der vorherigen Authentifizierungs- und Autorisierungsstatus für den Peer verwendet.

Der clientseitige Lebenslauf basiert auf RFC 4507. Der Server muss keine Daten zwischenspeichern. Stattdessen fügt der Client die PAC in die Erweiterung TLS Client Hello SessionTicket ein. Die PAC wiederum wird vom Server validiert.  Beispiel basierend auf der Tunnel-PAC, die an den Server übermittelt wurde:

AnyConnect NAM-Implementierung

Die Funktion ist auf Client-Seite (AnyConnect NAM) über Fast Reconnect aktiviert, dient jedoch nur zur Steuerung der PAC-Autorisierungsnutzung.

Wenn die Einstellung deaktiviert ist, verwendet NAM weiterhin die Tunnel-PAC zum Erstellen des TLS-Tunnels (keine Zertifikate erforderlich). Dabei werden jedoch keine Autorisierungs-PACs verwendet, um eine sofortige Benutzer- und Computerautorisierung durchzuführen. Dadurch ist immer Phase 2 mit dem inneren Verfahren erforderlich.

Die ISE verfügt über eine Option zum Aktivieren des Stateless Session Resume. Wie bei NAM nur für Autorisierung PAC. Die Tunnel-PAC-Nutzung wird mit den Optionen "Use PACs" (PACs verwenden) gesteuert.

NAM versucht, PACs zu verwenden, wenn die Option aktiviert ist. Wenn "Don't Use PACs" (PACs nicht verwenden) in ISE konfiguriert ist und ISE eine Tunnel-PAC in der TLS-Erweiterung erhält, wird der Fehler "Insert here" (Hier einfügen) gemeldet und ein EAP Failure (EAP-Fehler) wird zurückgegeben:

hier einfügen

In der ISE muss außerdem die Sitzungswiederaufnahme basierend auf der TLS-Sitzungs-ID (aus den globalen EAP-FAST-Einstellungen) aktiviert werden. Diese Funktion ist standardmäßig deaktiviert:

Beachten Sie, dass nur ein Typ von Sitzungswiederaufnahme verwendet werden kann. SessionID-basiert wird nur für Bereitstellungen ohne PAC verwendet, RFC 4507-basiert wird nur für PAC-Bereitstellungen verwendet.

PAC-Bereitstellung (Phase 0)

PACs können in Phase0 automatisch bereitgestellt werden. Phase 0 besteht aus:

• Einrichtung des TLS-Tunnels
• Authentifizierung (innere Methode)

PACs werden nach erfolgreicher Authentifizierung im TLS-Tunnel über PAC TLV (und PAC TLV Acknowledgement) bereitgestellt.

Anonymer TLS-Tunnel

Für Bereitstellungen ohne PKI-Infrastruktur kann ein anonymer TLS-Tunnel verwendet werden. Der anonyme TLS-Tunnel wird mithilfe der Diffie-Hellman-Verschlüsselungs-Suite erstellt - ohne dass ein Server- oder Client-Zertifikat erforderlich ist. Dieser Ansatz ist anfällig für die Angriffe des Menschen im Nahen Osten (Imitation).

Um diese Option zu verwenden, benötigt NAM die konfigurierte Option:

"Wenn die Verwendung von PACs eine nicht authentifizierte PAC-Bereitstellung zulässt" (dies ist nur bei der kennwortbasierten internen Methode sinnvoll, da ohne PKI-Infrastruktur keine zertifikatbasierte interne Methode verwendet werden kann).

Außerdem muss die ISE die Konfiguration "Allow Anonymous In-Band PAC Provisioning" unter den Authentication Allowed Protocols aktivieren.

Anonyme In-Band-PAC-Bereitstellung wird in TrustSec NDAC-Bereitstellungen verwendet (zwischen Netzwerkgeräten ausgehandelte EAP-FAST-Sitzung).

Authentifizierter TLS-Tunnel

Dies ist die sicherste und empfohlene Option. Der TLS-Tunnel wird auf Basis des Serverzertifikats erstellt, das vom Supplicant validiert wird. Dies erfordert nur eine serverseitige PKI-Infrastruktur, die für die ISE erforderlich ist (auf NAM kann die Option "Serveridentität validieren" deaktiviert werden).

Für die ISE gibt es zwei zusätzliche Optionen:

Normalerweise wird nach der PAC-Bereitstellung eine Access-Reject-Nachricht gesendet, die die Komponente dazu zwingt, sich mithilfe von PACs erneut zu authentifizieren. Da die PACs jedoch im TLS-Tunnel mit Authentifizierung bereitgestellt wurden, ist es möglich, den gesamten Prozess zu verkürzen und Access-Accept sofort nach der PAC-Bereitstellung zurückzugeben. 

Mit der zweiten Option wird der TLS-Tunnel auf Basis eines Clientzertifikats erstellt (hierzu ist eine PKI-Bereitstellung auf den Endpunkten erforderlich). Dadurch kann der TLS-Tunnel mit gegenseitiger Authentifizierung erstellt werden, wodurch die interne Methode übersprungen wird und direkt zur PAC-Bereitstellungsphase übergegangen wird. Hierbei ist Vorsicht geboten - manchmal stellt der Supplicant ein Zertifikat dar, das von der ISE nicht vertrauenswürdig ist (für andere Zwecke bestimmt) und die Sitzung scheitert.

EAP-Verkettung

Ermöglicht Benutzer- und Geräteauthentifizierung innerhalb einer Radius/EAP-Sitzung. Mehrere EAP-Methoden können miteinander verknüpft werden. Nachdem die erste Authentifizierung (in der Regel eine Maschine) erfolgreich abgeschlossen wurde, sendet der Server ein TLV mit Zwischenergebnis (innerhalb des TLS-Tunnels), um den Erfolg anzuzeigen. Diese TLV muss von einer Crypto-Binding-TLV-Anforderung begleitet werden. Mit der Kryptobindung wird nachgewiesen, dass sowohl der Server als auch der Peer an der bestimmten Authentifizierungssequenz beteiligt waren. Bei der Kryptobindung wird das Schlüsselmaterial aus Phase 1 und Phase 2 verwendet. Darüber hinaus ist noch ein TLV angefügt: EAP-Payload - diese initiiert die neue Sitzung (in der Regel für den Benutzer). Sobald der RADIUS-Server (ISE) die Krypto-Binding TLV-Antwort empfängt und validiert, wird diese im Protokoll angezeigt, und die nächste EAP-Methode wird versucht (in der Regel für die Benutzerauthentifizierung):

12126   EAP-FAST cryptobinding verification passed

Wenn die Verschlüsselungsvalidierung fehlschlägt, schlägt die gesamte EAP-Sitzung fehl. Wenn eine der Authentifizierungen innerhalb fehlgeschlagen ist, ist es immer noch in Ordnung - infolgedessen ermöglicht die ISE einem Administrator, mehrere Verkettungsergebnisse auf der Grundlage der Autorisierungsbedingung Netzwerkzugriff:EapChainingResult:

Die EAP-Verkettung wird auf NAM automatisch aktiviert, wenn die EAP-FAST-Benutzer- und Geräteauthentifizierung aktiviert ist.

Die EAP-Verkettung muss in der ISE konfiguriert werden.

Speicherort der PAC-Dateien

Standardmäßig werden Tunnel- und Computer-PACs in den Abschnitten <credential> unter C:\ProgramData\Cisco\Cisco AnyConnect Secure Mobility Client\Network Access Manager\system\internalConfiguration.xml gespeichert. Diese werden in verschlüsselter Form gespeichert.

Autorisierungs-PACs werden nur im Arbeitsspeicher gespeichert und nach dem Neustart oder NAM-Service-Neustart entfernt.

Zum Entfernen des Tunnel- oder Computer-PAC ist ein Neustart des Diensts erforderlich.

AnyConnect NAM 3.1 und 4.0 im Vergleich

Mit dem AnyConnect 3.x NAM-Profil-Editor konnte der Administrator die PACs manuell konfigurieren. Diese Funktion wurde aus dem AnyConnect 4.x NAM-Profil-Editor entfernt.

Die Entscheidung, diese Funktion zu entfernen, basiert auf der Cisco Bug-ID CSCuf3142 und der Cisco Bug-ID CSCua13140 .

Beispiele

Netzwerkdiagramm

Alle Beispiele wurden mit dieser Netzwerktopologie getestet. Dasselbe gilt auch für die Verwendung von Wireless-Netzwerken.

EAP-Fast ohne EAP-Verkettung mit PAC für Benutzer und Maschine

Standardmäßig ist EAP_chaining auf der ISE deaktiviert. Alle anderen Optionen sind jedoch aktiviert, einschließlich Computer- und Autorisierungs-PACs. Die Komponente verfügt bereits über eine gültige Rechner- und Tunnel-PAC. In diesem Fluss gibt es zwei separate Authentifizierungen - eine für den Computer und eine für den Benutzer - mit separaten Anmeldungen bei der ISE. Die wichtigsten Schritte werden von der ISE protokolliert. Erste Authentifizierung (Maschine):

• Supplicant sendet TLS-Client-Hello mit Computer-PAC.
• Der Server validiert die Computer-PAC und erstellt den TLS-Tunnel (es werden keine Zertifikate verwendet).
• Der Server validiert die Computer-PAC und führt die Kontensuche in Active Directory durch und überspringt die interne Methode.

12102 Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated 
12800 Extracted first TLS record; TLS handshake started 
12174 Received Machine PAC 
12805 Extracted TLS ClientHello message 
12806 Prepared TLS ServerHello message 
12801 Prepared TLS ChangeCipherSpec message 

12816 TLS handshake succeeded 
12132 EAP-FAST built PAC-based tunnel for purpose of authentication 

24351 Account validation succeeded 
24420 User's Attributes retrieval from Active Directory succeeded - example . com 
22037 Authentication Passed 
12124 EAP-FAST inner method skipped 

11503 Prepared EAP-Success 
11002 Returned RADIUS Access-Accept 

Die zweite Authentifizierung (Benutzer):

• Supplicant sendet den TLS-Client Hello mit Tunnel-PAC.
• Der Server validiert die PAC und erstellt den TLS-Tunnel (es werden keine Zertifikate verwendet).
• Da Supplicant über keine Autorisierungs-PAC verfügt, wird die innere Methode (EAP-MSCHAP) für die Authentifizierung verwendet.

12102 Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated 
12800 Extracted first TLS record; TLS handshake started 
12175 Received Tunnel PAC 
12805 Extracted TLS ClientHello message 
12806 Prepared TLS ServerHello message 
12801 Prepared TLS ChangeCipherSpec message 

12816 TLS handshake succeeded 
12132 EAP-FAST built PAC-based tunnel for purpose of authentication 
12125 EAP-FAST inner method started 
11806 Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge 

24402 User authentication against Active Directory succeeded - example . com 
22037 Authentication Passed 

11503 Prepared EAP-Success 
11002 Returned RADIUS Access-Accept

Im Abschnitt "Andere Attribute" des detaillierten Berichts in der ISE wird dies sowohl für die Benutzer- als auch für die Geräteauthentifizierung vermerkt:

EapChainingResult: No chaining

EAP-Fast mit EAP-Verkettung mit PAC Fast Reconnect

In diesem Fluss verfügt der Supplicant bereits über eine gültige Tunnel-PAC sowie über die PACs für die Benutzer- und Computerautorisierung:

• Supplicant sendet den TLS-Client Hello mit Tunnel-PAC.
• Der Server validiert die PAC und erstellt den TLS-Tunnel (es werden keine Zertifikate verwendet).
• Die ISE startet die EAP-Verkettung, der Supplicant fügt Autorisierungs-PACs für den Benutzer und den Computer mithilfe von TLV im TLS-Tunnel an.
• Die ISE validiert die Autorisierungs-PACs (keine interne Methode erforderlich), überprüft, ob Konten in Active Directory vorhanden sind (keine zusätzliche Authentifizierung) und gibt "Success" zurück.

12102   Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated
12800   Extracted first TLS record; TLS handshake started
12175   Received Tunnel PAC
12805   Extracted TLS ClientHello message
12806   Prepared TLS ServerHello message
12801   Prepared TLS ChangeCipherSpec message

12816   TLS handshake succeeded
12132   EAP-FAST built PAC-based tunnel for purpose of authentication
12209   Starting EAP chaining
12210   Received User Authorization PAC
12211   Received Machine Authorization PAC

24420   User's Attributes retrieval from Active Directory succeeded - example .com
22037   Authentication Passed

24439   Machine Attributes retrieval from Active Directory succeeded - example .com
22037   Authentication Passed

11503   Prepared EAP-Success        
11002   Returned RADIUS Access-Accept 

Im Abschnitt "Sonstige Attribute" des detaillierten Berichts der ISE wird dieses Ergebnis wie folgt festgehalten:

EapChainingResult: EAP Chaining

Darüber hinaus sind Benutzer- und Computeranmeldeinformationen im gleichen Protokoll enthalten, wie hier gezeigt:

Username: cisco,host/mgarcarz-PC

EAP-Fast mit EAP-Verkettung ohne PAC

In diesem Fluss ist NAM so konfiguriert, dass es keine PAC verwendet, ISE ist ebenfalls so konfiguriert, dass PAC nicht verwendet wird (jedoch mit EAP-Verkettung)

• Supplicant sendet TLS-Client Hello ohne Tunnel-PAC.
• Der Server reagiert mit den Payloads für das TLS-Zertifikat und die Zertifikatanforderung.
• Der Supplicant muss dem Serverzertifikat vertrauen, sendet kein Clientzertifikat (Zertifikatsnutzlast ist Null), der TLS-Tunnel wird erstellt.
• Die ISE sendet eine TLV-Anforderung für das Client-Zertifikat innerhalb des TLS-Tunnels, die Supplicant-Funktion jedoch nicht (sie ist nicht erforderlich, um fortzufahren).
• Startet die EAP-Verkettung für den Benutzer mithilfe der internen Methode mit MSCHAPv2-Authentifizierung.
• Fahren Sie mit der Computerauthentifizierung fort, wobei die innere Methode mit der MSCHAPv2-Authentifizierung verwendet wird.
• Keine PACs bereitgestellt.

12102     Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated
12800     Extracted first TLS record; TLS handshake started
12805     Extracted TLS ClientHello message
12806     Prepared TLS ServerHello message
12807     Prepared TLS Certificate message
12809     Prepared TLS CertificateRequest message
12811     Extracted TLS Certificate message containing client certificate
12812     Extracted TLS ClientKeyExchange message

12816     TLS handshake succeeded
12207     Client certificate was requested but not received during tunnel establishment. Will renegotiate and request client certificate inside the tunnel.
12226     Started renegotiated TLS handshake

12104     Extracted EAP-Response containing EAP-FAST challenge-response
12811     Extracted TLS Certificate message containing client certificate
12812     Extracted TLS ClientKeyExchange message
12804     Extracted TLS Finished message
12801     Prepared TLS ChangeCipherSpec message
12802     Prepared TLS Finished message
12226     Started renegotiated TLS handshake
12205     Client certificate was requested but not received inside the tunnel. Will continue with inner method.
12176     EAP-FAST PAC-less full handshake finished successfully

12209     Starting EAP chaining
12218     Selected identity type 'User'

11806     Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge

24402     User authentication against Active Directory succeeded - example .com
22037     Authentication Passed

12219     Selected identity type 'Machine'

11806     Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge

24470     Machine authentication against Active Directory is successful - example .com
22037     Authentication Passed

11503     Prepared EAP-Success
11002     Returned RADIUS Access-Accept 

EAP-Fast mit EAP-Verkettung, Autorisierung, PAC-Ablauf

In diesem Fluss verfügt der Supplicant über eine gültige Tunnel-PAC, hat jedoch abgelaufene Autorisierungs-PACs:

• Supplicant sendet den TLS-Client Hello mit Tunnel-PAC.
• Der Server validiert die PAC und erstellt den TLS-Tunnel (es werden keine Zertifikate verwendet).
• Die ISE startet die EAP-Verkettung, der Supplicant fügt Autorisierungs-PACs für Benutzer und Maschine mithilfe von TLV im TLS-Tunnel an.
• Wenn die PACs abgelaufen sind, wird die interne Methode für Benutzer und Computer gestartet (EAP-MSCHAP).
• Sobald beide Authentifizierungen erfolgreich sind, werden sowohl Benutzer- als auch Computer-Autorisierungs-PACs bereitgestellt.

12102   Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated
12800   Extracted first TLS record; TLS handshake started
12175   Received Tunnel PAC
12805   Extracted TLS ClientHello message
12806   Prepared TLS ServerHello message
12801   Prepared TLS ChangeCipherSpec message

12816   TLS handshake succeeded
12132   EAP-FAST built PAC-based tunnel for purpose of authentication
12209   Starting EAP chaining
12227   User Authorization PAC has expired - will run inner method
12228   Machine Authorization PAC has expired - will run inner method
12218   Selected identity type 'User'

11806   Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge

24402   User authentication against Active Directory succeeded - example .com
22037   Authentication Passed

12219   Selected identity type 'Machine'

24470   Machine authentication against Active Directory is successful - example .com
22037   Authentication Passed

12171   Successfully finished EAP-FAST user authorization PAC provisioning/update
12179   Successfully finished EAP-FAST machine authorization PAC provisioning/update

11503   Prepared EAP-Success
11002   Returned RADIUS Access-Accept 

EAP-Fast mit EAP-Verkettungstunnel - PAC abgelaufen

Wenn in diesem Fluss keine gültige Tunnel-PAC vorhanden ist, findet eine vollständige TLS-Aushandlung mit der inneren Phase statt.

• Supplicant sendet den TLS-Client Hello ohne Tunnel-PAC.
• Der Server reagiert mit den Payloads für das TLS-Zertifikat und die Zertifikatanforderung.
• Der Supplicant muss dem Serverzertifikat vertrauen, sendet kein Clientzertifikat (Zertifikatsnutzlast ist Null), TLS-Tunnel wurde erstellt.
• Die ISE sendet eine TLV-Anforderung für das Client-Zertifikat innerhalb des TLS-Tunnels, die Supplicant-Funktion jedoch nicht (sie ist nicht erforderlich, um fortzufahren).
• Startet die EAP-Verkettung für den Benutzer mithilfe der internen Methode mit MSCHAPv2-Authentifizierung.
• Fahren Sie mit der Computerauthentifizierung fort, wobei die innere Methode mit der MSCHAPv2-Authentifizierung verwendet wird.
• Alle PACs wurden erfolgreich bereitgestellt (aktiviert in ISE-Konfiguration).

12102   Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated
12800   Extracted first TLS record; TLS handshake started
12805   Extracted TLS ClientHello message
12806   Prepared TLS ServerHello message
12807   Prepared TLS Certificate message
12809   Prepared TLS CertificateRequest message
12105   Prepared EAP-Request with another EAP-FAST challenge
11006   Returned RADIUS Access-Challenge
11001   Received RADIUS Access-Request

12816   TLS handshake succeeded
12207   Client certificate was requested but not received during tunnel establishment. Will renegotiate and request client certificate inside the tunnel.
12226   Started renegotiated TLS handshake

12104   Extracted EAP-Response containing EAP-FAST challenge-response
12811   Extracted TLS Certificate message containing client certificate
12812   Extracted TLS ClientKeyExchange message
12804   Extracted TLS Finished message
12801   Prepared TLS ChangeCipherSpec message
12802   Prepared TLS Finished message
12226   Started renegotiated TLS handshake
12205   Client certificate was requested but not received inside the tunnel. Will continue with inner method.
12149   EAP-FAST built authenticated tunnel for purpose of PAC provisioning
12105   Prepared EAP-Request with another EAP-FAST challenge
11006   Returned RADIUS Access-Challenge
11001   Received RADIUS Access-Request
11018   RADIUS is re-using an existing session
12104   Extracted EAP-Response containing EAP-FAST challenge-response
12209   Starting EAP chaining
12218   Selected identity type 'User'
11806   Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge    

24402   User authentication against Active Directory succeeded - example .com
22037   Authentication Passed

12126   EAP-FAST cryptobinding verification passed
12200   Approved EAP-FAST client Tunnel PAC request
12202   Approved EAP-FAST client Authorization PAC request
12219   Selected identity type 'Machine'

11806   Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge

24470   Machine authentication against Active Directory is successful - example .com
22037   Authentication Passed

12169   Successfully finished EAP-FAST tunnel PAC provisioning/update
12171   Successfully finished EAP-FAST user authorization PAC provisioning/update
12170   Successfully finished EAP-FAST machine PAC provisioning/update
12179   Successfully finished EAP-FAST machine authorization PAC provisioning/update

11503   Prepared EAP-Success
11002   Returned RADIUS Access-Accept 

EAP-Fast mit EAP-Verkettung und anonymer TLS-Tunnel-PAC-Bereitstellung

In diesem Fluss wird der anonyme ISE- und NAM-TLS-Tunnel für die PAC-Bereitstellung konfiguriert (der ISE-authentifizierte TLS-Tunnel für die PAC-Bereitstellung ist deaktiviert). Die PAC-Bereitstellungsanforderung sieht wie folgt aus:

• Supplicant sendet TLS-Client-Hello ohne mehrere Chiffre-Suites.
• Der Server antwortet mit den anonymen TLS Server Hello- und TLS Diffie Hellman-Verschlüsselungen (z. B. TLS_DH_anon_WITH_AES_128_CBC_SHA).
• Supplicant akzeptiert es und der anonyme TLS-Tunnel wird erstellt (keine Zertifikate ausgetauscht).
• Startet die EAP-Verkettung für den Benutzer mithilfe der internen Methode mit MSCHAPv2-Authentifizierung.
• Fahren Sie mit der Computerauthentifizierung fort, wobei die innere Methode mit der MSCHAPv2-Authentifizierung verwendet wird.
• Da der anonyme TLS-Tunnel erstellt wird, sind Autorisierungs-PACs nicht zulässig.
• Radius Reject (Zurückweisen von Radius) wird zurückgegeben, um die erneute Authentifizierung des Supplicant zu erzwingen (mithilfe der bereitgestellten PAC).

12102     Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated      
12800     Extracted first TLS record; TLS handshake started
12805     Extracted TLS ClientHello message
12806     Prepared TLS ServerHello message
12808     Prepared TLS ServerKeyExchange message
12810     Prepared TLS ServerDone message

12812     Extracted TLS ClientKeyExchange message
12804     Extracted TLS Finished message
12801     Prepared TLS ChangeCipherSpec message
12802     Prepared TLS Finished message
12816     TLS handshake succeeded
12131     EAP-FAST built anonymous tunnel for purpose of PAC provisioning

12209     Starting EAP chaining
12218     Selected identity type 'User'

11806     Prepared EAP-Request for inner method proposing EAP-MSCHAP with challenge

24402     User authentication against Active Directory succeeded - example .com
22037     Authentication Passed

12162     Cannot provision Authorization PAC on anonymous provisioning. Authorization PAC can be provisioned only on authenticated provisioning
12200     Approved EAP-FAST client Tunnel PAC request
12219     Selected identity type 'Machine'

24470     Machine authentication against Active Directory is successful - example .com
22037     Authentication Passed

12162     Cannot provision Authorization PAC on anonymous provisioning. Authorization PAC can be provisioned only on authenticated provisioning      
12169     Successfully finished EAP-FAST tunnel PAC provisioning/update
12170     Successfully finished EAP-FAST machine PAC provisioning/update

11504     Prepared EAP-Failure
11003     Returned RADIUS Access-Reject 

Wireshark-Paketerfassung für anonyme TLS-Tunnelaushandlung:

EAP-Fast, nur Benutzerauthentifizierung mit EAP-Verkettung

In diesem Fluss wird AnyConnect NAM mit EAP-FAST und User (EAP-TLS) sowie Machine Authentication (EAP-TLS) konfiguriert. Der Windows-PC wird gestartet, es werden jedoch keine Benutzeranmeldeinformationen angegeben. Der Switch initiiert eine 802.1x-Sitzung. NAM muss antworten, es werden jedoch keine Benutzeranmeldeinformationen bereitgestellt (noch kein Zugriff auf den Benutzerspeicher und das Zertifikat). Die Benutzerauthentifizierung schlägt fehl, während der Computer erfolgreich ist. Die ISE-Authentifizierungsbedingung "Netzwerkzugriff: EapChainingResult EQUALS: Benutzer fehlgeschlagen und der Computer erfolgreich" ist erfüllt. Später meldet sich der Benutzer an, und eine weitere Authentifizierung wird gestartet. Sowohl der Benutzer als auch der Computer sind erfolgreich.

• Supplicant sendet TLS-Client-Hello mit Computer-PAC.
• Server reagiert mit TLS Change Cipher Spec - TLS-Tunnel wird sofort basierend auf dieser PAC erstellt.
• Die ISE initiiert die EAP-Verkettung und fragt nach der Benutzeridentität.
• Supplicant stellt stattdessen die Maschinenidentität bereit (Benutzer noch nicht bereit), beendet die EAP-TLS innere Methode.
• ISE fragt erneut nach der Benutzeridentität, Supplicant kann diese nicht bereitstellen.
• ISE sendet TLV mit intermediärem Ergebnis = Fehler (für die Benutzerauthentifizierung).
• ISE gibt die letzte EAP-Erfolgsmeldung zurück, ISE-Bedingung Netzwerkzugriff:EapChainingResult EQUALS Benutzer ist fehlgeschlagen und der erfolgreiche Computer ist zufrieden.

12102   Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated
12800   Extracted first TLS record; TLS handshake started
12174   Received Machine PAC

12805   Extracted TLS ClientHello message
12806   Prepared TLS ServerHello message
12801   Prepared TLS ChangeCipherSpec message
12802   Prepared TLS Finished message

12816   TLS handshake succeeded
12132   EAP-FAST built PAC-based tunnel for purpose of authentication

12209   Starting EAP chaining
12218   Selected identity type 'User'

12213   Identity type provided by client is not equal to requested type
12215   Client suggested 'Machine' identity type instead

12104   Extracted EAP-Response containing EAP-FAST challenge-response
12523   Extracted EAP-Response/NAK for inner method requesting to use EAP-TLS instead

12805   Extracted TLS ClientHello message
12806   Prepared TLS ServerHello message
12807   Prepared TLS Certificate message
12809   Prepared TLS CertificateRequest message

12816   TLS handshake succeeded
12509   EAP-TLS full handshake finished successfully

22070   Identity name is taken from certificate attribute
15013   Selected Identity Source - Test-AD
24323   Identity resolution detected single matching account
22037   Authentication Passed

12202   Approved EAP-FAST client Authorization PAC request
12218   Selected identity type 'User'
12213   Identity type provided by client is not equal to requested type
12216   Identity type provided by client was already used for authentication
12967   Sent EAP Intermediate Result TLV indicating failure

12179   Successfully finished EAP-FAST machine authorization PAC provisioning/update
12106   EAP-FAST authentication phase finished successfully
11503   Prepared EAP-Success
11002   Returned RADIUS Access-Accept

EAP-Fast mit EAP-Verkettung und inkonsistenten anonymen TLS-Tunneleinstellungen

In diesem Fluss wird die ISE für die PAC-Bereitstellung nur über einen anonymen TLS-Tunnel konfiguriert. NAM verwendet jedoch einen authentifizierten TLS-Tunnel. Dies wird von ISE protokolliert:

12102   Extracted EAP-Response containing EAP-FAST challenge-response and accepting EAP-FAST as negotiated
12800   Extracted first TLS record; TLS handshake started
12805   Extracted TLS ClientHello message
12814   Prepared TLS Alert message
12817   TLS handshake failed
12121   Client didn't provide suitable ciphers for anonymous PAC-provisioning

11504   Prepared EAP-Failure
11003   Returned RADIUS Access-Reject 

Dies tritt auf, wenn NAM versucht, einen authentifizierten TLS-Tunnel mit seinen spezifischen TLS-Chiffren zu erstellen. Diese werden von der ISE, die für einen anonymen TLS-Tunnel konfiguriert ist, nicht akzeptiert (nur DH-Chiffren werden akzeptiert).

Fehlerbehebung

ISE

Für detaillierte Protokolle müssen Runtime-AAA-Debugging auf dem entsprechenden PSN-Knoten aktiviert werden. Hier einige Beispiele für Protokolle von prrt-server.log:

Generierung von maschinellem PAC:

DEBUG,0x7fd5332fe700,cntx=0001162745,sesn=mgarcarz-ise14/223983918/29245,CPMSessionID=0A3E946D00000FE5131F9D26,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Using IID from PAC request for machine,EapFastTlv.cpp:1234

DEBUG,0x7fd5332fe700,cntx=0001162745,sesn=mgarcarz-ise14/223983918/29245,CPMSessionID=0A3E946D00000FE5131F9D26,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Adding PAC of type=Machine Authorization,EapFastProtocol.cpp:3610

DEBUG,0x7fd5332fe700,cntx=0001162745,sesn=mgarcarz-ise14/223983918/29245,CPMSessionID=0A3E946D00000FE5131F9D26,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Eap-Fast: Generating Pac, Issued PAC type=Machine Authorization with expiration time: Fri Jul  3 10:38:30 2015

Genehmigung der PAC-Anforderung:

INFO ,0x7fd5330fc700,cntx=0001162745,sesn=mgarcarz-ise14/223983918/29245,CPMSessionID=0A3E946D00000FE5131F9D26,user=host/mgarcarz-pc,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Eap-Fast: client PAC request approved for PAC type - Requested PAC type=Machine,EapFastProtocol.cpp:955

INFO ,0x7fd5330fc700,cntx=0001162745,sesn=mgarcarz-ise14/223983918/29245,CPMSessionID=0A3E946D00000FE5131F9D26,user=host/mgarcarz-pc,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Eap-Fast: client PAC request approved for PAC type - Requested PAC type=Machine Authorization,EapFastProtocol.cpp:955

PAC-Validierung:

DEBUG,0x7fd5330fc700,cntx=0001162499,sesn=mgarcarz-ise14/223983918/29243,CPMSessionID=0A3E946D00000FE5131F9D26,user=anonymous,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Authorization PAC is valid,EapFastProtocol.cpp:3403

Eap,2015-07-03 09:34:39,208,DEBUG,0x7fd5330fc700,cntx=0001162499,sesn=mgarcarz-ise14/223983918/29243,CPMSessionID=0A3E946D00000FE5131F9D26,user=anonymous,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Authorization PAC accepted,EapFastProtocol.cpp:3430

Beispiel einer erfolgreichen Zusammenfassung für die PAC-Generierung:

DEBUG,0x7fd5331fd700,cntx=0001162749,sesn=mgarcarz-ise14/223983918/29245,CPMSessionID=0A3E946D00000FE5131F9D26,user=cisco,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Conversation summary: Provisioning. Authenticated. Inner method succeeded. Inner method succeeded. Generated PAC of type Tunnel V1A. Generated PAC of type User Authorization. Generated PAC of type Machine. Generated PAC of type Machine Authorization.  Success

Beispiel einer erfolgreichen Zusammenfassung für die PAC-Validierung:

DEBUG,0x7fd5330fc700,cntx=0001162503,sesn=mgarcarz-ise14/223983918/29243,CPMSessionID=0A3E946D00000FE5131F9D26,user=host/mgarcarz-pc,CallingStationID=00-50-B6-11-ED-31,FramedIPAddress=10.0.13.127,Conversation summary: Authentication. PAC type Tunnel V1A. PAC is valid.Skip inner method. Skip inner method.  Success

AnyConnect NAM

Beispiel für Nicht-EAP-Verkettung, Maschinenauthentifizierung ohne schnelle Wiederherstellung der Verbindung:

EAP: Identity requested
Auth[eap-fast-pac:machine-auth]: Performing full authentication
Auth[eap-fast-pac:machine-auth]: Disabling fast reauthentication

Beispiel einer PAC-Suche für die Autorisierung (Machine Authentication für Nicht-EAP-Chaining-Sitzung):

Looking for matching pac with iid: host/ADMIN-PC2
Requested machine pac was sen

Alle Zustände der internen Methode (für MSCHAP) können anhand der folgenden Protokolle überprüft werden:

 EAP (0) EAP-MSCHAP-V2: State: 0 (eap_auth_mschapv2_c.c 731
 EAP (0) EAP-MSCHAP-V2: State: 2 (eap_auth_mschapv2_c.c 731
 EAP (0) EAP-MSCHAP-V2: State: 1 (eap_auth_mschapv2_c.c 731
 EAP (0) EAP-MSCHAP-V2: State: 4 (eap_auth_mschapv2_c.c 73

NAM ermöglicht die Konfiguration der erweiterten Protokollierungsfunktion, die alle EAP-Pakete erfasst und in einer pcap-Datei speichert. Dies ist besonders hilfreich für die Funktion "Start Before Logon" (EAP-Pakete werden auch bei Authentifizierungen erfasst, die vor der Benutzeranmeldung erfolgen). Fragen Sie Ihren TAC-Techniker zur Aktivierung der Funktion.

Referenzen

• Administratoranleitung für den Cisco AnyConnect Secure Mobility Client, EAP-FAST-Konfiguration, Version 4.0
• Administratorleitfaden für die Cisco Identity Services Engine, EAP-FAST-Empfehlungen für Version 1.4
• Cisco Identity Services Engine - Designleitfäden
• Bereitstellung der EAP-Verkettung mit AnyConnect NAM und der Cisco ISE
• Technischer Support und Dokumentation für Cisco Systeme