Eduroam接入认证、MSCHAPv2分析及口令存储方式

Eduroam中的接入认证

1. Eduroam使用的认证方式

根据Eduroam的官网文档，其安全主要表现在两个方面：
1） 用户的信息存储在其注册的本地机构服务器中，即使在其他地点登录，也要连接原机构服务器进行认证，极大地减少了用户信息的传播。
2） 使用WPA2-Entrerprise (802.1x)，用RADIUS服务器建立TLS通道（通过EAP TTLS或PEAP），保证身份认证过程在通道中进行，提供端到端加密，用户信息不被泄露。

部分原始信息：

• What technology does eduroam use?
  In eduroam, communication between the access point and the user’s home institution is based on IEEE 802.1X standard; 802.1X encompasses the use of EAP, the Extensible Authentication Protocol, which allows for different authentication methods. Depending on the type of EAP method used, either a secure tunnel will be established from the user’s computer to his home institution through which the actual authentication information (username/password etc.) will be carried (EAP-TTLS or PEAP), or mutual authentication by public X.509 certificates, which is not vulnerable to eavesdropping, will be used (EAP-TLS).
  https://www.eduroam.org/faqs/

• Our network relies on PAP/CHAP, can we join eduroam securely?
  While PAP passwords remain in plain text in the “inner-tunnel,” the 802.1x SSL tunnel, in either TTLS or PEAP, exists from the users’ supplicant all the way back to the home RADIUS server. All EAP authentication traffic, including the plain text password, is encrypted within the SSL tunnel which terminates on the RADIUS server itself. At that point the only users who should have access to the unencrypted traffic are local administrators/users on the RADIUS server itself. From there the transit to/from the directory service (IdP) must be secured according to local policy.
  With CHAP the security challenge rests in the secure storage of unencrypted passwords at rest, rather than in the transit of the credentials over the network. This must be addressed by institution-specific security policy.
  https://www.incommon.org/eduroam/faq.html

官网并未指明其在TTLS/PEAP中需要使用哪种认证方式，官网文档认为，其安全性在于“端到端的加密”，而具体的认证方式并没有提到。
另外，在关于Eduroam的rfc 7593中，也提到EAP中的认证方法是可选的：
In other words, in principle, every authentication form that can be carried inside EAP can be used in eduroam, as long as they adhere to minimal requirements as set forth in the eduroam Policy Service Definition [eduroam-service-definition].

在查阅了国内外高校的Eduroam配置和使用文档后，发现几乎所有高校选择的认证方式都是PEAP+MSCHAPv2。个别学校在安卓手机的设置中，第二阶段认证方式会设为“空”，但是在实验验证时发现，由于freeradius中eap.conf文件中显示：
使用默认设置，即使选择“空”，使用的也是MSCHAPV2的认证方法。
所以在之后的实验验证过程中，默认Eduroam使用的是PEAP+MSCHAPv2的认证方式。

2. MSCHAPv2具体算法

在MSCHAPv2的rfc 2759中，提到关于用户和认证服务器之间的双向认证，需要双方生成两个认证信息，

• 一个叫做NT-Response，由用户用自己的password、ID、Peer challenge和Server challenge首先生成，然后发给服务器，服务器用同样的方式生成NT-Response并进行对比。
• 另一个叫做Authenticator Response，是由服务器用password、ID、Peer challenge、Server challenge和NT-Response生成的，发给用户由用户验证。

其中，用户的口令password并不是直接作为输入参与最终运算，而是要对其进行哈希运算：

• NT-Response使用的是password的NT-Hash值，使用NtPasswordHash()函数

  功能：输入0-256个Unicode字符password，输出16个字符passwordHash；
  处理逻辑：使用MD4对password计算Hash值

• Authenticator Response使用的是password的两次NT-Hash值。

基于上述分析，MSCHAPv2要完成验证过程，服务器需要获取用户的口令明文（Cleartext-Password）或口令的NT-hash值（称为NT-Password）。并且只能使用NT-hash方法，不能选择其他hash算法。

这部分信息也可以从freeradius的文档中找到：
The mschap module provides support for MS-CHAPv1 and MS-CHAPv2, which is a common authentication mechanisms for Microsoft clients.
If you want to support mschap, there are only 3 possibilities:

• 1.You have access to the users plaintext password, and you configure
  FreeRADIUS to read this, and set the Cleartext-Password control
  attribute.
• 2.You have access to the NT (MS-CHAPv2) or LM (MS-CHAPv1) hashes,and you configure FreeRADIUS to read this and set the
  NT/LM-Password control attribute.
• 3.You have Samba installed, joined into a windows domain, and use the ntlm_auth helper binary to pass authentication onwards to a
  domain controller.
  These are the ONLY possibilities; MS-CHAP is IMPOSSIBLE if you e.g. only have the unix/md5/sha crypt of your users password. For more info, see:
  http://deployingradius.com/documents/protocols/compatibility.html

上面的网址描述了不同的认证方法对于哈希算法的兼容情况：

所以我们确定，对于存储的口令格式来说，MSCHAPv2是支持存储哈希后的口令的，只是必须使用NT hash算法。并且，如果存储的口令是NT-Password，则无法使用不兼容NT-Hash算法的认证方法。

3. FreeRADIUS存储哈希口令

3.1 哈希口令的属性

首先，根据RADIUS支持的PAP认证方法的文档rlm_pap，发现对于不同类型的hash口令，freeradius提供了不同的attribute:

上表也表示了freeradius支持的所有类型的hash算法，包括哪些算法可以加盐。

PAP认证方式是采用Password-With-Header的方法，在数据库中寻找口令，即上表中的Header一列，但当找不到Header属性时，将会寻找Cleartext-Password、NT-Password、Crypt-Password等属性。这些属性应该直接包含相关的格式密码，没有Header前缀。

据此得知了freeradius中对于不同哈希口令的区分方式，其中用NT-Hash计算的口令值，保存时应该附有“NT-Password”属性。

另外，Freeradius的文档以及官方文档都指出了一个问题，这也是在调试时经常出现的warning:

User-Password和Cleartext-Password属性是不同的。Cleartext-Password属性是用户的"known good"口令，也就是服务器存储用来比对的口令。只要向服务器提供明文口令Cleartext-Password，大多数身份验证方法就可以工作。User-Password属性是用户在其专用机器上键入的口令。这两者是不一样的，应该区别对待。也就是说，通常不应该在RADIUS配置的任何位置使用User-Password属性。

3.2 计算NT-HASH的模块

Freeradius的网站提供了计算NT-Hash的命令smbencrypt：
https://freeradius.org/radiusd/man/smbencrypt.html

NAME
smbencrypt - produce LM & NT password hashes from cleartext passwords
SYNOPSIS
smbencrypt password [password …]

DESCRIPTION
smbencrypt For each cleartext password passed on the command line emit the LM-Password and NT-Password hashes for that password.
EXAMPLE
$ smbencrypt foo bar

3.3 实验验证

在之前搭建的freeradius+Hostapd环境中，我设置的用户信息存储在mysql数据库中，原本对于口令明文的属性为”Password”，经验证可以成功，但调试信息会产生warning提醒，希望用户将”User-Password”属性改为“Cleartext-Password”属性。修改之后就没有问题了。

假设用户信息为”user5””password5”，首先计算其NT-hash值：

然后将用户信息输入数据库中：

此时数据库中的测试用户user5的信息如下：

之后重启freeradius，用手机使用”user5””password5”信息进行连接，发现可以成功连接，即存储NT-Password是可以认证成功的。

问题

1） Eduroam的设置是各个高校和机构自己配置的，并没有指定使用哪种存储用户信息的方式（如mySQL或OpenLDAP）。在https://www.eduroam.edu.cn/网站中给出的Eduroam搭建方法中，使用的是LDAP，且没有对具体配置方式的要求:

使用LDAP是在OpenLdap中需要添加samba的支持，然后将sambaNTPassword存储的密码字段映射为Freeradius中的NT-Password字段。和使用mysql数据库类似。
另外，在中科大给出的Eduroam搭建文档中，使用的是mysql数据库：
http://staff.ustc.edu.cn/~james/eduroam/eduroam-ustc.html
http://staff.ustc.edu.cn/~james/eduroam/


Eduroam没有给出标准的建设设置，所以各个高校建设Eduroam时可能选择的方式略有差别，其存储用户信息的数据库也是由各校自己维护的，所以高校内的数据库中存储的是明文口令还是哈希口令还未尝可知。

2） 关于如何测试Eduroam数据库中存储的密码格式的问题，我在自己搭建的实验环境中尝试了一下，发现选择PEAP方式，有两种认证方法（MSCHAPv2,GTC）；选择TTLS方式，有四种认证方法（PAP,MSCHAP,MSCHAPv2,GTC），但是这几种认证方法都支持NT-Password，无论选择哪一种都可以成功连接，所以不存在数据库中存储NT-Password导致与所选认证方法不兼容的问题。
3） freeradiu中的NT-Hash算法不支持加盐，且MSCHAPV2中的计算方法也不支持用加盐后的Hash值计算，因为用户和认证服务器之间的信息应该是对等的，盐值的存在会导致双方无法计算出相同的Response。