EAP协议与EAP方法概览
EAP协议，以其独特的通信方式和灵活的应用场景，成为了网络认证的重要基石。它不依赖于IP连接，而是通过EAPoL/PPP等协议封装，在数据链路层上运行，甚至能够借助EAPoR在Radius客户端和服务器之间进行交互。这种灵活性使得EAP协议在各种网络环境中都能大放异彩。同时，EAP不仅是一个框架协议，它还定义了报文格式和交互顺序，为不同的EAP方法提供了公共功能。而验证用户身份的具体机制，则是由各种EAP方法所决定的。目前，已有多达40种EAP方法可供选择，包括IETF定义的通用方法如EAP-MD5/EAP-TLS，以及厂商私有方法如思科的LEAP。随着新的认证技术的不断涌现，这些EAP方法都能轻松融入EAP协议中，展现出其卓越的扩展性。更为重要的是，EAP-TLS等方法还支持双向认证和加密通信，进一步提升了EAP协议的安全性。这些优点使得EAP成为了801X用户身份认证协议的不二之选。
PEAP（Protected EAP）是由思科、微软和RSA公司共同开发的一种EAP方法。其独特之处在于，它通过在客户端与认证服务器之间建立TLS隧道，确保了认证过程的安全性。客户端利用TLS数字证书对认证服务器进行身份验证，而认证服务器则通过TLS隧道内的EAP方法，例如EAP-MSCHAPv2或EAP-GTC，对客户端进行身份验证。值得注意的是，某些隧道内部的EAP方法，如EAP-MSCHAPv2，支持双向认证，即同时对客户端和认证服务器进行身份验证。
相较于EAP-MD5的单向认证（仅对客户端进行身份验证，且认证信息以明文传输），PEAP提供了更高的安全性。而EAP-TLS则使用数字证书进行双向认证，要求客户端和认证服务器都持有数字证书，这需要部署一套PKI系统来颁发和维护这些证书，因此实现成本和部署复杂性相对较高。相比之下，PEAP仅要求认证服务器提供数字证书，从而降低了实现成本和部署难度。
因此，在部署801X认证时，PEAP方法通常成为首选，用于对用户进行身份认证。接下来，我们将深入探讨在801X认证中，PEAP是如何发挥其作用的。
PEAP方法认证过程详解
在801X认证体系中，Authenticator（认证器）作为网络接入服务器（NAS）负责控制Supplicant（客户端）的接入。它通过EAPoL（EAP over LAN）或EAPoR（EAP over Radius）中继Supplicant与Authentication Server（认证服务器）之间的EAP认证消息，但并不直接参与EAP方法的选取。PEAP方法的认证过程被精心设计为两个阶段。
PEAP阶段一的主要任务是在Supplicant与Authentication Server之间建立起一条TLS隧道，以确保阶段二中的EAP方法能够得到安全保护。在此阶段，Authenticator会首先发送EAP-Request/Identity消息，请求用户身份信息。Supplicant则会响应一个EAP-Response/Identity消息，包含用户的身份信息。值得注意的是，Supplicant在此时可以提供虚假身份或匿名身份，因为真正的身份验证将在阶段二中进行。一旦Authentication Server收到Supplicant的身份信息，它会发送一个负载为空的EAP-Request/EAP-PEAP Start消息，启动PEAP方法的认证流程。
EAP-Request/EAP-TLS Start消息格式
若Supplicant不支持PEAP方法，它将回复一个EAP-Response/NAK消息。若Supplicant支持PEAP，则随后Supplicant与Authentication Server将通过EAP-TLS执行标准的TLS握手，以此建立TLS隧道。在此过程中，Supplicant仅对Authentication Server进行身份验证，而无需后者提供数字证书。值得注意的是，PEAP阶段一中的TLS握手消息均被封装在TLS记录层报文中，这些报文再被封装到PEAP报文中，在Supplicant与Authentication Server之间进行交互。其具体的报文格式可参见相关图示。
EAP协议与EAP方法概览
接下来，我们探讨PEAP方法的阶段二。
阶段二报文封装格式
更直观的阶段二报文封装格式图
阶段二认证消息的封装格式实例
TLS Hello消息（Supplicant响应的）封装格式实例
在EAP协议中，每个EAP-Request消息都必须伴随一个对应的EAP-Response消息。当Authentication Server发送完最后一个EAP-Request/PEAP [TLS Change cipher Spec]消息后，Supplicant若无需向Authentication Server发送TLS消息，则会发送一个负载为空的EAP-Response/PEAP消息以作响应。此外，为了提升协商效率并节省网络带宽，多个TLS握手消息可被整合在一个TLS记录层报文中进行发送。
接下来，我们探讨PEAP方法的阶段二。
在这一阶段，TLS隧道内会依据所配置的内部EAP方法对Supplicant进行身份认证。目前，PEAP阶段二支持的认证方法包括EAP-MSCHAPvEAP-GTC和EAP-TLS。值得注意的是，阶段二中的认证消息在经过阶段一建立的TLS隧道加密和哈希计算后，会受到TLS隧道的保护。这些认证消息作为负载被封装在PEAP中，并通过支持扩展的EAP-TLV方法传输更多种类的消息，例如Result TLV和Cryptobinding TLV等。其报文封装格式如图所示：
阶段二报文封装格式
在PEAP方法的阶段二中，TLS隧道对Supplicant的身份认证消息提供了保护。这些经过TLS加密和哈希计算的认证消息，作为负载被封装在PEAP中，并通过EAP-TLV方法传输。此外，为了支持更多种类的消息传输，如Result TLV和Cryptobinding TLV等，该阶段还提供了扩展的EAP-TLV方法。其详细的报文封装格式如图所示：
更直观的阶段二报文封装格式图
请注意，不同版本的PEAP以及各厂商的具体实现，在报文格式和交互的认证消息方面可能存在细微差异。然而，PEAP的整体工作流程是保持一致的。
阶段二认证消息的封装格式实例
在PEAP的阶段二中，认证过程涉及多个消息的交互。首先，Authentication Server会向Supplicant发送一个EAP-Request/Identity消息，请求用户身份信息。Supplicant随后会回复一个EAP-Response/Identity消息，其中包含真实的用户身份。
接着，Authentication Server会选择一种内部EAP方法，如EAP-MSCHAPv2或EAP-GTC等，并通过EAP-Request/EAP-Type=X消息将该方法发送给Supplicant。如果Supplicant不支持所选的EAP方法，则会发送一条EAP-Response/NAK消息；否则，它会发送一条EAP-Response/EAP-Type=X消息作为响应。
随后，双方将开始进行内部EAP方法的消息交互。Authentication Server将对Supplicant进行身份验证，并将验证结果通过EAP-TLV/Result TLV（表示成功或失败）发送给Supplicant。Supplicant随后会对验证结果进行响应。一旦内部EAP方法的身份验证完成，TLS隧道将被拆除。
在用户身份验证成功后，双方将共同生成用于派生PMK的MSK。Authentication Server会将生成的MSK发送给Authenticator，并同时发送一个EAP-Success（明文）消息通知Authenticator认证成功。如果验证失败，则会发送EAP-Failure消息进行指示。Authenticator再将EAP-Success/EAP-Failure消息转发给Supplicant。
收到EAP-Success消息后，Authenticator与Supplicant将执行WPA/WPA2的四次握手过程，以生成会话密钥。
以上便是PEAP方法完整的认证流程概述，而阶段二中的认证细节并未详细展开具体内部EAP方法的认证流程。在阶段二中，最常采用的内部EAP方法为EAP-MSCHAPv2。对此方法感兴趣的朋友，建议查阅相关文档以深入了解其认证原理及详细过程。
