链路层安全扩展——L2TP协议
PPP协议
协议概念
说到数据链路层的安全协议,我们不得不先提一下PPP协议,后面的PAP、CHAP与L2TP协议都是围绕它展开的。(PPP不是本文重点,很多细节没有提到,到时候会专开一篇文章讲PPP)
PPP(Point-to-point Protocol,点到点协议)协议是为同等单元之间传输数据包设计的,主要是用来通过拨号或专线方式建立点对点连接发送数据,使其成为各种主机、网桥和路由器之间简单连接到一种共同的解决方案。
点对点网络中,一个数据帧的接收者就是固定的对等端。
PPP规定了以下内容:
- 帧格式以及成帧方法
- 用于建立、配置和测试PPP链路的链路控制协议(Link Control Protocol, LCP),以及通信双方可通过LCP包协商一些选项。
- 一组用于建立和配置网络层协议的网络控制协议(Network Control Protocol,NCP)。在PPP链路上可以传输不同网络协议的数据,NCP用于对这些网络协议相关的参数进行配置。但NCP只是一个统称,如果传输的是IP数据,则“NCP”是指IP控制协议(IPCP)。不同类型的NCP充分说明了PPP具有良好的通用性。鉴于IP的通用性,随后都以IPCP为例进行说明。
协议封装格式
PPP协议的封装格式如下:
- 协议字段分为三种:如果是
0xC021
,则数据部分是PPP的链路控制数据;如果为0x0021
,数据部分就是IP数据报;如果是0x8021
,则表示这是网络控制数据。
协议流程
PPP协议流程如下:
- 在建立PPP链路前,发送方和回应方必须建立一条物理连接。
- 双方首先利用LCP建立PPP链路。
- 用PAP或CHAP验证身份。
- 用IPCP配置IP层参数。
- 通信完成后,利用LCP断开PPP链路。
- 断开物理连接。
整个过程包括5个阶段:
- 链路不可用阶段:链路状态的起始点和终止点。
- 链路建立阶段:双方用LCP建立链路。
- 认证阶段:回应方发起身份验证。
- 网络层协议阶段:回应方给发起方分配IP地址(毕竟是对等方式连接的)。
- 链路终止阶段:PPP链路终止。
PAP和CHAP认证协议
PPP协议有两种认证协议,分别是PAP协议和CHAP协议。
PAP协议
PAP(Password Authentication Protocol)是基于口令认证的方法,被认证方发送Authenticate-Request报文(类型1),其中包含了身份(通常是账号或者说用户名)和口令信息。
若认证通过,认证方返回Authenticate-Ack(类型2),否则返回Authenticate-Nak(类型3)。
PAP协议以明文方式传输身份和口令给网络接入服务器(Network Access Server,NAS)。因此安全性较差,容易被第三方窃取用户名和口令。
另外,PAP在PPP身份认证过程中,由被认证方发起认证,并且仅在建立链路阶段使用,在数据传输过程中不能用。
下面是PAP两次握手的具体过程:
CHAP协议
**基于挑战认证的协议(Challenge-Handshake Authentication Protocol)**通过三次握手完成身份认证,我们记认证方为S
,其用户名为SU
,被认证方为U
其用户名为UU
,随机数为R
,口令为PW
,则认证成功的工作过程如下(部分字段没有体现在下文中,详细请参考包格式):
S → U : 0 x 0001 , I D , R , S U U → S : 0 x 0002 , I D , H a s h ( P W ∣ ∣ R ) , U U S → U : 0 x 0003 , I D , M e s s a g e S\to U:0x0001,ID,R,SU \\ U\to S: 0x0002,ID,Hash(PW || R),UU \\ S\to U: 0x0003,ID,Message S→U:0x0001,ID,R,SUU→S:0x0002,ID,Hash(PW∣∣R),UUS→U:0x0003,ID,Message
数据包格式如下图所示:
- Challenge和Response报文的类型编号分别为1和2,Success和Failure报文类型分别为3和4
- 随机数和散列值长度可变,内容在值字段体现。
- 名字字段描述发送方身份信息。
- 消息字段包含描述信息,比如认证失败的原因。
CHAP协议相比PAP协议较安全,它由认证方发起挑战,使用Hash函数来避免连接时传输明文,随机数可避免重放攻击,而且不定时重复呼叫用户提供口令来避免第三方冒充。
但CHAP也有许多安全隐患:
- 服务器明文存放口令
- 单向认证,不能判断服务器是否假冒
- 重复呼叫周期过长容易被攻击,周期过短计算量增加影响性能
L2TP协议
了解以上情况后,终于该本文主角登场了!
概念
**第二层隧道协议(Layer 2 Tunnel Protocol, L2TP)**是PPTP协议与Cisco L2F协议联合版本,有一部分采用PPTP,但可以在多种网络传输,突破了PPTP只能在IP网络上的局限性。
我们来看下L2TP相关术语:
- LAC:L2TP接入控制器。作为L2TP隧道端点,位于一个LNS和一个远程系统之间,并在两者之间发数据包。从LAC发往LNS的数据包需要用L2TP协议进行隧道传输,从LAC到远程系统之间的连接或是本地的或是一个PPP连接。
- LNS:L2TP网络服务器。一次PPP会话的逻辑端结点,能处理PPP协议和L2TP协议分组。
- AVP:属性值对。用于构造PPTP的控制消息。
- 控制连接:一个控制连接是LAC和LNS之间的一条连接,用以建立、维护和关闭L2TP会话和控制连接本身
- 隧道:隧道存在于一个<LAC,LNS>对之间。隧道包括一个控制连接和零个或多个L2TP会话。隧道在LAC和LNS之间传输被封装的PPP数据包和控制消息。一条隧道对应一个控制连接,并可承载多个会话。LAC和LNS通过协商建立控制连接后,意味着隧道建立成功,随后即可承载会话。LAC每收到一个来自远程系统的呼叫,就为该呼叫建立一个会话。
实现模式
L2TP有两种实现模式,分别是强制模式和自愿模式。
强制模式
强制模式如上图中的1用户所示。
- 提供L2TP服务的网络访问服务器作为LAC。
- 对用户透明,只需向LAC拨号建立PPP连接,由LAC建立一条通向目的LNS的隧道。
- 远程系统只需加载TCP/IP协议及普通的远程拨号软件即可。
- 可同时建立多条隧道,与多个公司同时通信。
- 缺点是隧道的建立依赖于支持L2TP协议的服务者
强制模式下,考虑远程用户对公司总部内联网进行访问的情况,其建立L2TP会话的过程主要包括建立控制连接和建立会话:
- 远程用户通过PSTN/ISDN网,向LAC发起PPP请求。LAC接受此连接,建立远程用户到LAC的PPP连接。在建立PPP连接的过程中,远程用户与LAC之间交换了LCP配置信息,并可能实现了如CHAP身份认证信息的交换。认证信息交换的过程是LAC向远程用户进行CHAP呼叫,远程用户对此呼叫进行应答。
- ISP的LAC根据CHAP中的应答信息,确定此用户实现直接的Internet访问控制还是虚拟的拨号访问服务。如果需要进行虚拟拨号访问,则确定用户访问的目的地,即目的LNS
- 如果LAC与该LNS之间没有建立隧道,则由LAC向LNS发起建立隧道的请求,并为该隧道分配隧道号。
- LAC与LNS之间的隧道建立完成后,在隧道中为该用户的呼叫分配ID。之后LAC向LNS发出入站呼叫请求。该请求中可能包括LAC对远程用户收集的认证信息以及其他配置信息。
- 如果LNS接受此入站呼叫,则LNS为此呼叫产生一个虚拟接口,该虚拟接口就是L2TP隧道的终点,同样,在LAC上也有一个虚拟接口。此时,LAC和LNS之间的会话已经建立。
- 远程用户发来的PPP分组成帧到达LAC后,LAC上的L2TP虚拟接口剥去帧的同步序列位等,将余下的数据部分用L2TP进行封装,发送至LNS后,L2TP头被剥去,剩余分组将和本地分组一样被送到相应的接口进行处理。
- 当用户想断开链接时,可以向LNS发送终止请求分组,请求断开PPP连接。该分组同其他分组一样,封装在L2TP隧道中传输给LNS。LNS在收到该分组后,发送终止确认分组以终止链路。LNS知道用户已经终止了本次会话后,发送L2TP呼叫关闭分组给LAC,释放会话连接。
自愿模式
自愿模式如上图的2用户所示,要求机器上必须具备LAC客户端。
- 由连接到Internet的主机(LAC客户)自己建立、控制、管理VPN。
- 客户只需在其主机上安装LAC客户软件即可与LNS建立连接。
- 适合远程办公用户与自己公司相连的情况,隧道的建立不依赖服务提供者。
- 隧道不能分用/复用,LNS需要大量隧道来满足连接请求,并且每个用户同时只能开通一条隧道。
协议消息
- L2TP使用两种消息类型:控制消息,数据消息。均由首部(头)和主体两部分组成。
- 控制消息用于建立、维护、清除隧道和呼叫,主体部分描述了控制报文类型,以及与报文类型相关的信息,这些信息都以属性值对(AVP)的形式出现。
- 数据消息用于封装在隧道上传输的PPP帧,主体是PPP帧。
L2TP分组报文首部格式如下:
- T(ype)比特:类型标识,“0”表示数据消息,“1”表示控制消息。
- L(ength)比特:长度字段标识,“1”表示首部包含“长度”字段。对控制字段必须为1.
- 长度:消息总长度,包括L2TP头、PPP分组等
- 隧道ID:此次会话所属隧道号
- 会话ID:表示一个隧道内一次会话的标识符
- Ns和Nr:在数据消息中是可选项,在控制消息中必须出现。分别代表当前分组序列号和希望接收的下一个分组序列号。
- 偏移量:在数据消息中可选,在控制消息中不出现。最高位置1时,表示紧接L2TP头后(从该字段开始)应跳过多少字节才是用户数据偏移填充:为0,为了使L2TP头与填充字节的总长度达到一定长度的整数倍,使协议的处理更高效。
- Ver:L2TP的版本,目前取值为2
对于L2TP控制消息格式如下:
L2TP控制消息=L2TP头+AVP(1|n)
IETF定义的所有AVP,从功能上可分为6大类:
- 适用于所有控制消息的AVP
- 用于报告结果和错误代码的AVP
- 用于控制连接管理的AVP
- 用于呼叫管理的AVP
- 用于认证的AVP
- 用于显示呼叫状态的AVP
AVP格式如下图所示:
- M:强制位,说明接收方在收到无法识别的AVP时应怎样处理。M取1会话将被中断,取0则忽略。
- H:隐藏位。表示AVP中的属性值是否被想隐写为密文。此功能可在AVP中传输口令等敏感数据。
- 长度:字段长为10位,表示AVP所包含的字节数。
- 厂商ID:字段长为16位,不同软/硬件厂家被分配的一个SMI(structure of management information,管理信息结构)即为厂商ID。
- 属性类型:2个字节,表示AVP类型。
- 属性值:对应属性的取值,长度随不同属性类型而不同。
L2TP对属性值做加密处理之前首先生成隐藏AVP子格式(Hidden AVP Subformat, HAS),其中包含2B的“原属性值长度”以及任意长度的“原属性值”和“填充”字段。
加密处理时首先将HAS划分为16B的分组,依次为(p1,p2,….,pi)
随后加密过程如下:
其中,AV是2B的属性类型;S是通信双方的共享秘密,这个秘密和双方实施CHAP时所使用的共享秘密相同;RV是随机向量。最终的属性值字段是c1|c2|….|ci。
由于加密属性值需使用RV,所有每个包含隐藏AVP的L2TP报文中都应该包含“随机向量AVP”,且在所有隐藏AVP之前出现。多个隐藏AVP可共用同一RV,每个隐藏AVP都使用其前面最近的RV。
控制连接
连接建立
- L2TP封装分组在IP网络中是通过UDP报文方式传送的,所以不需建立TCP连接。
- LAC和LNS都可发起控制连接,各自分配唯一的隧道ID。
- 同一LAC-LNS对可建立多条隧道,以区分不同的服务质量。
- 通过在SCCRQ或SCCRP消息中包含Challenge AVP,要求对方提供身份认证信息;对方回复时必须包含相应的Challenge Response AVP。
- 隧道认证用共享密钥完成。
隧道维护
- 隧道没有收到任何消息,则可以小于1分钟/次的频率发送Hello消息
- 探测隧道是否存活。
- 接收方收到Hello消息后应立即进行确认。
- 若发送方在一定时间内没有收到接收方的确认,可在一定时间后重发。
- 重发一定次数后仍没有收到确认,则关闭隧道连接。
隧道关闭
- 关闭原因:系统出错、资源不足、认证失败、用户挂断等。
- 一方将关闭隧道时给对方发送一个StopCCN(Stop-Control-Connection-Notification)消息。
- 收到StopCCN的一方应发送零长度消息(zero-length-body,ZLB),以确认接收,之后将等待一个重发周期的时间,防止ZLB消息丢失而重发StopCCN的情况。
L2TP呼叫
呼叫建立
- 控制连接建立后就可以进行会话建立的协商、维护和管理。
- 会话建立有方向性,分为出站呼叫和入站呼叫。
- 总部主机希望同远程用户通信,LNS向用户所在LAC发起出站呼叫。
- 远程用户向总部主机发起访问时,用户所在LAC向LNS发起入站呼叫。
- 出站呼叫和入站呼叫都是三次握手的过程。
会话维护
- 两个消息控制用于会话维护:
- LAC向LNS发送WEN(WAN-Error-Notify)消息,报告本地会话处理中出现错误的统计情况。
- LNS向LAC发送SLI(Set-Link-Information)消息通知LAC修改异步控制字符映射ACCM。
会话关闭
LAC与LNS都可以作为会话关闭的发起方。
举例来讲,当用户希望终止会话时,他使用PPP Terminate-Request消息通知LAC。LAC并不理解该消息,像其他分组一样封装后发送给LNS。LNS发送Call-Disconnect-Notify 通知LAC,并清除本地与该会话有关的状态量
LAC收到CDN后,也清除相应的状态量,会话终止。
安全性分析
- L2TP不提供对PPP数据的机密性和完整性保护,若使用CHAP,则可体现端点身份认证的功能。
- CHAP依赖共享秘密,但L2TP并未讨论秘密的生成和更新方法;
- 由于不提供对每个报文的认证功能,所以无法抵抗插入攻击和地址欺骗。
- 攻击者可能会伪造一些假冒的控制信息,使得隧道和底层链路断开,造成拒绝服务攻击。
- L2TP应被看成一个隧道协议。
- 从安全的角度考虑,L2TP应与IP或传输层的安全协议结合使用。