简介
本文档介绍如何了解可扩展身份验证协议(EAP)会话并对其进行故障排除。讨论以下问题:
- 当身份验证、授权和记帐(AAA)服务器返回可扩展身份验证协议传输层安全(EAP-TLS)会话的服务器证书时的行为
- 请求方返回EAP-TLS会话的客户端证书时的行为
- 同时使用Microsoft Windows本地请求方和Cisco AnyConnect网络访问管理器(NAM)时的互操作性
- IP、RADIUS和EAP-TLS中的分段以及网络访问设备执行的重组过程
- RADIUS Framed-Maximum Transmission Unit(MTU)属性
- AAA服务器执行EAP-TLS数据包分段时的行为
先决条件
要求
Cisco 建议您了解以下主题:
- EAP和EAP-TLS协议
- 思科身份服务引擎(ISE)的配置
- Cisco Catalyst交换机的CLI配置
要理解本文,必须充分了解EAP和EAP-TLS。
服务器返回的证书链
AAA服务器(访问控制服务器(ACS)和ISE)始终返回EAP-TLS数据包的完整链,其中包含服务器Hello和服务器证书:

ISE身份证书(公用名(CN)=lise.example.com)与签名CN=win2012,dc=example,dc=com的证书颁发机构(CA)一起返回。ACS和ISE的行为相同。
请求方返回的证书链
Microsoft Windows本地请求方
为使用EAP-TLS而配置的Microsoft Windows 7本地请求方,无论是否有“简单证书选择”,都不会发送客户端证书的完整链。即使客户端证书由与服务器证书不同的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本地请求方以及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对等体收到EAP-Request数据包时,它必须使用EAP-Type=EAP-TLS且无数据的EAP-Response进行响应。这用作分段ACK。EAP服务器必须等待,直到收到EAP响应,才能发送另一片段。”
最后一句描述了AAA服务器的一个非常重要的功能。它们必须等待ACK才能发送另一个EAP分段。请求方使用类似规则:
"EAP对等体必须等到收到EAP请求后才能发送另一个分段。"
IP层中的分段
分段仅可在网络接入设备(NAD)和AAA服务器(用作传输的IP/UDP/RADIUS)之间发生。 当NAD(Cisco IOS交换机)尝试发送包含EAP负载的RADIUS请求时,会发生这种情况,该负载大于接口的MTU:

大多数Cisco IOS版本不够智能,不会尝试组合通过EAPoL接收的EAP数据包,并将它们合并到RADIUS数据包中,该RADIUS数据包可以适用于指向AAA服务器的物理接口的MTU。
AAA服务器更智能(如下节所示)。
RADIUS中的分段
这并不是任何一种分裂。根据RFC 2865,单个RADIUS属性最多可以包含253字节的数据。因此,EAP负载始终在多个EAP-Message 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服务器也使用支持巨帧的接口连接时会发生什么情况。大多数典型的请求方都使用MTU为1,500的1Gbit链路连接。
在这种情况下,Cisco IOS交换机执行EAP-TLS“assymetric”程序集并重新组装并更改EAP-TLS分段大小。以下是AAA服务器(SSL服务器证书)发送的大型EAP消息的示例:
- AAA服务器必须发送带有SSL服务器证书的EAP-TLS消息。该EAP数据包的总大小为3,000。在封装到RADIUS Access-Challenge/UDP/IP后,它仍小于AAA服务器接口MTU。单个IP数据包会发送12个RADIUS EAP-Message属性。没有IP或EAP-TLS分段。
- Cisco IOS交换机接收此类数据包,解封该数据包,并决定EAP需要通过EAPoL发送给请求方。由于EAPoL不支持分段,因此交换机必须执行EAP-TLS分段。
- Cisco IOS交换机准备第一个EAP-TLS分段,该分段可以适合到指向请求方(1,500)的接口的MTU中。
- 此分段由请求方确认。
- 收到确认后,将发送另一个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访问请求中发送的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分段(通常为带证书的服务器Hello)(尽管最后一个分段通常较小)。 它不遵守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 201上确认)2数据中心)。
经测试,NPS尊重根据前述指南在本地设置Framed-MTU,并将EAP消息分段为Framed-MTU中设置的大小。但是,不使用在访问请求中收到的Framed-MTU属性(与在ISE/ACS上相同)。
设置此值是解决拓扑中类似以下问题的有效解决方法:
请求方[MTU 1500] — [MTU 9000]交换机[MTU 9000] — [MTU 9000]NPS
目前,交换机不允许您设置每个端口的MTU;对于6880交换机,此功能添加了Cisco Bug ID CSCuo26327 - 802.1x EAP-TLS not working on FEX host ports。
AnyConnect
AnyConnect发送长度为1,486字节的EAP-TLS分段(通常为客户端证书)。对于此值大小,以太网帧为1,500字节。最后一个片段通常较小。
Microsoft Windows本地请求方
Microsoft Windows发送长度为1,486或1,482字节的EAP-TLS分段(通常为客户端证书)。对于此值大小,以太网帧为1,500字节。最后一个片段通常较小。
相关信息