VPN身份认证技术
对于一些使用PPP协议通信的二层VPN方案，如PPTP VPN和L2TP VPN，是直接采用数据链路层PPP协议支持的PAP（Password Authentication Protocol，密码认证协议）或CHAP（Challenge Handshake Authentication Protocol，质询握手认证协议）进行用户身份认证的。但必须确保PPP链路两端的接口上启用了相同的PPP认证方式，并且相关功能配置正确。而在一些三层VPN方案中，要使用密钥进行认证，这就涉及一些认证密钥算法，如MD5、SHA、SM3等。
1. PAP协议报文格式及身份认证原理
以下内容是针对PPP协议进行介绍的，但同时适用于PPP协议的扩展协议，如PPTP和L2TP协议。
（1）PAP报文格式
PAP协议是PPP协议簇中的一个，与PPP一样同位于数据链路层，但在PPP协议之上，其帧也要受到PPP协议封装。PPP协议数据帧格式如图1所示，如果封装的是PAP报文，则其中的“协议”字段值为0x C023。
图1 PPP数据帧格式
PAP协议报文格式如图2所示，各字段说明如下：
图2 PAP协议报文格式
Code：报文代码，8字节，用于识别PAP报文类型，1为Authenticate-Request （认证请求），2为Authenticate-ACK（认证确认），3为Authenticate-NAK（认证否认）。
Identifier：报文标识符，8字节，类似于报文序列号，同一组认证进程下的请求报文和应答报文标识符一致。
Length：长度，16字节，以字节为单位标识整个PAP报文（包括本字段）的长度。
Data：数据，长度可变，具体内容会因PAP报文类型的不同而不同，如果是ACK报文，该字段长度为0；NAK报文中该字段会说明认证失败的原因；Request报文中该字段为用于进行身份认证的用户凭据信息。
（2）PAP协议身份认证原理
PAP协议的身份认证过程非常简单，是一个二次握手机制，整个认证过程仅需两个步骤：被认证方（PPP客户端）发送认证请求→认证方（PPP服务器）给出认证结果。但是它是一种以明文方式在线路上传输认证用户名和密码，所以安全性不高。
PAP认证可以在一方进行，即仅由一方对另一方的身份进行认证，通常是是由PPP服务器对PPP客户端进行认证；也可以进行双向身份认证，也就是既要PPP服务器对PPP客户端进行认证，PPP客户端也需要对PPP服务器进行认证，以确保用于认证的PPP服务器是合法的。如果是双向认证，则要求被认证的双方都要通过对方的认证程序，否则无法在双方之间建立通信链路。
下面以单向认证为例介绍PAP认证过程，如图3所示。但要注意的是，PAP认证是由被认证方（PPP客户端）首先发起的。
图3 PAP身份认证的两次握手
1）发起PPP连接的客户端（被认证方）首先以明文方式向PPP服务器端发送一个认证请求（Authenticate-Request）帧，其中就包括用于身份认证的用户名和密码；
2）PPP服务器端（认证方）在收到客户端发来的认证请求帧后，先查看PPP服务器本地配置的用户账户数据库，看是否有客户端提供的用户名（这个用户账户数据库存必须先在PPP服务器端配置好）。如果有，且对应的用户账户密码也一致，则表明客户端具有合法的用户账户信息，向PPP客户端返回一个认证确认（Authenticate-ACK）帧，表示认证成功，则该用户可以与PPP服务器端建立PPP连接。
如果在本地数据库中找不到与客户端发来的用户名一致的用户账户，或者虽然有相同名称的用户账户，但密码不一致，则会认证失败，返回一个认证拒绝（Authenticate-NAK）帧，客户端也不能与PAP服务器端建立PPP连接。
如果第一次认证失败，并不会马上将链路关闭，而是会在PAP客户端提示可以尝试以新的用户账户信息进行再次认证，只有当认证不通过的次数达到一定值（缺省为4）时才会关闭链路，以防止因误传、网络干扰等造成不必要的LCP重新协商过程。
以上介绍的是PAP单向认证过程，仅两步（一问一答形式），很简单。PAP双向认证过程与单向认证过程类似，只不过此时PPP链路的两端是同时具有客户端和服务器双重角色，任何一端都向对方发送认证请求，同时对对方发来的认证请求进行认证。
2. CHAP协议报文格式及身份认证原理
以下内容是针对PPP协议进行介绍的，但同时适用于PPP协议的扩展协议，如PPTP和L2TP协议。
（1）CHAP报文格式
CHAP协议也是PPP协议簇中的一个，是用于进行身份认证的，也与PPP协议一样位于数据链路层，但在PPP协议之上，其报文也要受到PPP协议封装，对应的协议号为0x C223。CHAP报文格式与PAP协议报文格式一样，参见图2。但各字段的含义有所区别，具体说明如下。
Code：报文代码，8字节，用于识别PAP报文类型，1为Challenge（质询），2为Response（响应），3为Success（认证成功），4为Failure（认证失败）。
Identifier：报文标识符，8字节，类似于报文序列号，同一组认证进程下的各类报文标识符一致。
Length：长度，16字节，以字节为单位标识整个CHAP报文（包括本字段）的长度。
Data：数据，长度可变，具体内容会因CHAP报文类型的不同而不同，Success和Failure报文中该字段身份认证成功或失败的的一段文本说明信息；Challenge报文中该字段为主认证方发送被认证方的随机MD5摘要消息；Response报文中该字段为被认证方发给主认证方的一个经过MD5加密的Hash（哈希）值。
（2）CHAP身份认证原理
CHAP协议的身份认证过程相对前面介绍的PAP认证来说更为复杂，采用的是三次握手机制（而不是PAP中的两次握手机制），整个认证过程要经过三个主要步骤：认证方（PPP服务器）要求被认证方（PPP客户端）提供认证信息→被认证方提供认证信息→认证方给出认证结果。
其次，CHAP身份认证方式相对PAP认证方式来说更加安全，因为在认证过程中，用于认证的密码不是直接以明文方式在网络上传输的（用户名仍是以明文方式传输），而是封装在MD5加密摘要信息中，更加安全。CHAP认证的具体步骤还与认证方是否配置了用户名有关，推荐使用验证方配置用户名的方式，这样被认证方也可以对认证方的身份进行确认，相当于PPP客户端对PPP服务器的身份也可以进行认证。
同PAP认证一样，CHAP认证也可以是单向或者双向的。如果是双向认证，则要求通信双方均要通过对对方请求的认证，否则无法在双方建立PPP链路。在此，我们仍以单向认证为例介绍CHAP认证流程。具体如图4所示，但要注意，CHAP身份认证首先是由PPP服务器端主动发起质询的。
图4 CHAP身份认证的三次握手
1）当PPP客户端要与PPP服务器建立连接，并且配置采用CPAP身份认证方式时， PPP服务器（认证方）会首先向PPP客户（被认证方）端发送一个随机报文（如果认证方配置了用户名，则还随同发送认证方的用户名）进行“质询”（Challenge，也称“挑战”），询问客户端用于身份认证的账户信息。同时这个发送的随机报文会保存在缓存中。
2）PPP客户端在收到服务器端发来的质询消息后，如果随机报文中包括了PPP服务器的用户名，则先看本地是否配置了PPP服务器的账户信息对PPP的身份进行认证（如果收到的随机报文中不包括PPP服务器的用户账户信息，则不需要对PPP服务器身份进行认证），认证通过后再把所收到的随机质询报文与PPP客户端配置的账户密码（相当于MD5算法中所说的“共享密钥”）采用MD5算法进行加密，将生成的MD5摘要密文和自己的用户名发回PPP服务器进行响应（Response）。
3）PPP服务器端在收到来自客户端的响应后，首先直接利用来自PPP客户端的明文用户账户名在本地数据库中进行查找，如果找不到该账户，则直接认证为认证失败；如果在本地数据库中有该用户账户就可以得到本地配置的该账户的密码，然后再利用所查到的该账户密码与原来发送给客户端，并且在缓存中保存的随机质询报文进行同样的MD5哈希计算，看最终的结果与来自PPP客户端的MD5哈希报文进行比较。
如果两个MD5哈希报文完全一致（如果本地配置的该账户密码与在PPP客户端配置的一样，则肯定一致，因为此时进行哈希计算时的MD5报文和密码都是一样的），则认为PPP客户端具有合法的用户账户信息，认证通过，向PPP客户端发送认证成功（Sucess）帧，成功进行PPP连接；否则表示认证失败，向PPP客户端发送认证失败（Failure）帧，不能建立PPP连接。
与PAP一样，第一次认证失败后，也不会马上关闭链路，而是再次向客户端提示输入新的用户名和密码进行再次认证，直到规定的最高尝试次数。
3. 身份认证算法
在一些三层VPN解决方案中，还涉及到许多用于生成身份认证密钥的算法，如在IPSec VPN中使用的AH和ESP安全协议就支持多种认证算法——MD5、SHA1、SHA2（包括sha2-256、sha2-384、sha2-512）、SM3、 AES-XCBC-MAC-96，这些其实都是属于哈希，摘要，或者杂凑算法。
在这些算法中都需要用到一些特定的函数运算方法，这些函数的名称也对应有多种，如“哈希（Hash）函数”，或“消息摘要函数”“杂凑函数”“单向散列函数”，这些函数运算的基本设计思想是将输入的任意长度消息，通过运算后得到一个固定长度的输出值。这个输出值也就对应称之为“哈希值”，或“消息摘要”“杂凑值”“散列值”等。这个消息摘要会随同消息一起发送到对方，对方再用相同的摘要算法对所接收的消息数据进行运算，看结果是否与随同消息一起发送、在源端得出的摘要相同，如果相同，则表示消息数据在传输过程中没有被篡改，可以放心使用；不同，则表示消息数据在传输过程中被非法篡改，不可用。
哈希函数（或杂凑函数）可以按其是否有密钥参与运算分为“不带密钥的哈希函数”和“带密钥的哈希函数”。不带密钥的哈希函数在运算过程中没有密钥参与，只有原始消息输入。这类哈希函数不具有身份认证功能，仅提供数据完整性检验，称之为MDC（篡改检测码）。而带密钥的哈希函数在消息的运算过程中是有密钥参与的，即哈希值（或杂凑值）同时与密钥和原始消息的输入有关，只有拥有密钥的人才能计算出相就的哈希值。所以带密钥的哈希函数不仅能检测数据完整性，还能提供身份认证功能，被称之为MAC （消息认证码）。现在通常是采用带密钥的哈希函数。
