EAP-TTLS预研报告

  1. 概述

EAP-TTLS(Tunneled Transport Level Security)是由Funk Software与Certicom所共同开发,为了提供一比EAP-TLS简单的方式而开发。TTLS只需要Server端的Certificate而大大降低管理所需时间。对TTLS鉴权算法的功能描述如下:

  1. 允许用户使用username和password鉴权,而不损安全性;
  2. 提供加强的交互验证,credential security和dynamic keys;
  3. 仅需要将证书(certificates)部署在Radius服务器上,而不需要放在客户端;
  4. 与现有的用户安全数据库兼容,包括Windows Active Directory, token systems,SQL,LDAP等等。

EAP-TTLS的特点如下:

  1. TTLS先利用Server Certificate建立一个Tunnel到Client,再利用这个Tunnel让Client将其密码或Certificate送给Server。
  2. TTLS的特色如:
    1. 它的Tunnel之中可搭配任何形式的验证法,如Password、Certificate或Token,如MS-CHAPv2、MS-CHAP、CHAP、PAP、MD5等。
    2. 只需要Server端的Certificate。
    3. 不怕黑客的Dictionary攻击。
    4. 支持双向验证,漫游时的Fast Reconnection,以及自动变换Key。

EAP-TTLSv0v1两种版本,v0版本是命名为EAP-TTLSv1版本命名为EAP-TTLSv1。根据协议和需求,我们需要支持的鉴权算法为v0版本的TTLS算法,即EAP-TTLSv0版本。

  1. 术语

AAA/H:用户归属域的AAA服务器,用于给归属域管理的用户鉴权和授权。

TTLS Server:能够支持EAP-TTLS算法的AAA服务器。该服务器也可以承担用户鉴权功能,或者能够代理转发用户鉴权到AAA/H。

Access Point:接入点,提供基于AAA服务器返回的信息,实现用户接入控制和策略功能的实体。在本文中“access point”和“NAS”在体系结构上是等同的。“access point”一般是指无线接入领域,“NAS”一般用户传统接入领域,例如拨号接入。

Client:通过接入点接入到网络的主机或设备。

  1. 网络结构模型

下图为EAP-TTLS应用的网络结构模型。

 

        上图描述的实体,是逻辑实体,并不一定是分开的网元。例如,TTLS Server和AAA/H可以合一;TTLS Server和Access Piont可以合一;甚至Access Piont、TTLS Server和AAA/H都合一。

        我们EAP-TTLS的实现方式应该为AAA/H和TTLS Server合一方式。

    1. 传输协议

上图实体之间的通信,使用可以封装EAP消息的传输协议。Client和Access Piont之间使用链路层传输协议,例如PPP或EAPOL。Access Point、TTLS Server和AAA/H之间通信使用AAA传输协议,例如RADIUS或Diameter。

 

    1. 协议分层模型

EAP-TTLS包是封装在EAP,EAP又是通过传输协议进行传送的。EAP-TTLS包本事封装了TLS,TLS又是用来封装用户鉴权信息的。所以EAP-TTLS消息可以描述为以下分层模式,每一层都封装在下面一层中。

 

当用户鉴权采用EAP鉴权时,EAP-TTLS协议分层可以描述为下面的模式:

 

传输协议PPP(RFC1611)、EAPOL(IEEE802.1X, Standard for Port Based Network Access Control)、RADIUS(RFC2865)、Diameter(RFC3588)本文档不在赘述。详见相关参考文献。

 

    1. TTLS流程

EAP-TTLS协商流程包括两个阶段:TLS握手阶段(TLS handshake phase)和TLS隧道阶段(TLS tunnel phase)。

在握手阶段,TLS用在客户端对TTLS服务器进行鉴权,服务器对客户端的鉴权是可选的。在此阶段,客户端和服务器进行协商选定加密用的加密套,建立TLS通道。协商的加密套的类型决定了在下一阶段数据的安全程度,如果协商的是空的加密套,那么在后面的数据传输中就没有任何安全可言。

在第二阶段,即通道建立后的TLS隧道阶段,可以执行一系列操作,包括:用户鉴权、协商数据通讯安全等级、密钥分发、通讯或计费信息等。Client和TTLS Server之间的信息交互通过AVPs(Attribute-value pairs)。

EAP-TTLS定义了在第二阶段如何进行用户鉴权。在这个阶段用户鉴权可以使用EAP,例如MD5,也可以使用传统的鉴权协议,例如PAP、CHAP、MS-CHAP或MS-CHAP-V2。第二阶段的用户鉴权也不是必选的,因为在握手阶段执行了服务器对客户端的鉴权(可选),就不需要在进行用户鉴权。

 

      1. 握手阶段

当Client发送EAP-Response/Identity报文的时候,表明TLS握手阶段开始,这个报文中并不包含用户名信息,但它可以包含域名信息,如‘@myisp.com’。

TTLS服务器发出EAP-TTLS/Start来响应EAP-Response/Identity,这是一个EAP-Request报文,类型为EAP-TTLS,并且S位(Start)置1,无数据部分。这个报文指示客户端送上ClientHello报文,表明TLS握手开始。

客户端和TTLS服务器直到互相ChangeCipherSpec Finished,才算完成TLS握手成功。

在某些TLS握手协议中,TTLS服务器会发送自己的证书,连同一个可信任的CA颁发的证书链,这时客户端就需要配置可信任的CA的证书,以便执行对TTLS服务器的证书的鉴权。

如果客户端所希望鉴权是基于证书的鉴权,那么客户端自己也必须发行一个证书,而且必须保留一个基于证书的私钥。

      1. 隧道阶段

任何信息都可以在隧道阶段进行交互,在此阶段,客户端把信息编码到一系列的AVPs中,再通过TLS层加密发送到TTLS Server。

Client在AVPs序列中编码信息,开始第二阶段的数据交换,传送AVPs序列到TL进行加密,并发送结果数据给TTLS server。

TTLS Server从TLS层收到AVPs,并恢复成明文。并用自己的AVPs序列进行响应,TTLS Server将自己的AVPs序列,通过TLS层加密发送结果数据到Client。

如果AVP序列包含鉴权信息,它将继续传送到AAA Server。注意:EAP-TTLS Server和AAA Server有可能是一个,并且是相同的,在这种情况下,它仅仅只是在本地执行一下就可以了。

TTLS server 通过自己的AVPs序列响应。它传送AVP序列到TLS层进行加密并发送结果数据到Cleint。例如The TTLS可能发送密钥分发信息(key distribution information),或者转发从AAA/H收到的鉴权挑战。

这个过程直到TTLS server有足够的信息去下发EAP-Success或EAP-Failure为止。这样,如果AAA/H拒绝基于前转鉴权信息的Client,TTLS Server将下发EAP-Failure;如果AAA/H接受这个Client,TTLS Server将下发EAP-Success。

        TTLS Server在分发EAP-Success消息的报文中同时分发数据连接键控信息和其它的授权信息给Access Piont。

 

      1. 产生密钥元素(MSK

在TLS握手后,一个伪随机函数PRF(Pseudo-Random Function)用来把协商的主密钥、服务器的随机数、客户端的随机数展开成一串二机制序列,作为密钥元素,它的长度依赖协商的密码套。并包含6个部分:client_write_MAC_secret,server_write_MAC_secret,client_write_key,server_write_key,client_write_IV(可选),server_write_IV(可选)。其中一个常量字符串作为PRF的输入,用来产生这个序列。

EAP-TTLS通过这种方式,在客户端和AP之间产生密钥元素用于数据传送,完全一致的PRF可以用来产生所需大量的密钥元素。常量字符串设为‘ttls keying material’,如下所示:

EAP-TTLS_keying_material =

PRF(SecurityParameters. master_secret,

”ttls keying material”,

SecurityParameters.client_ random+SecurityParameters.server_random);

 

PRF(secret, label, seed)为伪随机函数(详细参考RFC2246),定义如下:

P_hash(secret, seed)  =        HMAC_hash(secret, A(1) + seed)+

HMAC_hash(secret, A(2) + seed)+

HMAC_hash(secret, A(3) + seed)+ ...

这里A()定义如下:

        A(0) = seed  A(i) = HMAC_hash(secret, A(i-1))

伪随机函数:

PRF(secret, label, seed) =P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);

这里,S1和S2为secret的各一半,如果secret为奇数个字节,则S1和S2共享一个字节。

用来产生密钥元素的主密钥、客户端随机数以及服务器随机数,必须是在握手阶段建立时使用的值。如果握手成功的话,不管是客户端还是服务器生成的密钥元素,都能保证是一致的。TTLS服务器通过AAA协议向AP分发产生的密钥元素。

注意:EAP-TTLS中客户端随机数、服务器随机数的顺序和TLS协议中是颠倒的,改变随机数的顺序是为了避免EAP-TTLS和TLS协议中定义的常量字符串中用户名为空的时候,发生冲突。

      1. 通过隧道成功进行CHAP鉴权流程

通过隧道成功进行CHAP鉴权。客户端仅对服务器进行单向TLS鉴权认证,CHAP作为隧道建立后的认证机制,并且TTLS服务器返回密码套和密钥元素。其中(1)-(11)属于TLS握手阶段,(11)-(15)属于TLS隧道阶段。EAP-TTLS的认证流程如下图所示,分下列几个步骤:

  1. AP收到后送出EAP-Request封包来要求Client做身份的验证;
  2. Client收到后将身份识别数据送回给AP,仅包含域名信息,包括用户名;
  3. AP对报文封装后转发给TTLS Server;
  4. TTLS Server收到客户端发来的身份识别数据后,送出EAP-TTLS/START帧进行应答,要求开始EAP-TTLS会话过程(报文类型为EAP-TTLS,无数据部分);
  5. AP将TTLS Server发给Client的身份识别数据转发给Client;
  6. Client收到后发送Hello 报文(为握手协议的开始),现在双方的加密及压缩数据的方式尚未协商完成,在Hello报文里包含协商过程所需的参数,如:所用的TTLS版本、session ID、一个随机数值与一些Client所能使用的整套加密方式(ciphersuite)等;
  7. AP将Client的Hello报文转发给TTLS Server;
  8. TTLS Server收到后,先确认session ID,其内容为空或无法辨识,会先选择新的来重新建立新联机,如果与先前步骤所用的session ID符合,则会从Client所送达的ciphersuite中挑选出后续步骤所要使用的。也送出Server端Hello的信息,其项目与Client送出的相同,并送出Server端的证书(certificate)、建立session key的数据(server_key_exchange)要求认证Client的证书(certificate _request及Server端完成hello交谈 (server_hello_done);
  9. AP转发给Client;当Client以内部之Issuer的公匙验证TTLS Server。certificate_request时,必须要响应,响应的数据包含自己的证书、经自己签署过的认证响应(certificate_verify验证通过后,发送EAP-Response封包,包含建立session key的数据 (client_key_exchange)、设定完成加密的参数(change_cipher_spec)与TTLS完成的信息;
  10. TTLS Server端收到Client的EAP-Response,给Client发送EAP-Request再次确认加密的参数(change_cipher_spec)与TLS完成的信息。
  11. Client收到Server端的EAP-Request,握手阶段结束。Client发送响应EAP-Response封包,携带用户鉴权的AVP,使用CHAP鉴权时,携带User-Name、CHAP-Challenge、CHAR-Password。
  12. AP封装为RADIUS的Access-Request,转发到归属AAA。
  13. 归属AAA完成用户鉴权,鉴权通过后,发送Access-Acept消息给TTLS Server携带授权参数。
  14. TTLS Server收到归属AAA的RADIUS认证响应后,则会发送EAP-Success,表示EAP认证通过。
  15. AP向Client发送EAP-Success。

 

 

 

 

      1. 通过隧道成功进行EAP-MD5鉴权流程

使用EAP-MD5用户鉴权,在握手阶段是和CHAP相同,仅仅区别在于隧道阶段使用MD5鉴权算法。

 

    1. EAP-TTLS编码

EAP-TTLS是EAP算法中的一种,分配的EAP代码为21。除了下面子章节描述的之外,其他的编码方式与EAP-TLS一样(参考RFC2716)。

      1. EAP-TTLS Start Packet

EAP-TTLS Start packet可能将来的协议中允许包含数据(EAP-TLS Start packet是不包含数据的)。

这样,EAP-TTLS Start packet包含数据被预留将来标准化,在这期间,服务器不能在EAP-TTLS Start packet中包含任何数据,客户端必须忽略这些数据而不是拒绝。

      1. EAP-TTLS Packets with No Data

本节用来澄清不包含数据的EAP-TTLS packet,不同于EAP-TTLS Start packet。

EAP-TLS中定义这种包是作为分包数据的响应使用的。当任何一方需要分包发送EAP-TLS packet,另外一方收到后回复分包的响应,用于告知发起方发送下一个分包片断。

EAP-TTLS使用分包响应的作用是和TLS一样的。当然也有另外一些场景需要发送EAP-TTLS packet with no data:

  1. 当TTLS Server发送最后一个协商阶段的EAP会话包时,Client必须响应EAP-TTLS packet with no data,用于允许TTLS Server发送最后的EAP-Success或EAP-Failure包;
  2. EAP-TTLS packet with no data也有可能在协商中间阶段发送。这种包可以简单理解为不包含AVPs的包。例如,在会话恢复阶段,Client首先发送Finished消息,TTLS Server响应Finished消息给客户端。因为TTLS Server必须等待Client密钥分发参数选择指示,所以不可能在发送Finished消息的EAP-TTLS包中搭载密钥分发AVPs。但是Client可能没有参数选择,这样就不会发送任何AVPs。Client就简单的发送一个EAP-TTLS packet with no data,允许TTLS Server通过发送密钥分发选择,继续协商阶段。
    1. TLS层AVPs封装
      1. AVP格式

    0                   1                   2                   3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           AVP Code                            |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V M r r r r r r|                  AVP Length                   |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                        Vendor-ID (opt)                        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |    Data ...

   +-+-+-+-+-+-+-+-+

 

   AVP Code

      AVP代码四字节。

 

   AVP Flags

      AVP标志,共一个字节,用于提供给接收者解析AVP必须的信息。

      'V' (Vendor-Specific)位指示Vendor-ID字段是否提供。设置为1标识提供Vendor-ID字段,为0标识没有提供。

      'M' (Mandatory)位指示AVP是否支持。如果设置为0,标识如果接收方不能过解析或支持AVP,则可以忽略。如果设置为1,表示接收方如果不能解析AVP时,协商失败,对于一个TTLS Server来说,就需要向客户端返回EAP-Failure,这就意味着放弃协商。

      'r' (reserved) 位保留,必须设置为 0。

   AVP Length

      AVP长度域时三个字节,用于表示AVP的长度,包括AVP Code, AVP Length, AVP Flags, Vendor-ID(如果提供) 和 Data。

 

   Vendor-ID

      如果AVP Flags 的'V'设置为1,表示AVP中包含Vendor-ID字段。 该字段四个字节,包含IANA分配给厂家的代码("SMI Network Management Private Enterprise Codes")。厂家必须保证在RADIUS、DIAMETER和REP-TTLS中保持一致。如果Vendor-ID为0,等同于没有提供Vendor-ID字段。

 

      1. AVP序列

在TLS层封装的数据是由一系列的0或AVPs组成。在序列中,每一个AVP和前一个AVP必须一个四字节的边界间隔,如果一个AVP不是四字节的整数倍,最后用0填充。

注意:AVP长度不包括填充的0。

 

      1. AAA Server最大兼容性方针

为了实现最大限度的兼容性,建议遵守以下AVP的使用指导原则:

  1. Non-vendor-specific AVPs必须从RADIUS定义的属性中选择,那就是说,属性代码必须小于256。这就能够提供RADIUS和DIAMETER的兼容性。
  2. Vendor-specific AVPs必须在RADIUS术语中定义。Vendor-specific RADIUS属性能够自动地转换为Diamter,反之不行。RADIUS Vendor-specific 属性使用RADIUS属性26和包括wendor ID、Vendor-specific属性编码和长度,参见RFC2865。

 

    1. 隧道鉴权

Tunnel之中可搭配任何形式的验证法,如Password、Certificate或Token,如MS-CHAPv2、MS-CHAP、CHAP、PAP、MD5等。

      1. 隐挑战

        某些鉴权协议使用的challenge/response机制依赖于挑战元素,并不是由鉴权服务器产生的,因此需要特殊处理。

        在CHAP, MS-CHAP和MS-CHAP-V2中,例如NAS发送一个挑战给客户端,客户端使用哈希算法使用密码加扰该挑战,向NAS回复响应,NAS将挑战和响应发送给AAA服务器。因为AAA服务器不是自己产生挑战,协议就容易被重放攻击。

        如果客户端能够产生挑战和响应,任何人都能够发现CHAP或MS-CHAP交换都能够用户冒充,即使使用EAP-TTLS。

      为了使得这些协议在EAP-TTLS使用时更加安全,必须提供一种产生挑战的机制,而不会被客户端控制或预知。一种成熟的方法就是使用上面提到的产生密钥元素的技术。

        当使用一种基于挑战的鉴权机制时,TTLS服务器和客户端都使用伪随机函数生成和挑战一样多的字节数。利用常量字符串“ttls challenge”,基于主密钥和握手阶段产生的随机数:

EAP-TTLS_challenge = PRF(SecurityParameters.master_secret,

                             "ttls challenge",

                             SecurityParameters.client_random +

                             SecurityParameters.server_random);

 
      1. 隧道鉴权协议

本文重点介绍如何在隧道阶段使用MSCHAPv2协议。

        1. MS-CHAPv2

MS-CHAP v2是一种基于密码的质询-响应式相互身份验证协议,使用工业标准的“信息摘要 4(Message Digest 4,MD4)”和数据加密标准(Data Encryption Standard,DES)算法来加密响应。身份验证服务器质询接入客户端,然后接入客户端又质询身份验证服务器。如果其中任一质询没有得到正确的回答,连接就被拒绝。MS-CHAP v2最初是由Microsoft当作一种PPP身份验证协议来设计的,以便为拔入和虚拟专用网(v*n)连接提供更好的保护。对于Windows XP SP1和Windows Server 2003家族,MS-CHAP v2还是一种EAP类型。

虽然MS-CHAP v2比以前基于PPP的质询-响应身份验证协议提供更好的保护,但它仍然容易受到脱机字典的攻击。 恶意的用户能够捕获成功的MS-CHAP v2交换,并想方设法地猜测密码,直至确定正确的密码。运用TTLS和MS-CHAP v2的组合,MS-CHAP v2交换就能通过TLS通道强大的安全性得到保护。

 

MS-CHAP-V2算法描述详见RFC2579 。RADIUS 属性定义格式见RFC2548。

客户端和TTLS服务器都产生17个字节的挑战元素,使用常量字符串“ttls challenge”,这些字节用作以下用途:

      MS-CHAP-Challenge [16 octets]

      Ident         [1 octet]

 

        客户把User-Name、MS-CHAP-Challenge和MS-CHAP2-Response的AVPs通过隧道发送给TTLS服务器,MS-CHAP-Challenge来自挑战元素。MS-CHAP2-Response包含Ident(取自挑战元素)、Flages(设置为0)、Peer-Challenge(设置为随机数)和响应(依照MS-CHAP-V2算法计算出来)。

        TTLS服务器收到客户端的AVPs时,必须校验MS-CHAP-Challenge AVP和客户端MS-CHAP2-Response AVP中Ident的值是否和挑战元素相等,如果不匹配,服务器则拒绝客户端,否则在Access-Request中转发AVPs给归属AAA。

        如果鉴权成功,归属AAA响应一个包含MS-CHAP2-Succes属性的Access-Accept给TTLS服务器。这个属性包含一个42字节字符串,该字符串用于鉴权归属AAA到基于Peer-Challenge的客户端。TTLS服务器通过隧道转发AVP到客户端。需要注意的是鉴权并没有完全结束,客户端仍然必须接收归属AAA的鉴权响应。

        在客户端收到MS-CHAP2-Success AVP时,它应该能够鉴别归属AAA。如果鉴权成功,客户端发送一个EAP-TTLS packet with no data包给TTLS服务器。TTLS收到客户端发送的这个空EAP-TTLS packet时,发送EAP-Success包。

        如果鉴权失败,归属AAA将会响应一个包含MS-CHAP2-Error属性的Access-   Challenge。这个属性中包含一个新的Ident和一个附加信息字符串(例如错误原因)以及是否允许重试的标志。如果错误原因是非期望的密码和允许重试标志,客户端可以继续改变用户密码进行重试。如果错误原因不是非期望的密码或客户端不想改变密码重试,即放弃EAP-TTLS协商。

        如果客户端希望更改密码,它要把MS-CHAP-NT-Enc-PW、MS-CHAP2-CPW和 MS-CHAP-Challenge AVPs通过隧道发送给TTLS服务器。MS-CHAP2-CPW AVP来自新的Ident和MS-CHAP2-Error AVP中收到的挑战。MS-CHAP-Challenge AVP只不过回应了新的挑战。

        TTLS服务器收到这些来自客户端的AVPs时,它必须校验客户端MS-CHAP2-CPW AVP 中MS-CHAP-Challenge AVP的值和Ident的值是否与MS-CHAP2-Error AVP的一致。如果任何一组不一致,服务器必须拒绝客户端,反之向归属AAA在Access-Request中转发这些AVPs。

        如果鉴权成功,归属AAA响应一个包含MS-CHAP2-Success属性的Access-Accept。这时候,TTLS服务器发送MS-CHAP2-Success给客户端,客户端基于这个AVP鉴别归属AAA,客户可以放弃协商,也可以发送一个EAP-TTLS packet with no data包给TTLS服务器,服务器回复EAP-Success。

        注意:一些附加的AVPs将会在MS-CHAP-V2中发送给归属AAA。例如MS-CHAP-Domain。TTLS服务器必须能够连同MS-CHAP2-Succes一起,隧道发送这些鉴权相关属性。

 

  1. 遗留问题
  1. 服务器证书如何部署?
  2. X.509证书格式,没有具体研究,需要参考RFC2459,在TTLSTLS中使用X.509v3版本的证书。
  3. “当Client以内部之Issuer的公匙验证TTLS Server”,客户端内部Issuer的公匙是什么,如何验证服务器发送回来的证书?->可以暂不考虑,我们可以只考虑服务器端需要处理的流程。
  4. 有关TTLS流程中的握手协议定义,参考RFC2246的章节7.4包括Hello Message、服务器/客户端证书、证书验证等消息格式和过程定义。
  1. 参考资料

[1] PPP Extensible Authentication Protocol(EAP)         RFC 2284。

[2] PPP EAP TLS Authentication Protocol    RFC 2716。

[3] The TLS Protocol Version 1.0  RFC 2246。

[4] Remote Authentication Dial In User Service(RADIUS)        RFC 2865。

[5] draft-ietf-pppext-eap-ttls-05      Paul Funk.July 2004。

[6] PPP Extensible Authentication Protocol (EAP)        RFC3874。

[7] Microsoft PPP CHAP Extensions, Version 2        RFC2759

[8] Microsoft Vendor-specific RADIUS Attributes        RFC2548

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在,都有一个你没有努力的曾经。