mschapv1 vs mschapv2 && pap && chap
PAP认证
PAP协议很简单，其实就是在PPP建立过程中，PC需要将用户名和密码发送给NAS，NAS来验证用户名和密码的合法性，这个传送过程是明文传送的，这也是大家所谓的不安全，当然这部分确实是不安全的，IETF也建议不要使用PAP认证，在RFC-1334中明确了其已经被1994取代，也就是后面要讲到的CHAP
PAP 认证的流程
- PC <——> NAS：这部分是不是明文的那要看你PAP是在什么链路上运行的，如果是PPP协议，那可能是明文传送密码给NAS的，但是如果PAP认证协议是跑在TTLS（802.1X安全隧道中），那么外层隧道是加密的，所以即使PAP使用的是明文密码，对于隧道外来说仍然是密文的，所以简单的说PC和NAS之间的PAP是明文密码不安全的，是比较片面的；
- NAS <——>AAA：这部分就更不会是明文的了，NAS如果使用PAP认证协议找Radius服务器进行认证，那么他会将密码首先加密，放到User-Password属性中，交给Radius服务器，Radius服务器再进行解密获取原始密码，跟数据库中的密码进行比对得到认证结果； 所以我们常说的PAP认证使用明文密码，是不安全的，一般指的是1中PC和NAS之间的PAP认证协议，而Radius的PAP认证中并没有使用明文密码，是比较安全的（当然Radius的PAP密码保护使用了可逆的加密算法，安全程度不是太高）。
关于Radius协议中PAP认证协议的密码是如何加密的，具体实现可以查看RFC-2865， 大体是将用户密码按照16字节截断为p1、p2……，然后依次进行加密，形成密文c1+c2+….+cn 其中 c1 = p1 XOR MD5(secret + Authenticator) c2 = p2 XOR MD5(secret + c1) …. cn = pi XOR MD5(secret + c(n-1))
当Radius服务器收到认证请求的时候，使用和NAS配置的共享密钥Secret，加上包头中的Authenticator，就能解密出原始的明文密码
CHAP 认证
CHAP(Challenge Handshake Authentication Protocol）询问握手认证协议，或者叫做冲击握手认证协议，属于三次握手协议，相对于PAP来说安全性高一些，防止了重放攻击，因为每次询问内容是不同的
- PC <——> NAS：所说的三次握手也是这个过程，当链路建立以后，首先NAS会向PC发送一个Challenge字符串，这个字符串是随机的，PC利用用户输入的明文密码和Challenge使用单向加密算法加密后将用户名和密文密码一同发送给NAS设备；
- NAS <——> AAA：NAS设备收到PC发送的认证请求后，将用户名和密码分别放到User-Name和CHAP-Passowrd 中，另外必须携带Challenge给Radius服务器，否则Radius服务器无法验证密码，这个Challenge有两种方式，第一个是放到属性CHAP-Challenge中，如果Challenge长是16字节，也可以直接放到Radius包头中的Authenticator中，NAS将这些内容发送给Radius服务器，Radius服务器本地获取明文密码，加上Challenge后用相同的算法得到密文，与CHAP-Password对比得到结果； 所以看到三次握手指的是PC和NAS之间，而NAS和AAA服务器之间和PAP还是一样，NAS向AAA服务器发送一次请求，里面携带了所有数据，AAA根据这些数据判断将验证结果发送给NAS
Radius对于CHAP-Password解析如下：
- 第一个字节是CHAP Identifier，是PC发送给NAS的Response的ID值；
- 计算：C = MD5(CHAP-Ident + 明文密码 + Challenge)计算的到密文；
- 将C与CHAP-Password从第二字节开始的内容对比
关于Radius对于PAP和CHAP的处理，RFC-2865中有如下描述：
FreeRadius的处理一般是复杂的协议首先确定，比如首先在属性中查找是否有CHAP-Password属性，如果有的话，就默认是CHAP认证，试图使用CHAP认证方式，如果没有找到CHAP-Password，那么看是否有User-Password，如果有User-Password就认为是PAP认证方式，使用PAP模块进行认证
CHAP的特点：
- 该认证方法依赖于只有认证者和对端共享的密钥，密钥不是通过该链路发送的。
- 虽然该认证是单向的，但是在两个方向都进行 CHAP 协商，同一密钥可以很容易的实现相互认证。
- 由于 CHAP 可以用在许多不同的系统认证中，因此可以用 NAME 字段作为索引，以便在一张大型密钥表中查找正确的密钥，这样也可以在一个系统中支持多个 NAME/ 密钥对，并可以在会话中随时改变密钥。
- CHAP 要求密钥以明文形式存在，无法使用通常的不可回复加密口令数据库。
- CHAP 在大型网络中不适用，因为每个可能的密钥由链路的两端共同维护。
MS-CHAP 认证
MS-CHAP(MicroSoft Challenge Handshake Authentication Protocol)微软询问握手认证协议，也就是微软定义的CHAP协议，定义在RFC-2433/2548中
在上面CHAP介绍中了解到，Radius服务器必须有明文密码才能验证CHAP-Password的合法性，因为需要将明文密码经过相同的MD5得到密文与CHAP-Password进行比较，而这个明文密码的获取是微软所不允许的，也就是说你通过MS提供的任何API都不能获取系统明文密码（不管是本地还是AD域，MS都不允许获取明文密码，MS压根都没存明文密码），只能获取到密码MD4后的密文（MS这种考虑也是很合理的），既然获取不了明文密码，那就用不了CHAP了，而直接用PAP的话安全程度又太低，所以微软干脆提出了MS-CHAP认证协议。从RFC-2433中CHAP和MS-CHAP区别可以看到：
MS-CHAP有2个版本，V1和V2，其中为了解决上面CHAP明文密码问题，MS首先提出了V1版本，其基本思想就是发送的密码不是CHAP中MD5（明文密码 + Challenge）这种方式了，而是直接使用MS加密后的密文，这就有一个要求，就是PC发送密码的时候用的就是单向加密后的密码再加密，所以认证端也不用明文密码（或者有明文的话，使用明文进行和MS一样的加密获取密文）进行相同操作，然后进行比较。现在使用V1版本比较少了，大多数都使用V2版本，所以下面主要分析V2版本，V2版本比V1版本主要是加入了双向验证，也就是PC也要验证服务器
MS-CHAPv2工作模式主要分为两种：
- PC <——> NAS <——> AAA：这是所谓的MS-CHAPv2认证流程，NAS将Challenge发送给PC，PC响应后NAS再组织Radius属性（MSCHAP-Challenge + MSCHAP-Response），然后Radius服务器根据获取到的密码（可能是明文、LM-Password、NT-Password）加上MSCHAP-Challenge计算获取密文同收到的MSCHAP-Response进行比较；
- PC <————————>AAA：这是EAP/MS-CHAPv2，是基于EAP框架的MS-CHAPv2认证，EAP框架的作用就是透明化NAS设备，NAS设备只做翻译透传工作，而具体的认证协议协商是由Radius服务器和PC完成，所以Radius服务器需要完成1中NAS部分工作，主要是Challenge的发送，然后接收PC的响应，注意这里Radius接收到的不是1中的（MSCHAP-Challenge + MSCHAP-Response），而是原始的MS-CHAPv2的数据包，需要进行解析，所以EAP/MS-CHAPv2的实现对于Radius服务器来说更为复杂，freeRadius在EAP/MS-CHAPv2使用了将MS-CHAPv2数据包转换为（MSCHAP-Challenge + MSCHAP-Response）递归调用MS-CHAP模块来实现的
来看下chatgpt是 怎样回答这个问题的！！
EAP的出现
从上述几种认证方式可以看出， NAS作为中间人得了解PC客户端和AAA服务器的不同认证方式，比如基于PPP的PAP/CHAP，它还得了解如何将这些基于PPP等网络之上的认证协议转化为RADIUS认证协议（比如PAP转为User-Password属性，CHAP转为CHAP-Password和CHAP-Challenge属性），一旦要支持新的认证方式，参与认证的三方都得进行修改和支持，这里面作为发起人的PC和作为认证结束端的RADIUS是必须支持MS-CHAP，但是作为中间人的NAS网络设备若是能够透明的转发PC——AAA之间的数据包， 则无需修改NAS， 最终出现了EAP 协议
EAP（Extensible Authentication Protocol）可扩展认证协议，RFC-3748定义，是一种普遍使用的支持多种认证方法的认证框架协议，主要用于网络接入认证， EAP协议一般运行在数据链路层上， 与其说EAP是一个认证协议不如说EAP是一个认证框架，EAP本身不是认证协议，它自己不支持认证功能，它是为了承载多种认证协议而生的，EAP为扩展和协商认证协议提供了一个标准
以常用的802.1X为例，它就是使用了EAP协议:
- 在请求者和认证者之间， EAP 协议报文使用EAPOL 封装格式，直接承载于LAN 环境中
- 在认证者和AAA服务器之间， EAP 协议报文可以使用EAPOR（EAP over RADIUS）封装格式，承载于RADIUS 协议中；也可以由认证者端终结转换，而在认证者与AAA服务器之间传送PAP协议报文或CHAP等协议报文
EAP上面承载的认证协议对NAS是透明的，NAS设备不需要了解，也不需要支持，它只需要支持EAP即可
5. EAP认证
EAP（Extensible Authentication Protocol），可扩展认证协议，是一种普遍使用的支持多种认证方法的认证框架协议，主要用于网络接入认证， 该协议一般运行在数据链路层上，即可以直接运行于PPP或者IEEE 802之上，不必依赖于IP， EAP可应用于无线、有线网络中。
EAP的架构非常灵活，在Authenticator（认证方）和Supplicant（客户端）交互足够多的信息之后，才会决定选择一种具体的认证方法，即允许协商所希望的认证方法。认证方不用支持所有的认证方法，因为EAP架构允许使用一个后端的认证服务器（也就是AAA服务器），此时认证方将在客户端和认证服务器之间透传消息
该协议支持重传机制，但这需要依赖于底层保证报文的有序传输，EAP不支持乱序报文的接收。协议本身不支持分片与重组，当一些EAP认证方法生成大于MTU（Maximum Transmission Unit，最大传输单元）的数据时，需要认证方法自身支持分片与重组。
现在大约有40种不同的方法。IETF的RFC中定义的方法包括：EAP-MD5, EAP-OTP, EAP-GTC, EAP-TLS, EAP-SIM,和EAP-AKA, 还包括一些厂商提供的方法和新的建议, WPA和WPA2标准已经正式采纳了5类EAP作为正式的认证机制, 无线网络中常用的方法包括EAP-TLS, EAP-SIM, EAP-AKA, PEAP, LEAP,和EAP-TTLS
Here are some reasons why MSCHAPv2 is considered more secure:
Here are some reasons why MSCHAPv2 is considered more secure: Stronger cryptographic algorithms: MSCHAPv2 employs stronger cryptographic algorithms, such as the HMAC-SHA-1 algorithm, which provides more robust integrity and protection against tampering compared to the weaker cryptographic algorithms used in MSCHAPv1. Mutual authentication: MSCHAPv2 supports mutual authentication, which means both the client and the server authenticate each other during the authentication process. This prevents man-in-the-middle attacks, where an attacker intercepts the authentication process
and impersonates either the client or the server. Improved password security: MSCHAPv2 enhances the security of password-based authentication by employing a three-way handshake mechanism. It uses the NT-Password hash instead of sending the actual password in plaintext,
making it less susceptible to password attacks, such as offline dictionary attacks or rainbow table attacks. Protection against replay attacks: MSCHAPv2 includes protections against replay attacks by incorporating a challenge-response mechanism that involves the generation of unique session keys. These session keys ensure that each authentication
session is unique and cannot be replayed by an attacker. Enhanced key derivation: MSCHAPv2 improves the key derivation process by utilizing a stronger key generation algorithm. This makes it more difficult for an attacker to derive the encryption keys used for securing the communication channel. Compatibility with modern security standards: MSCHAPv2 aligns with modern security standards and protocols, making it more interoperable with other security mechanisms and authentication protocols. This compatibility enhances overall security
when used in conjunction with other security measures. Overall, the combination of stronger cryptographic algorithms, mutual authentication, improved password security, protection against replay attacks, enhanced key derivation, and compatibility with modern security standards makes MSCHAPv2
more secure than its predecessor, MSCHAPv1.
message interaction process between MS-CHAPv1 and MS-CHAPv2:
MS-CHAPv1 Message Interaction Process: Client Initiation: The client initiates the authentication process by sending a connection request to the server, including the user's identity (username) and the server's identity. Server Challenge: Upon receiving the client's request, the server generates a random number called the "challenge" and sends it back to the client. Client Response: The client combines the received challenge with the user's password using a one-way hash function to create an encrypted response. This response is sent back to the server. Authentication Check: The server receives the client's response and performs the following steps: a. It retrieves the user's password from its database using the provided username. b. The server independently generates an expected response using the retrieved password and the received challenge. c. The server compares the expected response with the client's response. If they match, the authentication is considered successful. Mutual Authentication: After successful authentication, the server sends an authentication request to the client, which includes the server's challenge. Client Response and Mutual Authentication Check: The client generates a response by combining the received challenge with the user's password using a one-way hash function.
The client sends this response back to the server, which checks it against the expected response derived from the server's challenge and the user's password. Session Key Derivation: Upon successful mutual authentication, both the client and server derive a session key from the password and challenges exchanged during the previous steps. This session key is used to encrypt further communication. MS-CHAPv2 Message Interaction Process: The message interaction process for MS-CHAPv2 is similar to MS-CHAPv1, but with a few notable improvements in security: Client Initiation: The client initiates the authentication process by sending a connection request to the server, including the user's identity (username) and the server's identity. Server Challenge: Upon receiving the client's request, the server generates a random number called the "challenge" and sends it back to the client. Client Response: The client combines the received challenge with the user's password using a stronger cryptographic algorithm to create an encrypted response. This response is sent back to the server. Authentication Check: The server receives the client's response and performs the following steps: a. It retrieves the user's password from its database using the provided username. b. The server independently generates an expected response using the retrieved password, the received challenge, and additional hashing rounds. c. The server compares the expected response with the client's response. If they match, the authentication is considered successful. Mutual Authentication: After successful authentication, the server sends an authentication request to the client, which includes the server's challenge. Client Response and Mutual Authentication Check: The client generates a response by combining the received challenge with the user's password, additional hashing rounds, and a new session-specific cryptographic salt.
The client sends this response back to the server, which checks it against the expected response derived from the server's challenge, the user's password, and the session-specific cryptographic salt. Session Key Derivation: Upon successful mutual authentication, both the client and server derive a session key from the password, challenges, and other parameters exchanged during
二、EAP协议简述
- EAP协议是IEEE 802.1x认证机制的核心，它将实现细节交由附属的EAP方法协议完成，如何选取EAP方法由认证系统特征决定。这样实现了EAP的扩展性及灵活性。
- EAP支持多种链路层认证方式，下面选取几种典型的认证方式进行叙述。
三、EAP-TLS
- EAP-TLS使用TLS协议作为认证方式，TLS有很多优点，所以EAP选用了TLS作为基本的安全认证协议，并为TTLS和PEAP建立安全隧道，TLS已经标准化，并且进过了长期应用和分析，都没有发现明显的缺点。
- TLS认证是基于Client和Server双方互相验证数字证书的，是双向验证方法，首先Server提供自己的证书给Client，Client验证Server证书通过后提交自己的数字证书给Server，客户端的证书可以放到本地、放到key中等等.
- TLS有一个缺点就是TLS传送用户名的时候是明文的，也就是说抓包能看到EAP-Identity的明文用户名。
- TLS是基于PKI证书体系的，这是TLS的安全基础，也是TLS的缺点，PKI太庞大，太复杂了，如果企业中没有部署PKI系统，那么为了这个认证方法而部署PKI有些复杂，当然，如果企业已经部署了PKI，那么使用EAP-TLS还是不错的选择。
四、EAP-TTLS和EAP-PEAP
- 正因为TLS需要PKI的缺点，所以设计出现了TTLS和PEAP，这两个协议不用建立PKI系统，而在TLS隧道内部直接使用原有老的认证方法，这保证了安全性，也减小了复杂度。
- 把TTLS和PEAP放到一起介绍的原因是他们俩很像，两个都是典型的两段式认证，在第一阶段建立TLS安全隧道，通过Server发送证书给Client实现Client对Server的认证（这里TTLS和PEAP仍然使用证书，但是这里的证书都是服务器证书，管理起来比TLS客户端证书要简单那的多）；当安全隧道一旦建立，第二阶段就是协商认证方法，对Client进行认证（Android中称为阶段2身份认证）。
- PEAP之所以叫Protected EAP，就是它在建立好的TLS隧道之上支持EAP协商，并且只能使用EAP认证方法，这里为什么要保护EAP，是因为EAP本身没有安全机制，比如EAP-Identity明文显示，EAP-Success、EAP-Failed容易仿冒等，所以EAP需要进行保护，EAP协商就在安全隧道内部来做，保证所有通信的数据安全性。
五、MSCHAPv2
- Microsoft 质询握手身份验证协议 (MS-CHAP v2) 是一个通过单向加密密码进行的相互身份验证过程。
- MSCHAPv2是一种典型的阶段2身份认证方式，但是不够安全。可以将MSCHAPv2作为EAP-TLS、EAP-TTLS、EAP-PEAP的内部协议结合使用。
六、GTC
- GTC是Cisco提供的一种token令牌认证方式。可以将GTC作为EAP-TLS、EAP-TTLS、EAP-PEAP的内部协议结合使用。
