排除EAP分段實施和行為故障

簡介

本文說明如何理解可擴展身份驗證協定(EAP)會話並對其進行故障排除。

必要條件

需求

思科建議您瞭解以下主題：

• EAP和EAP-TLS協定
• 思科身份服務引擎(ISE)的配置
• Cisco Catalyst交換機的CLI配置

要理解本文的內容，必須對EAP和EAP-TLS有很好的理解。

採用元件

本檔案所述內容不限於特定硬體和軟體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

本文檔的各個部分專門介紹以下領域的覆蓋範圍：

• 身份驗證、授權和記帳(AAA)伺服器返回可擴展身份驗證協定 — 傳輸層安全(EAP-TLS)會話的伺服器證書時的行為。
• 請求方返回EAP-TLS會話的客戶端證書時的行為。
• 同時使用Microsoft Windows Native Supplicant客戶端和Cisco AnyConnect Network Access Manager(NAM)時的互操作性。
• IP、RADIUS和EAP-TLS中的分段和網路接入裝置執行的重組過程。
• RADIUS已框架最大傳輸單元(MTU)屬性。
• AAA伺服器執行EAP-TLS資料包分段時的行為。

伺服器返回的證書鏈

AAA伺服器(訪問控制伺服器(ACS)和ISE)始終返回帶有伺服器Hello和伺服器證書的EAP-TLS資料包的完整鏈：

ISE身份證書(通用名稱(CN)=lise.example.com)與簽署CN=win2012,dc=example，dc=com的證書頒發機構(CA)一起返回。ACS和ISE的行為相同。

請求方返回的證書鏈

Microsoft Windows本機請求方

Microsoft Windows 7原生Supplicant客戶端配置為使用EAP-TLS（無論是否選擇簡單證書），並且不傳送客戶端證書的完整鏈。即使客戶端證書是由與伺服器證書不同的CA（不同鏈）簽名的，也會發生此行為。

此示例與前面螢幕抓圖中所示的伺服器Hello和證書相關。對於此場景，ISE證書由CA使用使用者名稱CN=win2012,dc=example，dc=com進行簽名，但是Microsoft應用商店中安裝的使用者證書由不同的CA進行簽名，CN=CA，C=PL，S=Cisco CA，L=Cisco CA，O=Cisco CA。

因此，Microsoft Windows請求方僅使用客戶端證書進行響應。簽署它的CA(CN=CA，S=PL，S=Cisco CA，L=Cisco CA，O=Cisco CA)未連線。

由於此行為，AAA伺服器在驗證客戶端證書時可能會遇到問題。本示例與Microsoft Windows 7 SP1 Professional有關。

解決方案

完整的證書鏈將安裝在ACS和ISE的證書儲存上（所有CA和子CA簽名客戶端證書）。

在ACS或ISE上可以輕鬆檢測到證書驗證問題。將顯示有關不受信任證書的資訊和ISE報告：

12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client
certificates chain

很難檢測到請求方上的證書驗證問題。通常，AAA伺服器響應終端放棄的EAP會話。

AnyConnect NAM

AnyConnect NAM沒有此限制。在相同的情況下，它會附加完整的客戶端證書鏈（附加正確的CA）。

Microsoft Windows Native Supplicant客戶端與AnyConnect NAM

當兩個服務都啟動時，AnyConnect NAM優先。即使NAM服務未運行，它仍然掛接在Microsoft Windows API上並轉發EAP資料包，這可能會導致Microsoft Windows本機請求方出現問題。

以下是此類故障的示例。

使用以下命令在Microsoft Windows上啟用跟蹤：

C:\netsh ras set tracing * enable

跟蹤(c:\windows\trace\svchost_RASTLS.LOG)顯示：

[2916] 09-14 21:29:11:254: >> Received Request (Code: 1) packet: Id: 55, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[2916] 09-14 21:29:11:254: << Sending Response (Code: 2) packet: Id: 55, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[1804] 09-14 21:29:11:301: >> Received Request (Code: 1) packet: Id: 56, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[1804] 09-14 21:29:11:301: << Sending Response (Code: 2) packet: Id: 56, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:348: >> Received Request (Code: 1) packet: Id: 57, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[1804] 09-14 21:29:11:348: << Sending Response (Code: 2) packet: Id: 57, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: >> Received Request (Code: 1) packet: Id: 58, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[1804] 09-14 21:29:11:363: << Sending Response (Code: 2) packet: Id: 58, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM
[3084] 09-14 21:31:11:203: >> Received Request (Code: 1) packet: Id: 122, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[3084] 09-14 21:31:11:218: << Sending Response (Code: 2) packet: Id: 122, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[3420] 09-14 21:31:11:249: >> Received Request (Code: 1) packet: Id: 123, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[3420] 09-14 21:31:11:249: << Sending Response (Code: 2) packet: Id: 123, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 124, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[3420] 09-14 21:31:11:281: << Sending Response (Code: 2) packet: Id: 124, Length:
6, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 125, Length:
344, Type: 13, TLS blob length: 0. Flags: 
[3420] 09-14 21:31:11:296: << Sending Response (Code: 2) packet: Id: 125, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM

最後一個資料包是Microsoft Windows本機請求方傳送的客戶端證書（EAP-TLS片段1,EAP大小為1492）。很遺憾，Wireshark沒有顯示該資料包：

而該資料包並未真正傳送；最後一個是攜帶伺服器證書的EAP-TLS的第三個片段。

它已被掛接在Microsoft Windows API上的AnyConnect NAM模組佔用。

這就是不建議將AnyConnect與Microsoft Windows本機請求方一起使用的原因。

當您使用任何AnyConnect服務時，建議同時使用NAM（當需要802.1x服務時），而不是Microsoft Windows本機請求方。

分段

分段可能發生在多個層上：

• IP
• RADIUS屬性值對(AVP)
• EAP-TLS

Cisco IOS^®交換器非常智慧。它們可以理解EAP和EAP-TLS格式。雖然交換機無法解密TLS隧道，但它負責在LAN上的可擴展身份驗證協定(EAPoL)或RADIUS中進行封裝時EAP資料包的分段、組裝和重組。

EAP協定不支援分段。以下是RFC 3748(EAP)的摘錄：

「EAP本身不支援分段；但是，單個EAP方法可以支援此功能。」

EAP-TLS就是這樣的例子。以下是RFC 5216(EAP-TLS)第2.1.5節（分段）的摘錄：

「當EAP-TLS對等體收到設定了M位的EAP-Request資料包時，它必須使用EAP-Type=EAP-TLS且無資料的EAP-Response進行響應。

這用作分段ACK。EAP伺服器必須等待，直到收到EAP-Response後再傳送另一個片段。

最後一句描述了AAA伺服器的一個非常重要的功能。他們必須等待ACK，然後才能傳送另一個EAP片段。請求方使用類似的規則：

"EAP對等體必須等待，直到它收到EAP-Request後再傳送另一個片段。"

IP層中的分段

分段只能在網路接入裝置(NAD)和AAA伺服器（用作傳輸的IP/UDP/RADIUS）之間進行。

當NAD（Cisco IOS交換器）嘗試傳送包含EAP負載（大於介面的MTU）的RADIUS要求時，會發生這種情況：

大多數Cisco IOS版本不夠智慧，不會嘗試組合通過EAPoL接收的EAP資料包，並將它們合併到可以容納通向AAA伺服器的物理介面的MTU的RADIUS資料包中。

AAA伺服器更加智慧（如下一節所示）。

RADIUS中的分段

這實際上不是任何形式的分裂。根據RFC 2865，單個RADIUS屬性最多可以有253位元組的資料。因此，EAP負載始終以多個EAP消息RADIUS屬性傳輸：

這些EAP-Message屬性由Wireshark重新組合併解釋（「最後段」屬性顯示整個EAP資料包的負載）。

EAP資料包中的Length報頭等於1,012，傳輸它需要四個RADIUS AVP。

EAP-TLS中的分段

從同一個螢幕截圖中，您可以看到：

• EAP資料包長度為1,012
• EAP-TLS長度為2,342

這表示它是第一個EAP-TLS片段，請求方期望更多，如果您檢查EAP-TLS標誌，可以確認這一點：

此類分段最常見於：

• AAA伺服器傳送的RADIUS Access-Challenge，該伺服器攜帶帶有整個鏈的安全套接字層(SSL)伺服器證書的EAP請求。
• NAD傳送的RADIUS Access-Request ，它攜帶帶有整個鏈的SSL客戶端證書的EAP-Response。

EAP-TLS片段確認

如前所述，必須在傳送後續片段之前確認每個EAP-TLS片段。

以下是範例（請求方和NAD之間EAPoL的封包擷取）：

EAPoL幀和AAA伺服器返回伺服器證書：

• 該證書在EAP-TLS片段（資料包8）中傳送。
• 請求方確認該分段（封包9）。
• 第二個EAP-TLS片段由NAD（資料包10）轉發。
• 請求方確認該分段（封包11）。
• 第三個EAP-TLS片段由NAD（資料包12）轉發。
• 請求方不需要承認這一點；而是使用從封包13開始的使用者端憑證進行。

以下是封包12的詳細資訊：

您可以看到Wireshark重組了資料包8、10和12。

EAP片段的大小為1,002、1,002和338，這使得EAP-TLS消息的總大小為2342。

在每個片段中通告總EAP-TLS消息長度。如果檢查RADIUS封包（在NAD和AAA伺服器之間），可以確認這點：

RADIUS封包4、6和8承載這三個EAP-TLS片段。前兩個片段已確認。

Wireshark能夠顯示有關EAP-TLS片段的資訊(大小：1,002 + 1,002 + 338 = 2,342)。

這個場景和例子很簡單。Cisco IOS交換機不需要更改EAP-TLS片段大小。

使用不同大小重新組裝EAP-TLS片段

試想一下，當指向AAA伺服器的NAD MTU為9,000位元組（巨型幀）時，當AAA伺服器還使用支援巨型幀的介面連線時，會發生什麼情況。大多數典型請求方都使用1Gbit鏈路連線，MTU為1,500。

在這種情況下，Cisco IOS交換機執行EAP-TLS不對稱彙編和重組，並更改EAP-TLS片段大小。

以下是由AAA伺服器（SSL伺服器憑證）傳送的大型EAP訊息的範例：

1. AAA伺服器必須傳送帶有SSL伺服器證書的EAP-TLS消息。該EAP資料包的總大小為3,000。將其封裝在RADIUS Access-Challenge/UDP/IP中後，仍然小於AAA伺服器介面MTU。傳送帶有12個RADIUS EAP-Message屬性的單個IP資料包。沒有IP或EAP-TLS分段。
   
   
2. Cisco IOS交換機收到此類資料包，將其解除封裝，並決定需要通過EAPoL將EAP傳送到請求方。由於EAPoL不支援分段，因此交換機必須執行EAP-TLS分段。
   
   
3. Cisco IOS交換機準備第一個可以容納到通向請求方(1,500)的介面MTU中的EAP-TLS片段。
   
   
4. 此片段由請求方確認。
   
   
5. 收到確認消息後，將傳送另一個EAP-TLS片段。
   
   
6. 此片段由請求方確認。
   
   
7. 最後一個EAP-TLS片段由交換機傳送。

此案例顯示：

• 在某些情況下，NAD必須建立EAP-TLS片段。
• NAD負責傳送/確認這些片段。

對於通過支援巨型幀的鏈路連線的請求方，當AAA伺服器的MTU較小時（然後Cisco IOS交換機在向AAA伺服器傳送EAP資料包時建立EAP-TLS片段），也會出現相同的情況。

RADIUS屬性已框架化 — MTU

對於RADIUS，在RFC 2865中定義有一個已框架的MTU屬性：

「此屬性指示當通過其他方式（如PPP）未協商使用者配置的最大傳輸單元。 它可用於Access-Accept資料包中。它可用於Access-Request資料包中，作為NAS向伺服器發出的首選該值提示，但伺服器不需要執行此提示。

ISE不執行提示。NAD在Access-Request中傳送的Framed-MTU值對ISE執行的分段沒有任何影響。

除了交換機上全域性啟用的巨型幀設定外，多台現代Cisco IOS交換機不允許更改乙太網介面的MTU。巨型訊框的組態會影響RADIUS Access-Request中傳送的Framed-MTU屬性的值。例如，您設定：

Switch(config)#system mtu jumbo 9000

這會強制交換器在所有RADIUS存取要求中傳送Framed-MTU = 9000。沒有巨型訊框的系統MTU也一樣：

Switch(config)#system mtu 1600

這會強制交換器在所有RADIUS存取要求中傳送Framed-MTU = 1600。

請注意，現代Cisco IOS交換機不允許您將系統MTU值降低到1,500以下。

傳送EAP片段時的AAA伺服器和請求方行為

ISE

ISE始終嘗試傳送1,002位元組的EAP-TLS片段（通常為Server Hello with Certificate）（儘管最後一個片段通常更小）。

它不遵守RADIUS Framed-MTU。無法將其重新配置為傳送更大的EAP-TLS片段。

Microsoft網路策略伺服器(NPS)

如果在NPS上本地配置Framed-MTU屬性，則可以配置EAP-TLS片段的大小。

事件：儘管在Microsoft NPS上配置EAP負載大小文章提到NPS RADIUS伺服器的已框架化MTU的預設值為1,500，但Cisco技術支援中心(TAC)實驗室已顯示，它使用預設設定傳送2,000個（在Microsoft Windows 2012資料中心上確認）。

經測試，NPS遵守上述指南中的本地設定Framed-MTU，並將EAP消息分段為Framed-MTU中設定的片段，但是未使用在訪問請求中接收的Framed-MTU屬性（與ISE/ACS中相同）。

設定此值是有效的解決方法，可以修復拓撲中出現的問題，如下所示：

Supplicant客戶端[MTU 1500] ---- ---- [MTU 9000]Switch[MTU 9000] ----- ----- [MTU 9000]NPS

目前交換器不允許您設定每個連線埠的MTU;對於6880交換機，新增此功能時附帶思科錯誤ID CSCuo26327 - 802.1x EAP-TLS不能在FEX主機埠上工作。

AnyConnect

AnyConnect傳送長度為1,486位元組的EAP-TLS片段（通常是客戶端證書）。對於此值大小，乙太網幀為1,500位元組。最後一個片段通常更小。

Microsoft Windows本機請求方

Microsoft Windows傳送1,486或1,482位元組的EAP-TLS片段（通常是客戶端證書）。對於此值大小，乙太網幀為1,500位元組。最後一個片段通常更小。

相關資訊

• 配置IEEE 802.1x基於埠的身份驗證
• 技術支援與文件 - Cisco Systems