接入控制层的安全协议 __〈无线局域网安全务实：WPA与802.11i〉读书笔记
接入控制层的安全协议
2.1 IEEE 802.11i，RSN, WPA之间的关系
IEEE（电气电子工程师学会）下有一个名为标准协会（SA)，该协会负责制定IEEE 802系列（局域网和城域网）的标准。IEEE 802 分成一系列工作组，每个工作组负责某一方面标准的制定，其中.11的工作组负责无线局域网标准的制定
标准IEEE802.11i定义一种新型的无线网络，名为RSN(Robust Security Network)。为了加入RNS网，无线设备必须具备一些新的性能，要求支持硬件加密，这些是通过软件升级不能达到的。IEEE 802.11i根据已存Wi-Fi产品的性能开发出一个安全的解决方案，这就是TKIP（临时密钥完整性协议），但是工业界没法等到标准获得批准的那一天，于是Wi-Fi联盟采取了一个新的方案，它基于RSN的草案，仅仅对TKIP进行了细化，这个RSN的子集称为WPA。RSN除了支持TKIP，也支持AES算法，而WPA仅支持TKIP
2.2 安全分层
对于一个物质的认识进行分层，这是便于更好的认识与实现的通用做法，比如TCP/IP分层，OSI分层。
在无线局域网安全环境中，分成三个层次：
- 无线局域网层是工作层。这一层可以理解成硬件网卡和驱动，负责处理原始的通信信息，通告性能和接受入网的申请。一旦安全内容建立，这一层还负责对数据进行加密和解密
- 接入控制层是管理层。这一层负责管理安全内容，它防止数据流向敌人或来自敌方的信息进入。通过对话的方式，它告知认证层：何时打开安全内容，何时参与创建相关的临时密钥。
- 认证层。制定决策和接受（或拒绝）申请者的身份证明，认证层对任何一个申请加入局域网的对象都具有否决权，一旦它接受了对象的申请，就会将权力分派给接入控制层。
通常，无线局域网层位于包含AP的无线装置中 ; 接入控制层完全位于AP中。尽管在小系统中，认证层可能位于AP，但在大型系统中认证层位于认证服务器，这种结构便于管理用户数据库。IEEE 802.11标准只适用于无线局域网，此标准工作组不负责定义该领域之外的行为，对于接入控制层，由另一个工作组（802.1X)来定义最为合适（该组很早就展开了安全标准的工作）
2.2.1 接入控制层
接入控制层中所采取的步骤通常都遵循以下模式：
- 认证方收到申请者的接入申请
- 申请者出示自己的身份证明
- 认证方请求来自授权机构的认证
- 授权机构发出允许或拒绝的指示
- 认证方允许或拒绝申请者的加入
有三个协议，它们在WPA和RSN中是用来实现接入安全的
- IEEE 802.1X
- EAP: 扩展认证协议
- RADIUS: 远程认证拨入用户业务
前两者对于WPA和RSN是必须强制实现的，后者是可选项
补充： IEFT标准
IETF是Internet工程任务组，它和IEEE是两个不同的组织，主要负责制定Internet上所使用的基本协议，从IP协议开始，都是该组织逐一制定的。其发布的文档称为RFC, Request for Comments，与它的命名不同，大多数RFC文档是非常稳定的，很少需要修订。IEFT中的新概念都是由草案文档显现出来，然后交由大家请讨论，这些草案并不具有相应的编号，它由相关主题及作者姓名构成，例如：draft-haverinen-pppext-eap-sim-03.txt是关于用SIM智能卡的GSM蜂窝电话系统中就用EAP的第三版草案，作者为Haverinen。由工作组提出的草案通常名称是“ietf”，例如：draft-ietf-pppext-eap-ttls-00.txt，它是如何使用EAP与TLS认证系统协同工作的。
2.3 IEEE 802.1X
IEEE 802.1X是在用户接入网络的入口处实现接入控制。它最初并非是为无线网络设计的，在IEEE 802.11第一版完成以前，802.1X的起草工作就开始了，它最初是为了保证交换式以太网集线器上的端口的安全。它的逻辑是：首先申请者申请接入，然后认证方向认证服务器请示并根据请示结果来决定是否允许申请者加入。如果认证服务器内置于接入点中，那么就没有使用RADIUS的必要了，因为认证方和认证服务器都处于AP中，它们不需要通过网络进行对话。对于拨号或以太网LAN端口接入，因为每一个申请者都占用了一条物理连接，而黑客想要控制这种物理连接是非常困难的。但对于WI-Fi环境而言，如果不加保护的话，当一个合法用户接入网络时，黑客也会通过盗取该用户的身份从而轻易接入该网络，所以，对于Wi-Fi环境而言，需要将授权作为一种机制，这可以通过将消息认证（完整性）作为授权过程的一部分来加以实现。
- 简单交换式集线器环境下的IEEE 802.1X
认证方和认证服务器之间需要用到高层协议，802.1X中引用了EAP协议。申请者和认证方也互发EAP消息，在认证过程中，认证方可能将申请者发送的EAP消息转发给认证服务器。如果认证服务器处于网络的某一远端，则这些消息就必须用某种高层协议通过网络进行传输，WPA中要求采用RADIUS协议来实现，它能基于IP网络传送这些请求。在拨入网络和IEEE802.1X之间的一个不同点在于IEEE802.1X不需要使用PPP协议，因为IEEE 802局域网协议本身就是被设计用来在局域网传送数据包的。所以基于局域网的EAP就叫做EAPOL
- Wi-Fi 无线局域网中的IEEE 802.1X
根据IEEE 802.1X的定义，每个移动设备可以被认为是希望获得AP服务（等同于有线网络中的连接）的申请者。为了进行有效地处理，AP需要为每个发出请求的申请者产生一个带有认证方的逻辑端口。每个认证方都负责对相应的移动申请者进行接入控制。有人逻辑端口和认证方，自然也少不了相应的逻辑可控开关，可控开关一开始也是open的。由于认证方和开关在物理上并不存在，所以具体操作中IEEE 802.1x实体的数目与处于连接状态中的移动设备的数目是一样的。
2.4 EAP原理
EAP消息可与各种上层认证算法一同使用（如TLS，SSL,Kerberos V5), EAP 也允许双方交互它们所希望采用的认证算法，即使该算法是新近发明出来的算法。但是与认证算法相关的具体内容在EAP中没有定义，EAP也不关心。EAP之所以能用标准的方式来处理双方认证过程的一部分，又能以其特定的方式处理另一部分，是因为它具有扩展性。我们把那些与认证相关的消息称为“中间消息”，因为它们通常出现在初始认证之后和认证结束之前。在整个认证结束前，通信双方需要交互大量的中间消息，EAP之所以有扩展性是因为这些特定的认证算法的中间消息的具体细节由其它RFC文档定义实现，例如，有一篇RFC文档就讲述了如何基于EAP使用传输层安全协议（TLS)。
EAP由RFC 2284中定义， RFC2284非常精简，它规定了4种可供传送的消息：
- Request: 认证方发送给申请者的消息
- Response: 申请者发送给认证方的消息
- Success: 认证方发送给申请者的消息，用来指示允许申请者接入;
- Failure: 认证方发旁顾给申请者的消息，用来指示拒绝申请者接入
在IEEE802.1X情景中，大多数情况下认证方会通过RADIUS协议将这些消息转发给认证服务器。在这种情况下，就是由认证服务器来产生Request, Success, Failure这些消息，然后再早认证方传送给申请者。
可以根据EAP中的Type域对Request和Response进行进一步分类。标准中只定义了前6种消息类型，其余尚未定义的保留给专用的认证算法使用（在大多数情况下，Type域用来指示某一特定的认证算法，但在少数情况下，它用来定义某种特殊用途的消息，如Type为2和3时就不是认证算法），如13就是TLS，254是WPS。
- Type为1时指明该消息是Identity，在EAP初始认证阶段都会使用它：即由认证方向申请者发送EAP-Request/Identity消息，申请者返回EAP-Response/Identity消息。Identity消息既可以被认为是特殊用途消息，也可以被认为是基本的认证消息。在修订的EAP草案中定义了最为简单的认证交互：
1.EAP-Identity Request(来自认证方）
2 EAP-Identify Response(来自申请方）
3 EAP- Success（来自认证方）
这里，设备通过了“认证”，获得了完全的信任，即“尽管你没有证明你的身份，但我还是决定相信你”，或者证据可能通过别的方式获得了。这种空认证只使用在简易的无线环境中，在这些网络中，密钥被预先加载（称为预先共享密钥），仅靠单纯的加密来保证通信的安全。
EAP-Idetity消息交互就其自身而言被认为是一种完整的认证算法，如果你在该认证完后再进行第二种认证如TLS认证，那么，你就相当于依序采用了两种认证算法。新的EAP草案中称为“序列认证”。许多新的解决方案中都采用了依序进行多重认证的方法，它允许客户在公开自己的身份前对网络进行认证，如PEAP，直到最后收到EAP-Success或EAP-Failure消息。
- Type为2时指明该消息是notification消息，它是用来传递某些需要在用户设备上显示的文本，所传送的文本可能是“请输入你的密码”或“准备支付账单”等。
- Type为3时指明该消息是NAK消息。当设备不支持收到请求中所标志的认证算法时，可以返回此消息。例如，某一设备不支持TLS认证算法，当它收到Type域为TSL的Request包时，它就可以返回NAK的Response
EAP中的Success和Failure, 这两种消息都不包含具体数据，它们都是没Type域的，所以非常小。在所有的认证协议中，Success和Failure这两种消息都是不可缺的，所以AP不必关心具体认证算法的细节就能够识别出认证过程何时结束（当然，AP只有在收到RADIUS Accept消息之后才能作出是否允许接入的决定）。
EAP消息格式：
2.5 EAPOL
EAP最初是为经由调制解调器的拨号认证系统设计的，因而它不是一个局域网协议，所以IEEE 802.1X制定了基于局域网的EAP协议，便于在申请者和认证方之间传送EAP消息。但是IEEE802.1X只描述了在以太网和令牌环网中，EAP的帧格式，没有涉及到IEEE 802.11。
EAPOL有5种类型消息：
- EAPOL-Start：当申请者刚连上局域网时，它并不知道认证方的MAC地址。为了保证一切能够正常进行，IEEE 802.1X定义了一种称为EAPOL-Start的消息，通过向为IEEE 802.1X认证方保留的某一专用的组播MAC地址发送这种消息，申请者就知道是否有认证方的存在了。
- EAPOL-Key: 一旦认证方决定允许申请者接入网络，它就会采用这种消息类型向申请者发送加密（或其他）密钥。在发送密钥之前对它们进行加密是非常必要的，但IEEE802.1X中并没有作相关规定。在WPA和RSN密钥分层中，描述了如何应用稍加修改的EAPOL-Key消息生成加密密钥并在允许申请者接入之前验证双方是否拥有正确的密钥。
- EAPOL-Packet：EAPOLo数据帧，它是用来发送实际的EAP消息的。它仅仅是在局域上传送EAP消息的载体，也是制定EAPOL协议的最初目的。
- EAPOL-Logoff：用来指示申请者希望离开网络
- EAPOL-Encapsulated-ASE-Alert：该消息允许一个未授权设备向系统发送管理警告，这是非常危险的，在WPA/RSN中没有使用该消息。
2.6 IEEE 802.1X中所用的消息
IEEE802.1X使用EAP在申请者和认证方之间传递消息，下面为完整的认证序列消息（在802.11中）：
- 当一个申请者想加入网络时，首先它必须引起认证方的注意。在有线网络中，用户将电缆插入集线器的端口会引起认证方的注意; 在无线环境下设备发起的联系也会引起认证的注意。如果认证方并没有察觉到申请者的到来，申请者必须向认证方发送EAPOL-Start消息
- 然后，认证方向申请者发送EAP-Request/Identity消息，然后申请者回复EAP-Response/Identity
- 当申请者对首条EAP Request/Identity消息以IEEE 802.1X消息包应答之后，才可与认证服务器进行交互，这样能保证认证服务器的效率。认证方在获取申请者的身份Response后，它需要与认证服务器进行联系，以确认是否允许申请者接入。为了简化认证方的工作使其不必了解各认证算法的具体细节，特定于各认证算法的EAP消息都被直接传送给服务器。在整个认证过程中，认证方对于申请者向认证服务器传送的EAP消息，它只是做快速扫描，它只需关心它所能理解的那些特定消息，特别是EAP-Success/Failure消息。它必须等到认证服务器发出接受或拒绝申请者的相关指示，如果认证方与认证服务器之间的交互是基于RADIUS协议的，那么认证服务器会向认证方发送一条RADIUS消息作出相关指示。
2.7 RADIUS
虽然在IEEE 802.11i标准中并未指明包括RADIUS，但在许多厂商产品的具体实现中都采用它在AP和认证服务器之间进行通讯。RADIUS由IETF制定，它被设计应用于TCP/IP类型的网络中，它假设设备是基于IP网络与RADIUS服务器进行交互的。在无线局域网中，AP好比NAS(网络接入服务器），RADIUS服务器相当于AS(认证服务器）。与WPA/RSN相关的规范文档：
RFC2865: 远程认证拨入用户业务（RADIUS)
RFC2866: RADIUS计费
RFC2867: RADIUS隧道计费
RFC2868: RADIUS隧道认证
RFC2869: RADIUS扩展—---------关于如何基于RADIUS使用EAP
RFC3162: 基于IPv6的RADIUS
RFC2548: 微软厂商相关RADIUS属性
3.7.1 RADIUS工作机制
RADIUS 核心协议有4条相关消息：
- Access-Request (NAS—>AS)
- Access-Challenge (NAS<—AS)
- Access-Accept (NAS<— AS)
- Access-Reject(NAS<— AS)
RADIUS协议最初是为拨入调制解调器协议设计的（PPP协议），它拥有两种认证选项：PAP和CHAP.
- PAP是一个简单的基于用户名/密码认证的算法。用户进行拨入，NAS(网络认证服务器）予以应答，告知用户它支持PAP认证，然后用户向NAS发送用户名/密码，接着NAS向RADIUS服务器发送Access-Request消息，该消息内含有用户名和密码信息。然后，RADIUS服务器以Access-Accept或Access-Reject消息进行应答，NAS根据返回的消息作出不同的判断。它在电话线路上明文传送用户名密码，此时对该线路进行监听的黑客都能轻易获得相关数据。
- CHAP要求服务器随机生成一个数据即所谓的Challenge发送给拨入系统，拨入系统采用此质询数据对密码加密，然后回送给服务器进行认证。
首先用户在电话线路上仅向NAS发送用户名而不传送明文密码，接着NAS向用户返回一个质询数据。由于该质询数据是由RADIUS服务器产生的，所以NAS要向服务器发送Access-Request消息，其中含用户名 ；服务器使用Access-Challenge消息将质询数据返回给NAS。然后在大多数实现中，NAS都避免打扰服务器而自行生成Challenge数据，传送给用户。用户用该Challenge数据对密码进行加密发送给NAS，最后NAS就能将质询数据，用户名，用户加密密码一起发送给AS，并指出它正在使用CHAP认证算法。所以在CHAP中密码是被加密发送的，它保证了某种程度的安全，因为每次接入时Challenge数据是变化的，但是它易受到字典攻击。
- 微软对CHAP算法做了改进，即MS-CHAP。微软通过RFC2548，为它们的属性进行了标准化
- 在WPA/RSN中，要求RADIUS与WPA/RSN中的安全协议同工作，需要更改RADIUS中某些消息的用法，例如，为了支持EAP，需要使用Access-Challenge消息，并非是为了返回质询数据，而是作为一种方式来传送EAP请求和应答。
RADIUS消息的基本格式：
属性（Attributes)示例：
2.7.2 基于RADIUS的EAP
在早期的RADIUS标准中，只有两种消息可以传送认证消息：NAS采用Access-Request消息向RADIUS服务器发送数据，而RADIUS服务器则采用Access-Challenge 消息向NAS发送数据。Access-Challenge消息本应具有CHAP中质询数据那样特殊用途，但在RFC2869中仅仅是一种非常通用的方式使用该消息，即采用该消息由RADIUS服务器向NAS回传消息，将相应的EAP消息放入Access-Request消息和Access-Challenge消息中，就实现了基于RADIUS的EAP认证。
在RADIUS中，EAP消息被置于一个或多个专用的属性域中进行发送，这些属性的类型值均为79。所有通用的EAP消息都能这样发送出去。在EAPOL中有一条称为EAPOL-Start的消息，当一个新设备希望接入网络时，它就应发送这条消息通知认证方，这样认证方就能有所行动。RFC2869定义了一条类似的消息称为EAP-Start消息，它具有EAP属性但不包括具体数据，该属性仅有2个字节。其中类型域占一个字节，具体值为79，用来指示EAP(消息属性); 另一个字节为长度域所占用，具体值为2。当NAS希望与RADIUS服务器交互时，就可以使用这条消息启动RADIUS服务器。具体可以见下图：
在图中，我们看到AP代替了原先的拨号NAS，尽管其中的原理是一样的。AP含有IEEE 802.1X认证方，它采用EAP消息与新到客户（申请者）进行交互。IEEE 802.1X中认证方打算转发给认证服务器的EAP消息则需要以RADIUS消息格式进行封装，然后发送给RADIUS服务器。
首先，新设备（申请者）向AP认证方发送EAPOL-Start消息。如果AP知道RADIUS服务器支持EAP，它就会继续下去，向客户设备发送EAP-Request/Identity消息并将客户设备的应答消息直接转发给服务器。但是，如果它不能确定服务器是否支持EAP，则必须向RADIUS服务器以Access-Request的形式发送EAP-Start消息，如果RADIUS服务器不支持EAP，它就返回一条拒绝消息。如果RADIUS服务器支持EAP，它就会以RADIUS Access-Challenge消息的格式向认证方发送EAP-Request/Identity消息。如图8.14所示，在交互快要结束时，服务器发送EAP-Success或EAP-Failure消息指示认证结果。
2.7.3 WPA和RSN中RADIUS的使用
如图8.14所示，RADIUS和基于RADIUS的EAP的工作机制非常适合于Wi-Fi无线局域网中WPA/RSN体系。但是Wi-Fi网络和拨号网络之间存在着一个重要区别：在拨号系统中，用户是否有权接入网络是唯一需要关心的事情，这是因为当用户一旦接入网络，由于电话线本身的物理特性，黑客是很难进行攻击的（尽管理论上存在攻击的可能性），但是在Wi-Fi环境中，通过盗取合法用户的MAC地址并据此入侵已建立好的一条连接并非难事。所以，Wi-Fi环境中提供了基于单个数据包的认证和完整性校验等安全机制。为了提供这种保护，认证服务器必须传送一个主密钥给AP。早期的基于RFC2865—RFC2869文档的RADIUS服务器并没有提供从认证服务器向NAS传送密钥的能力，这些RFC文档中都是假设供验证用的密码是通过别的方式传送。
微软制定了RFC2548：微软与厂商相关的RADIUS属性，它在扩展中包含一个MS-MPPE-Recv-Key的属性，它是专门用来向NAS传送密钥信息的。RFC2548中具体定义如下：MS-MPPE-Recv-Key属性含有微软点对点加密协议（MPPE)中使用的会话密钥，这些密钥是对远端产机发送给NAS的数据包进行加密用的，该属性仅包含在Access-Accept消息中。
在IEEE802.11i中， “MPPE”换成了“WPA”或“RNS”, “远端主机”则变成了“移动设备.”,WPA采用了该属性，将其作为一种推荐方式用于从RADIUS服务器向接入点传送主密钥信息。采用这种属性后，在进行传输之前，它无需预先声明该属性支持（或要求）对密钥原始数据的加密。
在讨论WPA/RNS如何与RADIUS协同工作时，首先要求AP支持RADIUS（这里的RADIUS必须支持EAP的扩展部分，并支持微软密钥传递属性，除此之外，当RADIUS服务器被要求向AP发送成对组密钥（PMK)时，该RADIUS服务器知道如何处理）。WPA要求实现RADIUS，但RSN中并没有此规定。
