排除EAP分段实施和行为故障

简介

本文档介绍如何了解可扩展身份验证协议(EAP)会话并对其进行故障排除。

先决条件

要求

Cisco 建议您了解以下主题：

• EAP和EAP-TLS协议
• 思科身份服务引擎(ISE)的配置
• Cisco Catalyst交换机的CLI配置

要理解本文，必须充分了解EAP和EAP-TLS。

使用的组件

本文档不限于特定的硬件和软件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

本文档的各部分专门介绍以下方面的内容：

• 身份验证、授权和记帐(AAA)服务器返回可扩展身份验证协议 — 传输层安全(EAP-TLS)会话的服务器证书时的行为。
• 请求方返回EAP-TLS会话的客户端证书时的行为。
• 同时使用Microsoft Windows本地请求方和Cisco AnyConnect网络访问管理器(NAM)时的互操作性。
• 网络接入设备执行的IP、RADIUS和EAP-TLS分段和重组流程。
• RADIUS Framed-Maximum Transmission Unit(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本机请求方是为了使用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原生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请求后再发送另一个分段。"

IP层分段

分段只能在网络接入设备(NAD)和AAA服务器（用作传输的IP/UDP/RADIUS）之间发生。

当NAD（Cisco IOS交换机）尝试发送包含EAP负载的RADIUS请求时，会出现这种情况，该负载大于接口的MTU:

大多数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访问质询，该质询带有安全套接字层(SSL)服务器证书和整个链的EAP请求。
• 由NAD发送的RADIUS访问请求，该请求携带带有整个链的SSL客户端证书的EAP响应。

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服务器也使用支持巨型帧的接口连接时会发生什么情况。大多数典型的Supplicant客户端都使用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属性Framed-MTU

对于RADIUS，RFC 2865中定义了Framed-MTU属性：

“此属性指示为用户配置的最大传输单元，当它不是通过其他方式（例如PPP）协商时。 它可用于Access-Accept数据包中。它可用于Access-Request数据包中，作为NAS向服务器发出的首选该值的提示，但并不要求服务器遵循该提示。"

ISE不执行提示。NAD在访问请求中发送的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 Access-Requests中发送Framed-MTU = 1600。

请注意，现代Cisco IOS交换机不允许将系统MTU值降低到1,500以下。

发送EAP分段时的AAA服务器和请求方行为

ISE

ISE始终尝试发送1,002字节长的EAP-TLS分段（通常为带证书的服务器呼叫）（尽管最后一个分段通常较小）。

它不遵守RADIUS Framed-MTU。无法将其重新配置为发送更大的EAP-TLS分段。

Microsoft网络策略服务器(NPS)

如果在NPS上本地配置Framed-MTU属性，则可以配置EAP-TLS分段的大小。

事件：虽然在Microsoft NPS上配置EAP负载大小文章提到NPS RADIUS服务器的框架MTU的默认值为1,500，但思科技术支持中心(TAC)实验室已显示，它使用默认设置发送2,000（在Microsoft Windows 2012数据中心上确认）。

经测试，NPS遵守根据前述指南在本地设置Framed-MTU，并将EAP消息分段为Framed-MTU中设置的片段，但不使用在访问请求中接收的Framed-MTU属性（与ISE/ACS中相同）。

设置此值是一种有效的解决方法，可以解决拓扑中的以下问题：

请求方[MTU 1500] ---- ---- [MTU 9000]交换机[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