eap-peap-with-mschapv2-decrypted-and-decoded

转自https://community.cisco.com/t5/security-blogs/eap-peap-with-mschapv2-decrypted-and-decoded/ba-p/3106761

EAP-PEAP - phase1 packet by packet

This part is really simple, there is already a lot of documents on the Internet. So I will not cover this part in details.

Let's focus on eap.pcap.

Packet1

Authenticator sending EAP  Request Identity.

Packet2

Right  now popup appears on Supplicant and user provides username (cisco) and  password (cisco). Supplicant is responding with EAP Response with  Identity “cisco”. This packet is received on NAD, EAP is decapsulated  from EAPOL, encapsulated into Radius and sent to AS. All further  communication uses the same transport mechanism. EAP session is built  between supplicant and AS.

Packet3

AS sending EAP Request with Type “EAP-PEAP”

Packet4

Supplicant  sending EAP Response with Type “EAP-PEAP” - which means that method is  accepted by supplicant. In the same packet we already SSL payload  (Client Hello)

Packet5,6

AS responds with SSL Server Hello  with it's certificate attached. EAP framework does not support  fragmentation, each EAP method need to implement that on it's own.  EAP-PEAP supports fragmentation (it's not specified for EAP-PEAP but for  EAP-TLS certificate can be up to 16MB in size - RFC5216).

Let's look at packet 5:

We  have EAP-Length=1012 (packet 5 length). Then More Fragments = 1. And  EAP-TLS-Length=1210 – which is total size of all fragments.

At this stage AS already agrees on SSL cipher suit and send random session id.

Packet7

Supplicant  already has all the information (server certificate, random session id)  to generate and encrypt session key using AS public key.

Packet8

AS acknowledges that and finished SSL session establishment.

SSL tunnel is complete.

Packet9

Supplicant send empty EAP Reponse with Type “EAP-PEAP” (this is not SSL encrypted packet). This is in accordance to http://tools.ietf.org/html/draft-kamath-pppext-peapv0-00 (Appendix A Examples) to acknowledge SSL tunnel establishment and end of phase1.

If  you look for the rest packets in eap.pcap – they are encrypted by SSL.  That is used to protect phase2 which is used for Mschapv2 peer  authentication.

Except the last packet 18. This is EAP  Response with Code 3 (Success). It can be read by NAD to verify that  supplicant has been authenticated successfully. But NAD can and usually  does read that information from Radius header (Access-Accept Code) along  with other Radius authorization attributes.

EAP-PEAP - phase2 packet by packet

Theory

Can  we decrypt that SSL packets easily ? Of course for that we need server  private key. It's not always so easy. If you troubleshoot production  network it's sometimes easier and more secure to generate and install  self signed certificate on AAA server and use that one  - just for this  process.

It  also depends on cipher suits. If DH (Diffie-Hellman) cipher suit  is  being used we can not, because DH is used to establish secure key in  unsecure medium. We would need to get dynamically generated secret  values (a,b) from supplicant and AS to decrypt such a session. Of course  it's possible but quite difficult to perform.

But if RSA based cipher suit is used – it's much easier. All we need is a private key of server (AS).

Fortunately most AAA servers use RSA ciphers. Let's check default configuration for ACS:

Packet4: Ciphers proposed by client

Packet5: Cipher chosen by server:

So the client propose all types of ciphers but server accept TLS_RSA_WITH_3DES_EDE_CBC_SHA.

We can decrypt it easily then.

Dump.pl script

Wireshark has the option to decrypt SSL traffic:

http://wiki.wireshark.org/SSL

But  unfortunately it works only for SSL encapsulated in TCP session. It  uses TCP/IP headers to track communication (server->client,  client->server). And we have SSL encapsulated in EAP in EAPOL. Not  even IP layer.

So  i wrote perl script (dump.pl) which search for SSL session encapsulated  in other protocols. Then it creates dummy TCP session with that SSL  payload. Tracking of session is based on L2 (ethernet address)

The output of the script is ssl.pcap file which can be decrypted by wireshark.

More info/details about script at the end of this document.

Wireshark configuration

After we have ssl.pcap it's time to configure wireshark:

# cat ~/.wireshark/preferences | grep ssl

ssl.desegment_ssl_records: TRUE

ssl.desegment_ssl_application_data: TRUE

ssl.keys_list:0.0.0.0,443,http,/path/to/key/server.pem

ssl.debug_file: /tmp/debug-ssl.txt

server.pem is base64 encoded unprotected server key, example:

-----BEGIN RSA PRIVATE KEY-----

MIICXgIBAAKBgQDRXuIPFFl6BwMgSyKixcw0wJZ+dLsIfLFrxGLR5PmdPUC9GVuA

…...............

w1nlHxzUKSfOzAGOEGE4gj5gp8V/rGP69PpWVWSxEgCG6Q==

-----END RSA PRIVATE KEY-----

Remember  to compile wireshark with gnutls and gcrypt support. Gcrypt was not  default on my gentoo box and it did not work (read debugs to verify).

Right now – when opening ssl.pcap in wireshark we have SSL payload decrypted.

Packet analysis

The bad news is that wireshark does not understand Mschapv2 nor EAP encapsulated Mschapv2.

We need to decode it manually.

At  this stage we will continue packet reading. Previously we have finished  on packet9 which was not SSL encrypted (we will not see that packet in  ssl.pcap). No we will read ssl.pcap file.

Packet9

This is first SSL payload. It's identity request send from AS:

Packet10

Supplicant respond with response with identity “cisco”.

This is first surprise. Why we do not see full EAP packet here ?

This  is intended for packet 9 and 10. Full EAP packet would need to have  type field with specific value (for example Mschapv2 as you will see it  later). But at this stage we do not know that. After AS gets client  identity it can choose which inner method to use based on that identity -  and propose that in packet 11.

Does  cisco ACS use that ? No, it can read Radius-IETF User-Name attribute  from first Access-Request - then based on that username put that session  into specific service. That is controlled in Access Policies / Service  Selection Rules, example:

In specific  service (POD11_RADIUS) we might have enabled for example just EAP-GTC as  inner method for EAP-PEAP - then in packet11 that will be offer send to  supplicant:

Packet11

In  our case AS sends Mschapv2 challenge (default setting) . Indeed we can  see here the first field is Type as described above. But then we have  Identifier, Length, Opcode – as described in: http://tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2-02 (EAP MS-CHAP-v2 Packet Format).

After fixed length value-size we have 16bytes of challenge.

Last we have identity of authentication server (AS) which is “acs” in our scenario.

That type of frame is not consistent with most EAP-PEAP drafts (different order of fields, no code filed). Why ?

The response is found in http://tools.ietf.org/html/draft-kamath-pppext-peapv0-00

The [PEAP] specification requires that EAP packets be tunneled within a TLS channel

in their entirety. However, the Windows XP SP1 implementation of PEAP does not

include an EAP header on packets sent within the TLS channel, except for EAP

Extension packets (Type 33), where the complete header is sent.  As a result, for

EAP Types other than 33, the Code, Identifier, and Length fields are not sent,

but rather EAP packets sent within the PEAP tunnel begin with the Type field.

That is also not entirely true, also we are using Windows XP SP3 not SP1. But from now on the first field will be always Type.

Packet12

If  supplicant have a correct password it can create correct response. This  packet is pretty similar, but with Opcode=2 (response) and 49 bytes of  challenge response which consists of:

16 octets: Peer-Challenge

8 octets: Reserved, must be zero

24 octets: NT-Response

1 octet : Flags

Last part of this packet is Name which represents name of peer's user account name (“cisco”).

Packet13

AS  performs similar computation to count correct response. If it matches  with received one it sends Success Request Packet (Opcode=3). Payload of  that packet (42 Bytes) is message authenticator. This is used by  supplicant for verification.

Packet14

If  supplicant verify message authenticator it sends empty Success Response  Packet (Opcode=3). In general this is enough. We are already  authenticated.

Packet15

This  is moment when EAP-extension is being used. AS sends Extension Request  Packet with Type = 33 (EAP extensions). It has only one mandatory AVP  which is ACK result.

(more details in http://tools.ietf.org/html/draft-kamath-pppext-peapv0-00).

Packet16

Supplicant respond with with the same packet but opcode = 2 (response).

The last 2 packets is the additional step to acknowledge the successful result of authentication.

I wound not expect to see this step for linux/opensource supplicants.

Summary

Identities

We have several peer identities being sent, all of them can differ:

• outer      identity being send in packet2 in EAPOL identity response (“cisco”)
• inner      identity being send inside SSL tunnel in packet10 as identity response (“cisco”)
• inner      identity being send inside SSL tunnel in packet12 as challange-response (“cisco”)

We also have authentication server identity being send in packet 11 as challenge-request (“acs”)

We also have User-Name AVP in all Access-Requests for Radius which tunnel EAP frames to AS.

This creates some potential misinterpreting and bugs in software.

Moreover we might have multiple identities being send in one EAP session.

According to http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-06 5.7 (Identify verification):

As a result, PEAP implementations SHOULD NOT attempt to compare the Identities

claimed with Parts 1 and 2 of the PEAP conversation. Similarly, if multiple Identities

are claimed within PEAP Part 2,   these SHOULD NOT be compared.

We  can see that EAP-PEAP with EAP tunneled Mschapv2 implementation in  Microsoft is not clear. It's not event 100% compatible with drafts. Also  please notice that drafts are pretty old and are ralated to WindowsXP  SP1. Moreover behavior differs between operating system version.

Dump.pl script details

• It  performs binary search for beginning of SSL session inside other  protocols. It might be not always accurate because I did not follow RFC  to      write it. But it works with all examples I tested.

• It's universal, might be used to grab SSL from other protocols

• It  uses heavily Net::Frame::Layer libraries. One of them did not worked  correctly (newest version) so I added my changes (Frame::Layer:IPv4).  Attached working libs to this document.

• Disclaimer: I can not take any responsibility for that script. Please use it at your own risk.

References

http://tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2-02

http://tools.ietf.org/html/draft-kamath-pppext-peapv0-00

http://tools.ietf.org/html/draft-josefsson-pppext-eap-tls-eap-06

http://tools.ietf.org/html/rfc5216

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工作模式主要分为两种：

1. PC <——> NAS <——> AAA：这是所谓的MS-CHAPv2认证流程，NAS将Challenge发送给PC，PC响应后NAS再组织Radius属性（MSCHAP-Challenge + MSCHAP-Response），然后Radius服务器根据获取到的密码（可能是明文、LM-Password、NT-Password）加上MSCHAP-Challenge计算获取密文同收到的MSCHAP-Response进行比较；
2. 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协议:

1. 在请求者和认证者之间， EAP 协议报文使用EAPOL 封装格式，直接承载于LAN 环境中
2. 在认证者和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的内部协议结合使用。