EAP分段实施和行为

简介

本文档介绍如何了解可扩展身份验证协议(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消息的示例：

1. AAA服务器必须发送带有SSL服务器证书的EAP-TLS消息。该EAP数据包的总大小为3,000。在封装到RADIUS Access-Challenge/UDP/IP后，它仍小于AAA服务器接口MTU。单个IP数据包会发送12个RADIUS EAP-Message属性。没有IP或EAP-TLS分段。
   
   
2. Cisco IOS交换机接收此类数据包，解封该数据包，并决定EAP需要通过EAPoL发送给请求方。由于EAPoL不支持分段，因此交换机必须执行EAP-TLS分段。
   
   
3. Cisco IOS交换机准备第一个EAP-TLS分段，该分段可以适合到指向请求方(1,500)的接口的MTU中。
   
   
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访问请求中发送的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字节。最后一个片段通常较小。

相关信息

• 配置基于 IEEE 802.1x 端口的身份验证
• 技术支持和文档 - Cisco Systems