简介
本文档介绍如何了解可扩展身份验证协议(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消息的示例:
- AAA服务器必须发送带有SSL服务器证书的EAP-TLS消息。该EAP数据包的总大小为3,000。将其封装到RADIUS Access-Challenge/UDP/IP中后,仍然小于AAA服务器接口MTU。发送一个具有12个RADIUS EAP-Message属性的IP数据包。没有IP或EAP-TLS分段。
- Cisco IOS交换机收到此类数据包,将其解封,然后确定需要通过EAPoL将EAP发送给请求方。由于EAPoL不支持分段,因此交换机必须执行EAP-TLS分段。
- Cisco IOS交换机准备第一个可以适合到通向请求方(1,500)的接口的MTU的EAP-TLS分段。
- 此片段由请求方确认。
- 收到确认消息后,将发送另一个EAP-TLS分段。
- 此片段由请求方确认。
- 最后一个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字节。最后一个片段通常更小。
相关信息