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-TTLS有v0和v1两种版本，v0版本是命名为EAP-TTLS，v1版本命名为EAP-TTLSv1。根据协议和需求，我们需要支持的鉴权算法为v0版本的TTLS算法，即EAP-TTLS的v0版本。

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. 1. 传输协议

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

1. 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. 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. 1. 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. 1. 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. 1. 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. 1. 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. 1. 1. 通过隧道成功进行EAP-MD5鉴权流程

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

1. 1. EAP-TTLS编码

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

1. 1. 1. EAP-TTLS Start Packet

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

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

1. 1. 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. 1. 1. AVP序列

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

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

1. 1. 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. 1. 隧道鉴权

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

1. 1. 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. 1. 1. 隧道鉴权协议

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

1. 1. 1. 1. MS-CHAPv2

MS-CHAP v2是一种基于密码的质询-响应式相互身份验证协议，使用工业标准的“信息摘要 4（Message Digest 4，MD4)”和数据加密标准（Data Encryption Standard，DES）算法来加密响应。身份验证服务器质询接入客户端，然后接入客户端又质询身份验证服务器。如果其中任一质询没有得到正确的回答，连接就被拒绝。MS-CHAP v2最初是由Microsoft当作一种PPP身份验证协议来设计的，以便为拔入和虚拟专用网（VPN）连接提供更好的保护。对于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，在TTLS、TLS中使用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

最后

以上就是善良眼睛为你收集整理的EAP-TTLS预研报告的全部内容，希望文章能够帮你解决EAP-TTLS预研报告所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。