rfc3748中文.docx
《rfc3748中文.docx》由会员分享，可在线阅读，更多相关《rfc3748中文.docx（26页珍藏版）》请在冰豆网上搜索。
rfc3748中文
1.引言
本文档定义了扩展认证协议，一个支持多路认证方法的认证框架。
EAP通常直接运行在数据链路层，例如PPP协议或者是IEEE802,不需要IP地址。
EAP自身支持消除重复和转发，但是它依赖于底层正确的排序。
EAP本身不支持分片，然而特别的EAP方法可能支持这个。
EAP架构的优势之一就是它的灵活性。
EAP是用来选择一个专门的认证方法，通常是在认证方在得到更多的信息以后决定使用什么专门的认证方法。
与其让认证方不断更新来支持每个新的认证方法相比，EAP更倾向于使用后台认证服务器，它可以实现一些或所有认证方法，此时认证方工作于传递模式。
1.1要求说明书
1.2术语
本文档经常使用下列词语：
认证方：
启动EAP认证的链路终端。
被认证方：
回应认证方的链路终端。
（也就是客户端）
客户端：
在中，链路终端回应被认证方。
在本文档中，这个链路终端被称为被认证方。
后台认证服务器：
后台认证服务器是一个提供认证服务给认证方的实体。
当被使用时，这个服务器通常为认证方使用EAP方法。
（也就是AAA服务器）
AAA：
认证，授权和计费。
支持EAP的AAA协议支持包括RADIUS和Diameter。
在这个文档中，AAA服务器和后台认证服务器这两个术语是相同的意思。
EAP服务器：
终止和被认证方进行EAP认证方法的实体。
在没有后台认证服务器时，EAP服务器是认证方的一部分。
在认证方工作在传递模式的情况下，EAP服务器相当于后台认证服务器。
简单丢弃：
这意味着执行操作没有做进一步处理的能力，只是将数据包简单的丢弃。
该执行应该提供记录错误的能力，如丢弃包的内容；并在统计处记录下该事件。
成功认证：
在本文档中，成功认证是一个EAP消息的交换，同样也是认证方决定允许被认证方访问和被认证方决定访问的结果。
认证方的决定通常包括认证和授权两个方面；被认证方可能已经成功的向认证方得以认证，但是访问可能由于政策原因被认证方拒绝。
消息完整性检查：
主要的哈希函数用于认证和数据完整性保护。
这常常被称为消息验证码。
加密分离：
两个密钥（x和y）是独立的加密，如果对手知道了在协议交换中所有的信息，也不能进行破密，即从X中计算出Y，或者从Y中计算出X。
特别是，这个定义允许对手知道所有以明文形式发送的随机数，和在协议中使用的所有可预见的计数器的值。
如果密钥是分开加密的，没有捷径来从Y中分离出X或从X中分离出Y，若对手想得到密钥，他必须执行的计算，相当于执行一个穷尽搜索。
主会话密钥（MSK）：
建钥资料是从EAP客户端和服务器间获取，通过EAP方法输出。
MSK至少是64字节长度。
在现有的实现中，一个AAA服务器作为一个EAP服务器来传送MSK到认证方。
扩展的主会话密钥：
附加的建钥资料从EAP客户端和服务器间获取，通过EAP方法输出。
EMSK至少64字节的长度。
EMSK不与认证方或其它第三方共享。
EMSK是为将来使用的，现在还没有定义。
结果标志：
如果在方法的最后信息被发送或者接收以后，它提供结果显示：
1）被认证方知道它是否认证了服务器，还有服务器是否认证了它。
2）服务器知道它是否认证了被认证方，还有被认证方是否认证了它。
在这种情况下，成功的认证足够获得访问批准，于是被认证方和认证方将会知道另外一方是否提供或者接收访问。
也可能不经常是这种情况。
一个认证的被认证方可能被拒绝访问，由于缺少授权或者其它的原因。
既然EAP交换是在被认证方和服务器间运行的，其它节点（例如AAA代理）也可能影响到授权的决定。
这在中被详细的讨论。
1.3适用性
EAP被设计用来使用在网络访问认证上，IP层连接到达不了的地方。
不建议将EAP用于其它用途，例如块数据传输。
由于EAP不需要IP连接，它仅仅为认证协议的可靠传输提供了足够的支持，其余的什么也没有。
EAP是锁步协议，它仅仅支持每次传输一个数据包。
因此，EAP不能够有效的传输块数据，不像传输层协议例如TCP或STCP。
虽然EAP为转发提供了支持，但是在它假定底层保证有序传输的基础上，所以不支持乱序接收。
由于EAP不支持分片和重组，EAP认证方法产生的有效载荷大于EAPMTU需要提供分片支持的最小值。
虽然认证方法例如EAP-TLS支持分片和重组，在本文档中EAP方法不支持。
因此，如果EAP数据包的大小超出了EAP链路的MTU，这些方法将会遇到困难。
EAP认证是由服务器（认证方）发起的，而很多认证协议是由客户端发起的，因此，为了运行EAP，认证算法增加一两个额外的信息是必要的。
凡基于证书的认证都是支持的，由于证书链的分片，额外的往返包的数量可能增多。
一般来说，一个分片的EAP数据包由于有分片，将需要很多的往返包来发送。
例如，一个认证链的大小是14960个字节，将需要10个往返来发送一个1496字节大小的EAPMTU。
EAP运行在底层，此时会有很多重要的包发生丢失，或者在认证方和认证服务器之间的通信时，重要的包丢失也发生，EAP方法需要很多往返包来解决这些问题。
在这种情况下，建议EAP方法使用较少的往返包。
2扩展认证协议
EAP认证交换过程如下：
1、认证一方向另一方首先发送一个身份请求，并等待对方发来响应。
2、对方在接到身份请求要求时，它应发送一个身份响应包，他们的ID必须相同
3、认证方检查包类型是否是身份响应包，且ID是否与发送请求时一致。
4、在收到身份响应时，认证方根据身份，检查通信实体数据库，以查找对应的认证方式，如找到则开始发送响应的认证请求。
5、对方在收到认证请求时，首先检查它自己是否支持认证者所要求的认证请求，如不支持，则发送一个NAK否认包，如支持，则发送认证响应。
6、认证者检查响应包，如是NAK否认包，则重发对方允许的认证请求。
如是上一次的认证请求的响应，则检查它是否是它所期待的响应以决定认证成功或失败，从而决定链路的打开或关闭。
7、如上一步成功，向对方发送认证确认包，以使对方把链路打开，通知上层网络控制协议进行网络通信协议参数的协商，随着各个网络控制协议打开之后，PPP就把数据链路交给通信网络协议，这时双方才可以进行实际的通信。
优点：
EAP协议能够支持多种认证方法。
网络访问服务器设备不需要理解每个认证方法，同时可能为后台认证服务器作传递代理。
支持传递是可选的。
认证方可能认证本地的被认证方，同时可能为非本地被认证方和不能当地实施的认证方法作为传递方。
被认证方和后台认证服务器相分离，简化了证件管理和政策的制定。
缺点：
在P2P中使用，EAP需要增加一个新的认证类型到PPPLCP，因此PPP需要作出改变才能够使用它。
它与之前的PPP认证模型不同，在链路建立阶段不指定认证方法。
同样，交换机或无线接入点为使用EAP协议需要支持。
被认证方和后台认证服务器分开，它使安全性分析复杂化，密钥分配也复杂化了。
2.1支持序列
EAP会话可能利用各种方法。
一个典型的例子，在身份请求后跟着一个EAP认证方法，例如MD5-挑战。
然而，在一个EAP会话中，认证方和被认证方必须使用一种认证方法，之后认证方必须发送成功或失败数据包。
一旦被认证方已经发送和初始请求一样类型的回应包，认证方在一个给定的方法完成最后一轮之前，不能发送一个不同类型的请求包，也不能在初始认证方法完成之后，发送请求任意类型的额外方法；被认证方收到上述请求包时，必须把它们作为无效的，简单丢弃。
因此，不支持身份重新查询。
被认证方在初始non-NaK回应被发送之后，不能为回复请求再发送一个NaK。
由于攻击者可能发送伪造的EAP请求包，认证方收到意外的NaK时应该丢弃它并且记录这件事情。
在一个EAP会话中不支持多路认证方法，因为它们容易受到拦截式攻击，并与现有的实现不兼容。
当使用一个特别的EAP认证方法时，其它的方法在它之中运行（一个隧道方法），此时上述在一个EAP会话中禁止多路认证方法就不适合了。
这种隧道方法是一种特别EAP的认证方法。
可提供后向兼容，因为一个不支持隧道方法的被认证方，能够用NaK回复初始EAP请求。
为了解决安全性的缺陷，隧道方法必须支持保护对抗拦截式攻击。
2.2EAP多路传输模型
从概念上讲，EAP的操作包括以下部分：
a）底层。
底层负责在认证方和被认证方之间转发和接收EAP帧。
EAP已经在各类的底层上运行，例如PPP，有线IEEE802局域网，无线局域网，UDP和IKEv2，TCP。
底层的表现在第3节中讨论。
b）EAP层。
EAP层通过底层收到和转发EAP数据包，完成重复检测和转发，同时从EAP被认证方和认证层传递和接收EAP信息。
c）EAP被认证方和认证层。
基于代码字段，EAP层多路分离输入EAP数据包到EAP被认证方和认证层。
通常情况下，在一给定主机上运行的EAP，将支持被认证方或者认证方的功能，同样对于一个主机来说，也可以同时担当EAP被认证方和认证方。
此时，EAP被认证方和认证层都将会出现。
d）EAP方法层。
EAP方法通过EAP被认证方和认证层，实现认证算法和接收转发EAP信息。
由于EAP本身不支持分片，现在这是EAP方法的责任，这将在第5节中被讨论。
EAP多路传输模型在下图一种说明。
注意这里没有要必须遵守这个模型，只要线上行为与它保持一致就行。
在EAP中，代码字段功能很像在IP中的协议号码。
假定EAP层根据代码字段多路分离传入的EAP数据包。
接收到的EAP数据包（1请求，3成功和4失败）被EAP层传到EAP的被认证方层。
带有代码=2（回应）的EAP数据包被传送到EAP认证层。
在EAP中，类型字段功能很像UDP或TCP中的端口号码。
假定EAP被认证方和认证层根据它们的类型多路分离输入的EAP数据包，然后把它们传送给相应类型的EAP方法。
在一台主机实施的EAP方法可能注册来接收从被认证方或认证方来的数据包，或者都接收，这样根据它所支持的功能角色。
通知回复仅仅被作为确定被认证方接收到通知请求，不是它已经处理了通知请求，或者向使用者显示了这个信息。
它不能假定通知请求或回复的内容对另外一种方法是有效的。
通知类型将在节讨论。
NaK（类型3）或者扩展的NaK（类型254）都是用于协商的目的。
被认证方回应一个NaK响应或者扩展NaK响应，给不想接收类型的初始EAP请求。
它不能假定NaK响应的内容是另一种方法有效。
NaK类型将在节被讨论。
带有成功或失败代码的EAP数据包不包括类型字段，同时也不被传送给一个EAP方法。
成功和失败将在第节中讨论。
鉴于上述考虑，成功，失败，NaK响应和通知请求/回应信息不能用与承载注定要发送到其它EAP方法的数据。
2.3传递行为
当作为一个传递认证方时，认证方检查代码，身份，字段长度，在节描述的那样。
它把从被认证方收到的、目的地址是它自己认证层的EAP数据包，转发给后台认证服务器；从后台认证服务器接收到的、目的地是被认证方的数据包被转发到传递认证方。
一个主机收到EAP可能仅仅对其做下列三件事情中的一件：
执行它，丢弃它，继续传送。
继续传送的决定通常是根据检查后的代码，身份和字段长度。
一个传递认证方必须能够把从被认证方接收的带有代码=2（回应）的EAP数据包转发给后台认证服务器。
它也必须能够吧从后台认证服务器收到EAP数据包，将代码=1（请求），代码=3（成功），代码=4（失败）的EAP数据包传递给被认证方。
除非认证方本地完成一个或多个支持认证方角色的认证方法，EAP方法层包头字段（类型、类型数据）作为转发决策的一部分不被检查。
当认证方支持本地认证方法，它可能检查类型字段来决定是否执行这个数据包或者转发这个数据包。
符合传递认证方的操作，必须默认转发任何类型的EAP数据包。
接收到代码=1（请求），代码=3（成功），以及代码=4（失败）的EAP数据包被EAP层多路分离，并且被传送到被认证方层。
因此，除非一个主机实现EAP被认证方层，否则这些数据包将会被简单丢弃。
同样的，接收到代码=2（回复）的EAP数据包也会被EAP层多路分离，并且被传送到认证方层。
因此，除非主机实现EAP认证方层的功能，否则这些数据包将会被丢弃。
传递性认证方层的行为在这个说明中没有被定义，并且像RADIUS和Diameter这些AAA协议不支持传递行为。
转发模型在图2中被说明：
图表2:
传递性认证方
在本章节中，认证方作为一个传递，它必须确定认证结果，基于后台认证服务器发送的接收/拒绝指示；结果必须不能被和接收/拒绝指示一起发送的EAP数据包的内容确定。
2.4P2P对等操作
由于EAP是P2P对等协议，一个独立和同步的认证可能发生在相反的方向上（取决于底层的能力）。
链路的两个终端可能同时作为认证方和被认证方。
这种情况下，两个终端都必须实施EAP认证方和被认证方层。
另外，在两个被认证方实现的EAP方法，必须同时支持认证方和被认证方的功能。
虽然EAP支持P2P的对等操作行动，但是一些EAP的实现，方法，AAA协议和链路层可能不支持这个。
一些EAP方法可能支持不对称的认证，其中被认证方需要一个类型的证书，认证方需要另一个类型的证书。
使用上述EAP方法并支持P2P对等操作的主机，因此将需要预备两种证书类型。
AAA协议像RADIUS/EAP和DiameterEAP仅仅支持传递认证操作。
像在中说明的那样，一个RADIUS服务器对访问请求回应一个封装了EAP请求，成功或失败的访问拒绝包。
因此这里不支持传递式对等操作。
即使是一种方法被用于支持相互认证和结果显示，一些注意事项可能会指示，需要两个EAP认证（每个方向上一个）。
主要有：
[1]在底层支持双向会话密钥派生。
底层像可能只支持单向派生和传输临时会话密钥。
例如，组密钥握手定义在是单向的，因为在结构模型中，只有访问点发送多播/广播信息。
在hoc模型中，被认证方可能发送多播/广播流量，请求两个单向组密钥交换。
由于设计的限制，这同样意味了单播密钥派生的需要和EAP方法交换，发生在每个方向。
[2]在底层中支持打破僵局。
底层像不支持打破僵局，当两个主机相互初始认证时，将仅仅转送一个特别的认证。
这意味着，虽然支持双向组密钥握手，然后两个认证，每个方向一个，仍可能会发生。
[3]被认证方政策补偿。
EAP方法可能支持结果显示，使被认证方能够用这种方法向EAP服务器显示，它成功的认证EAP服务器，同时使服务器将表明它也认证了被认证方。
然而，传递认证方将不会得知被认证方已经接收了EAP服务器提供的证书，除非这个信息通过AAA协议提供给了认证方。
认证方应该解释接收数据包中的密钥属性，作为被认证方成功认证服务器的信息显示。
然而，即使相互认证发生了，在初始EAP交换过程中，EAP被认证方的访问策略不被满足。
例如，EAP认证方可能不会证明授权同时担任认证方和被认证方的职能。
因此，被认证方可能需要在相反方向上加额外的认证，即使被认证方提供指示，EAP服务器已经成功的认证了被认证方。
3底层行为
3.1底层需求
EAP对底层有如下的假设：
[1]不可靠的传输。
在EAP中，认证方转发还没有接收到回应的请求，因此EAP不能假定底层是可靠的。
由于EAP定义了它自己的转发行为，当EAP运行在可靠的底层时，转发是有可能同时发生在底层和EAP层。
注意，EAP成功和失败数据包不被转发。
没有可靠的底层和不可忽略的错误比例，这些数据包可能丢失，从而导致时延。
因此降低EAP成功或失败数据包的丢包率是合适的，就像节中说的那样。
[2]底层错误检测。
当EAP不能假定底层是可靠的，它将依赖于底层错误检测。
EAP方法可能不包括一个MIC，或者如果EAP方法包括MIC，也可能不计算EAP数据包的所有字段，像代码，身份，长度或类型字段。
因此，没有底层错误检测，不可预料的错误将会进入EAP层或者EAP方法层的包头字段，导致认证失败。
例如，EAPTLS，它仅仅通过类型数据字段计算出它的MIC，把MIC确认失败当作致命性的错误。
没有底层错误检测和其它类似的方法，底层将不会可靠。
[3]底层安全。
EAP不会请求底层去提供安全服务，像是每个数据包加密，认证，完整型和重播保护。
然而，当这些安全服务可获得时，支持密钥派生的EAP方法，能够被用于提供动态密钥材料。
这将把EAP认证绑定到随后的数据上，同时保护数据不被修改、欺骗或重放。
详细请见节。
[4]最小MTU（最大传输单元）。
EAP能够在底层运行，同时提供一个1020字节甚至更大的EAPMTU（最大传输单元）。
EAP不支持路径MTU发现，同时也不支持分片和重组，但是不包括在本说明书中定义的方法：
身份1，消息2，NaK回应3，MD5挑战4，一次性密钥5，通用令牌卡6，扩展的NaK响应类型254类型。
通常，EAP被认证方从底层获取关于EAPMTU的信息，并设定EAP帧大小为合适的值。
当认证方运行在传递模式时，认证服务器没有直接的方法来确认EAPMTU，因此依赖于认证方提供这项信息，例如通过MTU帧属性，在节描述的那样。
虽然例如EAP-TLS方法支持分片和重组时，但EAP方法本来是设计在PPP中使用，此时一个1500字节的MTU是为保证控制帧可能没有分片和重组特征。
EAP方法能够假定一个最小的1020字节的EAPMTU没有其它的信息。
EAP方法应该包括支持分片和重组，如果它们的有效载荷比这个最小的EAPMTU大。
EAP是一个锁步协议，当处理分片和重组时，它意味必然的低效率。
因此，如果底层支持分片和重组（例如在EAP通过IP传输的地方），那么分片和重组发生在底层比在EAP中会更好。
这能够通过提供一个人为的大EAPMTU给EAP，导致分片和重组在底层中实现。
[5]可能的重复。
当底层可靠时，它将提供EAP层一个不重复的数据包流。
然而，当底层提供无重复是令人满意的时，它就不是个请求。
身份字段向认证方和被认证方都提供检查重复的能力。
[6]排序保证。
EAP不要求身份单调的增加，因此为正确运行而依赖于底层正确的排序。
EAP本来是定义运行在PPP上，同时第一节中有排序请求：
“P2P对等协议是被设计用来在两个被认证方之间的简单链路上传送数据包设计。
这些链路提供了全双工的同步的双向操作，同时被假定是按顺序传送数据包。
”
EAP的底层传输协议必须维持源地址和目的地之间的给定优先级水平的排序。
重新排序，如果这个发生的话，通常会导致EAP认证失败，导致EAP认证重新开始。
在重新排序这种环境下，EAP认证失败将会十分平常。
建议运行EAP的底层能够提供排序保证；在原始的IP或UDP传送中运行EAP是不被推荐的。
在RADIUS中封装EAP满足了排序的需要，由于RADIUS是锁步协议，因此需要按顺序发送数据包。
3.2在PPP中EAP的用法
为了通过PPP的链路建立通信，在链路建立阶段，PPP链路每个的终端首先发送LCP数据包来配置数据链路。
链路建立完毕后，进入到网络层协议阶段前，PPP提供一个可选的认证。
默认情况下，认证不是强制的。
如果要求链路的认证，在链路建立阶段期间，必须要明确指定认证协议配置选项。
如果被认证方的身份在认证阶段中显示了，服务器能够为接下来的网络层协商使用选项中的身份。
当在PPP中实施时，EAP不能在PPP链路控制阶段选择一个具体的认证方法，而是把这个推迟到认证阶段。
这允许了认证方在确定专门的认证策略前获得更多的信息。
当PPP认证方仅仅通过认证交换时，这也同样允许使用实际上能够实现各种认证方法的后台服务器。
PPP链路建立和认证阶段，和认证协议配置选项，被定义在PPP协议中。
3.2.1PPP配置选项格式
与EAP协商的PPP认证协议配置选项格式如下所示。
字段从左端传送到右端。
准确的说，一个EAP数据包被封装到一个PPP数据链路层帧的信息字段，此时协议字段显示了类型hexC227。
3.3
在IEEE802中使用EAP
通过IEEE802封装EAP被定义在。
在IEEE802封装的EAP不包含PPP，同时不支持对链路或网络层的协商。
因此，在中，不可能商议非EAP的认证方法，例如PAP或CHAP。
3.4底层标志
底层标志的可靠性和安全性依赖于更低的层。
由于EAP是媒体独立的，底层安全性的存在与否不会被考虑到EAP信息处理中。
为了提高可靠性，如果被认证方收到底层的成功标志消息，其被定义在节，它可能包括一个成功数据包已经丢失，和表现为好像它已经收到一个成功数据包。
这也包含了在某些情况下选择忽略成功数据包，像是在节描述的那样。
关于在PPP底层可靠性和安全性问题的讨论，IEEE802有线网络和无线局域网能够在安全性思考中找到，节。
在EAP认证结束后，被认证方通常将会通过认证方转发和接收数据。
需要提供保证，实体转发的数据是同一个成功结束EAP认证的数据。
为了达到这个目的，底层必须提供每个包的完整性，认证和重放保护，并在EAP认证阶段，把这些数据包的服务同派生的密钥相互绑定。
除此之外，随后的数据流也有可能被修改，欺骗和重演。
底层加密套接字的密钥材料本身由EAP提供的，加密套接字协商和密钥激活是由底层控制的。
在PPP中，加密套接字在ECP中被协商，因此不可能使用从EAP认证中派生的密钥，直到ECP结束。
因此，一个初始的EAP交换不能被PPP加密套接字保护，尽管EAP再次认证可能被保护。
在IEEE802媒体中，初始的密钥激活通常发生在EAP认证之后。
因此一个初始的EAP交换通常不被底层的加密套接字保护，尽管EAP的重新认证或预认证交换可能被保护。
4EAP数据包格式
EAP数据包格式由下图所示。
这些字段从左到右传送。
代码
代码字段是一个字节，确定了EAP数据包的类型。
EAP代码的代表含义：
1请求
2回应
3成功
4失败
由于EAP仅仅定义了代码1-4，EAP数据包其它的代码被认证方和被认证方简单丢弃。
身份
身份字段是一个字节，用于匹配请求的回应。
长度
长度字段是两个字节，显示了长度，EAP数据包包含代码，身份，长度和数据字段的字节数。
超出长度字段的字节应该被当作数据链路层的填补，一旦接收必须被忽略。
当消息长度字段设置的值大于接收字节数时，必须被简单丢弃。
数据
数据字段是0字节或者更多的字节。
数据字段的格式被代码字段确定。
4.1请求和回应
描述
请求数据包被认证方发送到被认证方。
每个请求都有一个类型字段，其中显示了什么在被请求。
额外的请求数据包必须等到有效的回应数据包被接收到，或一个可选的重试计数器到期，或者底层失败显示被接收到后，才能被发送。
转发的请求在发送时必须带有相同的身份，目的是为了与新请求包相互区分。
数据字段的内容依赖于请求类型。
被认证方必须发送一个回应包，用来回应有效的请求数据包。
回应包只有在回应有效的请求是才能被发送，绝对不能定时转发。
如果一个被认证方接收到有效的重复请求包时，此时它已经发送了一个回应包，它必须重新发送自己的初始回应，同时不能再次处理请求包。
请求必须按照它们接受的顺序进行处理，同时只有在处理结束之后才能检查下一个请求。
请求包和回应包的格式如下所示，这些字段从左到右发送。
代码
1请求
2回应
身份
身份字段是一个字节。
当等待回应时，如果请求数据包由于超时被转发，身份字段必须相同。
任何新的请求必须修改身份字段。
回应的身份字段必须和当前未解决的请求相符合。
认证方接收到一个回应包，如果它的身份不能符合当前未解决的请求包，必须简单丢弃。
为了防止在新请求和转发请求之间混淆，每个新请求的身份值应该和之前请求身份值不同，但是不需要在整个会话过程中是独一无二的。
一个可以达到此目的的方法就是开始时为身份赋予初值，随后每个新的请求包的身份值依次递增。
最好是开始的身份值是随机的，而不是从零开始，因为它会导致序列攻击什么的，变得很麻烦。
由于身份空间对每个字段来说是独一无二的，认证方没有限制同时只能有256个认证会话。
同样的，当再认证时，一个EAP会话可能持续
升级会员 