CN101379801B

CN101379801B - 用于eap扩展（eap-ext）的eap方法

Info

Publication number: CN101379801B
Application number: CN200780004901.6A
Authority: CN
Inventors: 大场义洋
Original assignee: Toshiba Corp; Telcordia Technologies Inc
Current assignee: Toshiba Corp; Iconectiv LLC
Priority date: 2006-12-08
Filing date: 2007-12-05
Publication date: 2015-12-09
Anticipated expiration: 2027-12-05
Also published as: JP2012199929A; JP5430709B2; CA2671833C; WO2008072646A2; CN101379801A; US20080141031A1; EP2557829B1; EP2557829A2; KR101007955B1; US8583923B2; EP2156641B1; JP2010502040A; KR20080087883A; CA2671833A1; WO2008072646A3; EP2557829A3; EP2156641A2; JP5068810B2

Abstract

该文档描述一种用于扩展EAP功能的EAP方法。所述扩展功能包括信道绑定和再认证。所述EAP方法还允许对其内部的多个EAP方法进行排序。

Description

用于EAP扩展（EAP-EXT）的EAP方法

技术领域

本申请涉及无线连网，并且在一些优选实施例中，涉及用于对对端与服务器之间的一致性而验证的信道绑定参数的***和方法。

背景技术

网络和互联网协议：

存在很多类型的计算机网络，以互联网具有最为有名。互联网是计算机网络的世界性的网络。如今，互联网成为了对于几百万个用户可用的公共和自立的网络。互联网使用被称为TCP/IP(即传输控制协议/互联网协议)的通信协议的集合来连接主机。互联网具有被称为互联网骨干的通信架构。对互联网骨干的接入极大地受控于互联网服务提供商(ISP)，他们把接入转售给公司和个人。

关于IP(互联网协议)，这是一种可以在网络上将数据从一个设备(例如电话，PDA[个人数字助理]、计算机等等)发送给另一设备的协议。如今存在各种版本的IP，包括IPv4、IPv6等等。网络上的每一主机设备具有至少一个IP地址，这是其自身唯一标识符。

IP是一种无连接协议。在通信期间在端点之间的连接不是连续的。当用户发送或者接收数据或消息时，数据或消息被划分为被称为分组的成分。每个分组被看作数据的独立单元。

为了对在互联网之类的网络上的点之间的传输进行标准化，建立了OSI(开放***互连)模型。OSI模型将在网络中两个点之间的通信处理划分为七个堆栈层，每一层添加其自身的功能的集合。每一设备处理消息，从而在发送端点处存在通过每一层的下游流，而在接收端点处存在通过多层的上游流。提供七层功能的程序和/或硬件典型地是设备操作***、应用软件、TCP/IP和/或其它传送协议和/或网络协议以及其它软件和硬件的结合。

典型地，当从用户传递消息或者将消息传递给用户时，使用上面四层，而当将消息传递通过设备(例如IP主机设备)时使用下面三层。IP主机是能够发送并且接收IP分组的网络上的任意设备，例如服务器、路由器或工作站。目的地是一些其它主机的消息并不向上传递到上层，而是被转发给其它主机。在OSI和其它相似模型中，IP处于层3，网络层。

无线网络：

无线网络可以包括各种类型的移动设备，例如蜂窝电话和无线电话、PC(个人计算机)、膝上型计算机、可佩戴的计算机、无绳电话、寻呼机、手机、打印机、PDA等等。例如，移动设备可以包括数字***，用于确保语音和/或数据的快速无线传输。典型的移动设备包括以下组件中的一些或全部：收发器(即发射机和接收机)，包括例如具有集成发射机、接收机以及根据期望的其它功能的单芯片收发器；天线；处理器；一个或多个音频变换器(例如用于音频通信的设备中的扬声器或麦克风)；电磁数据存储单元(比如例如ROM、RAM、数字数据存储单元等等，例如在提供数据处理的设备中)；存储器；闪速存储器；完全芯片或集成电路；接口(比如例如USB、CODEC、UART、PCM等等)；和/或诸如此类。

对于无线通信，可以采用无线LAN(WLAN)，在无线LAN中，移动用户可以通过无线连接而连接到局域网(LAN)。无线通信可以包括例如经由电磁波(例如光、红外线、无线电、微波)传播的通信。当前存在各种类型的WLAN标准，比如例如蓝牙、IEEE802.11以及家庭RF。

通过示例，可以使用蓝牙产品来提供移动计算机、移动电话、便携式手持设备、个人数字助理(PDA)以及其它移动设备之间的链路，以及对互联网的连接性。蓝牙是一种计算和电信产业规范，其详述了移动设备可以如何使用短距离无线连接而容易地彼此连接，并且与非移动设备连接。蓝牙创建了数字无线协议，以解决从需要保持数据从一个设备到另一设备被同步并且一致的各个移动设备的衍生所出现的端用户问题，由此允许来自不同商贩的设备一起无缝地运作。可以根据公共命名概念来命名蓝牙设备。例如，蓝牙设备可以拥有蓝牙设备名称(BDN)或与唯一蓝牙设备地址(BDA)关联的名称。蓝牙设备还可以加入互联网协议(IP)网络。如果蓝牙设备运行在IP网络上，则可以将IP地址和IP(网络)名称提供给它。因此，被配置为加入IP网络的蓝牙设备可以包含例如BDN、BDA、IP地址和IP名称。术语“IP名称”指的是与接口的IP地址对应的名称。

IEEE标准、IEEE802.11指定了用于无线LAN和设备的技术。使用802.11，可以采用支持几个设备的每一个基站来完成无线连网。在一些示例中，设备可以预先装配有无线硬件，或者用户可以安装分离的硬件(例如卡)，其可以包括天线。通过示例，无论设备是接入点(AP)、移动站(STA)、网桥、PCMCIA卡还是另一设备，在802.11中所使用的设备典型地包括三个值得注意的元件：无线电收发器；天线；以及MAC(媒体接入控制)层，其在网络中控制在点之间的分组流。

此外，可以在一些无线网络中利用多接口设备(MID)。MID可以包含两个独立的网络接口，例如蓝牙接口和802.11接口，因此允许MID加入两个分离的网络，并且与蓝牙设备进行接口。MID可以具有IP地址和与所述IP地址关联的公共IP(网络)名称。

无线网络设备可以包括蓝牙设备、多接口设备(MID)、802.11x设备(IEEE802.11设备，包括例如802.11a设备、802.11b设备和802.11g设备)、家庭RF(家庭射频)设备、Wi-Fi(无线保真)设备、GPRS(通用分组无线电设备)设备、3G蜂窝设备、2.5G蜂窝设备、GSM(全球移动通信***)设备、EDGE(GSM演进的增强数据)设备、TDMA类型(时分多址)设备、或(包括CDMA2000的)CDMA类型(码分多址)设备，但不限于此。每一网络设备可以包含各种类型的地址，包括IP地址、蓝牙设备地址、蓝牙公共名称、蓝牙IP地址、蓝牙IP公共名称、802.11IP地址、802.11IP公共名称、或IEEEMAC地址，但不限于此。

无线网络还可以包括例如在移动IP(互联网协议)***、PCS***以及其它移动网络***中所发现的方法和协议。关于移动IP，其包括由互联网工程任务组(IETF)所创建的标准通信协议。采用移动IP，移动设备用户可以移动穿过网络，同时保持曾经分配给他们的IP地址。参见请求评注(RFC)3344。NB：RFC是互联网工程任务组(IETF)的正式文献。移动IP地址增强了互联网协议(IP)，并且添加了用于当连接移动设备的归属网络的外部时将互联网业务转发给移动设备的方法。移动IP为每一移动节点分配其归属网络上的归属地址以及标识网络及其子网内的设备的当前位置的转交地址(CoA)。当设备移动到不同的网络时，其接收新的转交地址。归属网络上的移动代理可以将每一归属地址与其转交地址关联。移动节点可以使用例如互联网控制消息协议(ICMP)在每次其改变其转交地址时将绑定更新发送给归属代理。

在基本IP路由(即外部移动IP)中，典型地，路由机制依赖于这样的假设：每一网络节点总是具有对例如互联网的恒定接附点，并且每一节点的IP地址标识其所接附的网络链路。在该文献中，术语“节点”包括连接点，其可以包括例如用于传输的重新分布点或端点，并且可以识别、处理通信并且/或者将其转发给其它节点。例如，互联网路由器可以查看例如标识设备的网络的IP地址前缀等等。于是，在网络级，路由器可以查看例如标识特定子网的比特的集合。于是，在子网级，路由器可以查看例如标识特定设备的比特的集合。通过典型的移动IP通信，如果用户从例如互联网与移动设备断开连接，并且尝试在新的子网处进行重新连接，则设备必须被重新配置有新的IP地址、合适的网络掩码和默认路由器。否则，路由协议将不能够正确地交付分组。

独立于介质的预先认证：

独立于介质的预先认证(MPA)是一种以移动设备协助的安全切换优化方案，其运作在任意链路层上，并且采用任意移动性管理协议来运作。通过MPA，移动节点不仅能够安全地获得用于候选目标网络(CTN)的IP地址和其它配置参数，而且还能够使用在其实际接附到CTN之前所获得的IP地址来发送并且接收IP分组。这使得移动节点有可能完成任意移动性管理协议的绑定更新，并且在链路层处在执行切换之前使用新的转交地址(CoA)。

MPA运作在任意链路层上，并且采用任意移动性管理协议来运作，所述移动性管理协议包括移动IPv4、移动IPv6、MOBIKE、HIP、SIP移动性等等。在MPA中，IEEE802.11i预先认证的概念被扩展为在较高层运作，包括用于执行以下操作的附加机制：从移动对端可以移动至其的网络早期获取IP地址，以及在移动对端仍然接附到当前网络的同时主动切换到该网络。

支持MPA的移动节点(MN)以认证代理(AA)来启动预先认证处理。成功的认证使得PANA认证代理(PAA)能够建立与AA的安全性关联。这样添加到用于安全地执行配置协议以将IP地址和其它配置参数安全地交付给移动节点的配置代理(CA)，以及安全地执行隧道管理协议以建立对移动节点的主动切换隧道的接入路由器(AR)。当MN连接到当前接附点时进行这样的整个处理。在2006年3月的“draft-ohba-mobopts-mpa-framework-02.txt”和2006年10月22日的“draft-ohba-mobopts-mpa-framework-03.txt”中详细解释了这种情况，在此将其公开内容引入作为参考。

提供安全网络接入服务需要基于客户机和接入网的认证和授权的接入控制。客户机对网络认证提供了管辖通过强制点的业务流所需的参数。需要一种协议来承载客户机和接入网之间的认证方法。

PANA提供用于网络接入认证方法的链路层不可知传送。可扩展认证协议(EAP)[以下进一步讨论]提供了这种认证方法。关于这点，PANA承载EAP，EAP可以承载各种认证方法。通过使得能够在IP之上传送EAP的优点，使得可以被承载为EAP方法的任意认证方法对于PANA可用，并且因此使得其对于任意链路层技术可用。

PANA协议[I-D.ietf-pana-pana]承载接入网中PaC(PANA客户机)和PAA(PANA认证代理)之间的EAP消息。如果PaC是移动设备，并且能够在运行其应用的同时从一个接入网移动到另一接入网，则PaC对于无缝地执行切换而在切换时段期间不恶化应用的性能来说是关键的。当切换要求PaC在新的接入网中建立与PAA的PANA会话时，应该尽可能快速地完成用于建立PANA会话的信令。

PANA协议运行在客户机(PaC)与服务器(PAA)之间，以执行用于网络接入服务的认证和授权。协议消息传送包括一系列请求和响应，可以由两个端中的一个来发起所述一系列请求和响应中的一些。每一消息可以在有效载荷内承载零个或多个AVP。PANA的主要有效载荷是执行认证的EAP。PANA帮助PaC和PAA建立EAP会话。

对于进一步的背景信息，参见D.Forsberg，Y.Ohba等人2006年8月24日的用于承载网络接入的认证的协议(PANA)，IETF的PANA工作组的互联网草案，文献号draft-ietf-pana-pana-12，在此就像全文引用似的将其引入作为参考。

EAP：

参照对(以下所引用的)Aboba，RFC3748的引用，阐述了可扩展认证协议(EAP)的示例性方面。EAP是支持多个认证方法的认证框架。EAP典型地直接运行在诸如例如点对点(PPP)或IEEE802的数据链路层上而不需要IP。EAP提供其自身对于副本删除和重传的支持，但依赖于下层排序保证。在EAP自身内不支持分段；然而，各个EAP方法可以支持这种情况。

EAP可以使用在专用链路上，并且可以使用在交换电路上，而且可以使用在有线链路以及无线链路上。到此为止，已经通过经由交换电路或使用PPP的拨号线路连接的主机和路由器来实现了EAP[RFC1661]。也已经通过使用IEEE802[IEEE-802]的交换机和接入点实现了EAP。在[IEEE802.1X]中描述了IEEE802有线介质上的EAP封装，在[IEEE-802.11i]中描述了IEEE无线LAN上的封装。

EAP架构的优点之一在于其灵活性。EAP用于典型地在认证方请求了更多信息以确定将要使用的具体认证之后选择特定认证机制。并非需要认证方进行更新以支持每一新的认证方法，EAP允许使用可以实现一些或全部认证方法后端认证服务器，其中，认证方充当通路，以用于一些或全部方法和对端。

在所引用的后一文献中，无论认证方是否操作为通路，都应用认证方需求。其中，取决于在何处终止EAP认证，需求按理要么应用于认证方，要么应用于后端认证服务器，已经使用了术语“EAP服务器”。

EAP被设计为在网络接入认证中使用，其中，IP层连接性可能不可用。EAP是仅支持传输中的(inflight)单个分组的锁定步骤(lock-step)协议。结果，EAP不能高效地传送大块数据，这与例如TCP或SCTP的传送协议不同。

虽然EAP提供对重传的支持，但假设由下层所提供的排序保证，从而不支持无序接收。

由于EAP不支持分段和重组，因此生成比最小EAPMTU更大的有效载荷的EAP认证方法需要提供分段支持。

虽然诸如EAP-TLS的认证方法提供对于分段和重组的支持，但在所引用的后一文献中所定义的EAP方法不支持分段和重组。结果，如果EAP分组大小超过链路的EAPMTU，则这些方法将碰到困难。

EAP认证由服务器(认证方)发起，而很多认证协议由客户机(对端)发起。结果，对于认证算法，添加一个或两个附加消息(最多一个往返)以运行在EAP上可能是必须的。

在支持基于证书的认证的情况下，由于证书链的分段而导致附加往返的数量可能远远更大。通常，分段后的EAP分组将需要很多往返来发送分段。例如，大小14960字节的证书链将需要十个往返来以1496字节EAPMTU进行发送。在EAP运行在经历了明显分组丢失的下层的情况下，或者在认证方和认证服务器之间的连接经历了明显分组丢失的情况下，需要很多往返的EAP方法可能经历困难。在此情况下，建议使用具有较少往返的EAP方法。

EAP认证交换如下进行：

认证方发送请求以认证对端。该请求具有用于指示正在请求什么的类型字段。请求类型的示例包括：身份、MD5-质询等等。MD5-质询类型与CHAP认证协议接近地对应[参见RFC1994]。典型地，认证方将发送初始身份请求；然而，并不需要初始身份请求，并且可以绕过。例如，在由对端已经连接了的端口(租赁的线路、专用交换机或拨号端口)进行确定的情况下，或者，在以另一方式(经由呼叫站身份或MAC地址，在MD5-质询响应的名称字段中)获得身份的情况下，可以无需身份。

对端以对有效请求的应答来发送响应分组。关于请求分组，响应分组包含与请求的类型字段对应的类型字段。

认证方发送附加的请求分组，对端以响应来应答。只要需要，请求和响应的序列就继续。EAP是“锁定步骤”协议，从而除了初始请求之外，在接收到有效响应之前不能发送新的请求。认证方负责重传请求。在合适数量的重传之后，认证方应该结束EAP对话。当进行重传时，或者当无法从对端得到响应时，认证方无需发送成功分组或失败分组。

对话继续，直到认证方不能认证对端(对一个或多个请求的不可接受的响应)，在此情况下，认证方实现方式需要发送EAP失败(代码4)。可选地，认证会话可以继续，直到认证方确定已经出现成功认证，在此情况下，认证方需要发送EAP成功(代码3)。Id。

在其它优点之中，EAP协议可以支持多个认证机制，而无需预先协商特定的认证机制。此外，网络接入服务器(NAS)设备(例如交换机或接入点)无需知道每一认证方法，并且可以充当用于后端认证服务器的通路代理。对于通路的支持是可选的。认证方可以认证本地对端，而同时充当用于非本地对端和其没有在本地实现的认证方法的通路。此外，认证方与后端认证服务器的分离简化了凭证管理和策略判决处理。

在概念上，EAP实现方式包括以下组件：

[a]下层。下层负责在对端和认证方之间发送并且接收EAP帧。EAP已经运行在各种下层中，包括PPP、有线IEEE802LAN[参见IEEE802.1X]、IEEE802.11无线-LAN[IEEE-802.11]、UDP(L2TP[RFC2661]和IKEv2)以及TCP。

[b]EAP层。EAP层经由下层接收并且发送EAP分组，实现副本检测和重传，并且对出入EAP对端和认证方层的EAP消息进行交付和接收。

[c]EAP对端和认证方层。基于代码字段，EAP层将到来的EAP分组解复用到EAP对端和认证方层。典型地，给定主机上的EAP实现方式将要么支持对端功能，要么支持认证方功能，但主机有可能既充当EAP对端又充当认证方。在这种实现方式中，将既出现EAP对端层又出现认证方层。

[d]EAP方法层。EAP方法实现了认证算法，并且经由EAP对端和认证方层接收并且发送EAP消息。由于EAP自身不提供分段支持，因此分段是EAP方法的职责。Id。

稍后引用的参考阐述了以下定义，其在此被引用以用于参考。

认证方：

发起EAP认证的链路的一端。术语认证方使用在[IEEE-802.1X]中，并且具有与该文献中相似的含义。

对端：

对认证方进行响应的链路的一端。在[IEEE-802.1X]中，这个端被称为恳求方。

后端认证服务器：

后端认证服务器是将认证服务提供给认证方的实体。当使用时，这个服务器典型地执行用于认证方的EAP方法。该术语也使用在[IEEE-802.1X]中。

AAA：

认证、授权和计费(AAA)协议，其中，EAP支持包括RADIUS和Diameter。在该文献中，术语“AAA服务器”和“后端认证服务器”可互换地使用。

EAP服务器或服务器：

终止与对端的EAP认证方法的实体。在不使用后端认证服务器的情况下，EAP服务器是认证方的一部分。在认证方操作在通路模式中的情况下，EAP服务器位于后端认证服务器上。

成功认证：

在该文献的上下文中，“成功认证”是EAP消息的交换，其结果是认证方决定允许由对端接入，并且对端决定使用这种接入。认证方的决定典型地既包括认证方面又包括授权方面；对端可以对认证方进行成功地认证，但由于策略原因认证方可能拒绝接入。

主会话密钥(MSK)：

在EAP对端与服务器之间导出的并且由EAP方法所输出的密钥材料(keyingmaterial)。MSK长度至少是64字节。在现有实现方式中，充当EAP服务器的AAA服务器将MSK传送给认证方。

扩展的主会话密钥(EMSK)：

在EAP客户机与服务器之间导出的并且由EAP方法所输出的附加密钥材料。EMSK长度至少是64字节。EMSK不被认证方或任意其它第三方所共享。EMSK被保留为尚未定义的将来使用。

EAP扩展：

作为参考，我们参照V.Narayanan等人2007年8月24日的EAPExtensionsforEAPReauthenticationProtocol(ERP)，IETFInternetDraft，参见http://www.ietf.org/internet-drafts/draft-ietf-hokey-erx-04.txt。该参考文献如下解释了用于EAP再认证协议的EAP扩展。“可扩展认证协议(EAP)是用于传送对双方进行认证的方法的通用框架；认证要么是单向的，要么是相互的。基本目的是网络接入控制，并且建议密钥生成方法，以强制接入控制。EAP密钥生成体系定义了在高级别所导出的两个密钥——主会话密钥(MSK)和扩展的MSK(EMSK)。在最通常的部署情形中，对端和服务器通过被称为认证方的第三方来彼此认证。认证方或受控于所述认证方的实体强制接入控制。在成功认证之后，服务器将MSK传送给认证方；认证方和对端使用MSK导出瞬时会话密钥(TSK)作为认证密钥或密钥推导密钥，并且使用TSK以用于按分组接入强制。”Id。“当对端从一个认证方移动到另一认证方时，期望避免完全EAP认证。与另一轮EAP方法的完全EAP交换需要几个往返，并且需要大量时间来完成，这导致了移交时间的延迟。一些EAP方法指定使用来自初始认证的状态，以通过减少计算开销而对再认证进行优化，但对方法特定的再认证在很多情况下需要至少2次往返。注意，不提供对再认证的支持的很多方法也是重要的。因此，有利的是，在EAP中而不是在各个方法中具有高效再认证支持。Id。

“穿过认证方的密钥共享有时被用作对于降低移交时间的实际解决方案。在此情况下，认证方的折衷导致了经由其它认证方所建立的EAP会话的折衷。”Id。“结论是，需要设计一种高效EAP再认证机制，其允许刷新将要在对端和认证方之间建立的密钥，而无需再次执行EAP方法”。Id。“该文献指定EAP再认证扩展(ERX)，以用于使用EAP进行高效再认证。基于ERX的ERP再认证协议(ERP)支持独立于EAP方法的再认证，以用于具有来自先前所执行的EAP认证的有效的未过期的密钥材料的对端。在该文献中描述了EAP再认证所需的协议和密钥体系。”Id。

参考：

以下背景参考文献全部引入作为参考。

1.Bradner，S.，“KeywordsforuseinRFCstoIndicateRequirementLevels”，BCP14，RFC2119，1997年3月(在此称为[RFC2119])。

2.Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“ExtensibleAuthenticationProtocol(EAP)，”RFC3748，2004年6月(在此称为[RFC3748])。

3.Aboda，B.，“ExtensibleAuthenticationProtocol(EAP)KeyManagementFramework”，draft-ietf-eap-keying-16(进展中的工作)，2007年1月(在此称为[I-D.iEXTf-EAPp-keying])；以及2006年10月的[I-D.iEXTf-EAPp-keying]ww(进展中的工作)。

4.Narayanan，V.和L.Dondeti，“ProblemStatementonEAPEfficientRe-authenticationandKeyManagement”，draft-vidya-eap-reauth-ps-00(进展中的工作)，2006年10月(在此称为[I-D.vidya-eap-reauth-ps])。

5.Ohba，Y.，“ChannelBindingMechanismbasedonParameterBindinginKeyDerivation”，draft-ohba-eap-channel-binding-02(进展中的工作)，2006年12月(在此称为[I-D.ohba-eap-channel-binding])。

6.Salowey，J.，“SpecificationfortheDerivationofUsageSpecificRootKeys(USRK)fromanExtendedMasterSessionKey(EMSK)”，draft-salowey-eap-emsk-deriv-01(进展中的工作)，2006年6月(在此称为[I-D.salowey-eap-emsk-deriv])。

7.NationalInstituteofStandardsandTechnology，“SecureHashStandard”，2002年8月(在此称为[sha256])。

8.Arkko，J.和P.Eronen，“AuthenticatedServiceInformationfortheExtensibleAuthenticationProtocol(EAP)”，http://tools.ietf.org/html/draft-arkko-eap-service-identity-auth-04，2005年10月，(在此称为[arkko-eap-service-identity-auth])。

9.Kaufman，C，“InternetKeyExchange(IKEv2)Protocol”，RFC4306，2005年12月，(在此称为[RFC4306])。

10.Narayanan，V.和L.Dondeti，“EAPRe-authenticationExtensions”，draft-ietf-hokey-erx-02(进展中的工作)，2007年6月(在此称为[I-D.ietf-hokey-erx])。

11.Salowey，J.，“SpecificationfortheDerivationofRootKeysfromanExtendedMasterSessionKey(EMSK)”，draft-ietf-hokey-emsk-hierarchy-01(进展中的工作)，2007年6月(在此称为[I-D.ietf-hokey-emsk-hierarchy])。

虽然已知各种***和方法，但仍然需要改进的***和方法。

发明内容

本发明克服了背景技术中的各种限制和缺点。该申请在此包括多个发明，包括以下所描述的发明的集合。

第一组发明：

根据一些实施例，一种用于在客户机和服务器之间的方法的认证的处理，包括：a)采用在客户机和服务器之间没有认证机制的方法；以及b)使得所述方法依赖于内部认证方法，以认证所述客户机。优选的是，所述方法是第一EAP方法，其不具有在内部承载第二EAP方法的认证机制，所述第二EAP方法用于认证所述客户机。

第二组发明：

一种对关于EAP扩展功能的性能进行协商的EAP对端和EAP服务器的处理方法，包括：采用EAP扩展方法(EAP-EXT)，其关于扩展功能在所述服务器和所述客户机之间提供性能交换，其中，所述扩展功能不具有认证机制，并且其中，至少一个内部EAP方法运行在所述EAP扩展方法内部，以用于认证所述EAP对端。在一些实施例中，所述方法进一步包括：使得所述内部EAP方法生成密钥材料，并且以AUTHTLV保护所述外部EAP扩展中的消息。在一些实施例中，所述方法进一步包括：其中，使用从最近成功的内部方法的EAP密钥材料生成的EAP扩展密钥(EAP-EXT-KEY)来计算外部EAP扩展消息中的AUTHTLV。在一些实施例中，所述方法进一步包括：使用EAP扩展密钥来计算AUTHTLV，以用于完整性保护EAP-EXT消息。在一些实施例中，所述方法进一步包括：利用用途特定根密钥推导算法(usagespecificrootkeyderivationalgorithm)而从通过内部EAP方法所生成的EMSK导出所述EAP扩展密钥。在一些实施例中，所述方法进一步包括：所述EAP扩展方法定义EAP-re-authentication(EAP-再认证)密钥，其被用作对于再认证机制所使用的EAP方法所需的预先共享密钥。在一些实施例中，所述方法进一步包括：利用用途特定根密钥推导算法而从EAP扩展方法输出的EMSK导出所述EAP再认证密钥。在一些实施例中，所述方法进一步包括：所述EAP扩展方法采用包括公共EAP字段的消息格式，其具有被配置为被设置为指示其为最近消息的比特、被配置为被设置为指示差错的另一比特、多个比特的版本字段、用于将来扩展的多个比特的保留字段、以及每一个与特定性能对应的多个比特的性能字段。在一些实施例中，所述方法进一步包括：通过性能比特的设置来提供关于所述扩展功能在所述服务器和所述客户机之间的所述性能交换。在一些实施例中，所述方法进一步包括：所述性能比特指示所述发送方支持信道绑定机制。在一些实施例中，所述方法进一步包括：所述性能比特指示所述发送方支持再认证。在一些实施例中，所述方法进一步包括：当所述性能比特指示发送方支持再认证被设置在最终请求/EXT消息中时，并且所述消息包括Server-IDTLV(服务器-IDTLV)和Peer-IDTLV(对端-IDTLV)。在一些实施例中，所述方法进一步包括：当所述性能比特指示发送方支持再认证被设置在最终请求/EXT和响应/EXT消息交换中时，EAP对端和EAP服务器生成EAP再认证密钥，并且其中，包含在服务器-ID和对端-IDTLV中的服务器-ID和对端-ID以及所述EAP再认证密钥用于再认证EAP方法。在一些实施例中，所述方法进一步包括：采用依次运行在EAP扩展方法内部的多个内部EAP方法，以及每次序列中的内部EAP方法生成密钥材料，就生成新的EAP扩展密钥。在一些实施例中，所述方法进一步包括：a)所述EAP服务器发送设置了至少一个性能比特的EAP-请求/EXT消息；b)所述EAP对端接收所述EAP-请求/EXT消息，并且发送设置了至少一个性能比特的EAP-响应/EXT消息。在一些实施例中，所述方法进一步包括：c)所述EAP服务器接收所述EAP-响应/EXT消息，并且发送EAP-请求/EXT消息，所述EAP-请求/EXT消息设置了F比特、对端-IDTLV、服务器-IDTLV和AUTHTLV；d)所述EAP对端接收以上在c)中的所述EAP-响应/EXT消息，并且发送EAP-请求/EXT消息，所述EAP-请求/EXT消息设置了F比特、至少一个性能比特和AUTHTLV；e)所述EAP服务器接收d)中的所述EAP-响应/EXT消息，并且发送EAP-Success(EAP-成功)消息。在一些实施例中，所述方法进一步包括：要么使得所述EAP对端要么使得EAP服务器发送EAP扩展消息，所述EAP扩展消息设置了在所述对端或所述服务器检测到差错的情况下用于差错指示的比特合，并且具有AUTHTLV。在一些实施例中，所述方法进一步包括：在创建密钥材料之后执行受保护的消息交换，以避免性能信息受攻击者攻击。在一些实施例中，所述方法进一步包括：对EAP扩展方法的内部的多个EAP方法进行排序。在一些实施例中，所述方法进一步包括：通过保护每一内部EAP方法连同外部EAP扩展方法而采用在所述序列中由其前述成功内部方法所生成的密钥来创建加密绑定，并且最终输出由最近成功的内部EAP方法所生成的EAP密钥材料。

第三组发明：

根据一些其它实施例，提供一种无线移动站，其包括：处理器、存储器、数字数据存储单元、以及用于无线发送并且接收数据消息的至少一个无线接口；所述无线移动设备被编程以运行为EAP对端，并且其中，所述无线移动设备被编程为：i)从EAP服务器接收设置了至少一个性能比特的EAP-请求/EXT消息；以及ii)发送设置了至少一个性能比特的EAP-响应/EXT消息。

第四组发明：

根据一些其它实施例，一种用于无线网络的EAP服务器，其终止与EAP对端的EAP认证方法，所述EAP服务器被配置为：a)将设置了至少一个性能比特的EAP-请求/EXT消息发送给EAP对端；以及b)从EAP对端接收设置了至少一个性能比特的EAP-响应/EXT消息。

结合附图，参看以下描述，各个实施例的上述和/或其它发明、方面、特征和/或优点将更加清楚。各个实施例可以包括并且/或者不包括可应用的不同方面、特征和/或优点。此外，各个实施例可以结合可应用的其它实施例的一个或多个方面或特征。特定实施例的方面、特征和/或优点的描述不应理解为限制其它实施例或权利要求。

附图说明

图1是描述根据一些实施例的采用单个内部方法在EAP服务器与EAP对端之间的示例性EAP-EXT消息序列的示图；

图2是描述根据一些实施例的采用多个内部方法在EAP服务器与EAP对端之间的示例性EAP-EXT消息序列的示图；

图3(A)是描述根据一些示例性实施例的示例性消息格式的示图；

图3(B)是描述根据一些示例性实施例的示例性性能字段的示图；

图3(C)是描述根据一些示例性实施例的示例性TLV格式的示图；

图4是描述根据一些附加实施例的采用单个内部方法在EAP服务器与EAP对端之间的示例性EAP-EXT消息序列的示图；

图5是描述根据一些附加实施例的采用多个内部方法在EAP服务器与EAP对端之间的示例性EAP-EXT消息序列的示图；

图6(A)是描述根据一些附加示例性实施例的示例性消息格式的示图；

图6(B)是描述根据一些附加示例性实施例的示例性性能字段的示图；

图6(C)是描述根据一些附加示例性实施例的示例性TLV格式的示图；

图7(A)是描述加密算法TLV的示图；以及

图7(B)是描述完整性算法TLV的示图。

具体实施方式

在附图中，通过示例而并非限制来示出本发明优选实施例。

虽然本发明可以用很多不同形式来实施，但描述多个示例性实施例，应理解，该公开应看作提供在此所描述的各个发明的原理的示例，并且这些示例并非意欲将本发明限制为在此所描述并且/或者在此所示出的优选实施例。

1.简介

EAP(可扩展认证协议)是一种认证协议，其支持被称为“EAP方法”的多个认证算法[RFC3748]。在EAP中，EAP对端和EAP服务器生成EAP密钥材料，即MSK(主会话密钥)和EMSK(扩展的主会话密钥)。在[I-D.ietf-eap-keying]中描述了用于MSK的生成，传送和使用的详细框架。

在EMSK(扩展的主会话密钥)使用中的一个是再认证的情况下，通过定义EMSK的一些使用，存在EAP的扩展功能[RFC3748]。EAP的另一扩展功能是在[I-D.ohba-eap-channel-binding]中所定义的信道绑定方案。对于关于信道绑定的进一步的背景参考，Y.Ohba于2006年4月20日提交的同时待审申请序列号11/379,568的题为CHANNELBINDINGMECHANISMBASEDPARAMETERBINDINGINKEYDERIVATION的完整公开被引入此处作为参考。由于支持EAP的扩展功能的实现方式需要与不支持扩展功能的实现方式交互操作，从而当前者实现方式与后者实现方式进行通信时，前者实现方式可以禁用扩展功能，因此需要一种用于EAP对端和EAP服务器的机制来关于EAP的扩展功能在性能方面进行协商。

存在用于扩展EAP功能的两种基本方法。一种方法是定义新的EAP代码来实现除了现有EAP功能(即请求、响应、成功以及失败)之外的功能。然而，该方法需要对RFC3748进行改变，并且还可能需要对下层协议进行改变。另一方法是定义新的EAP方法来实现扩展功能。该文献采用后一种方法来最小化对现有EAP部署的影响。

该文献描述EAP-EXT，一种用于扩展EAP功能的EAP方法。在一些优选实施例中，所述扩展EAP功能包括信道绑定和再认证。所述EAP方法还允许对其内部的多个EAP方法进行排序。

2.EAP-EXT概述

在优选实施例中，EAP-EXT提供性能交换。关于这点，消息内的比特可以用于指示性能。在一些实施例中，一个比特(R比特)用于指示再认证性能。在一些实施例中，一个比特(C比特)用于指示信道绑定性能。

当使用EAP-EXT时，如果在服务器发送第一EAP-请求之前服务器已知对端的身份，则可以省略EAP-身份交换。关于这点，存在用于将对端的算法提供给服务器的一些带外机制，例如在认证方和服务器之间传递对端的身份。

在EAP-EXT中，扩展的EAP性能(比如例如信道绑定和再认证)在对端和服务器之间被交换。同时，至少一个EAP方法(例如EAP-TLS)运行在EAP-EXT内部，以用于对对端进行认证。直到内部方法生成EAP密钥材料，AUTHTLV才被包括，并且性能才被保护。因此，如果仅存在一种内部EAP方法，则在发送EAP-成功消息或EAP-失败消息之前，执行与AUTHTLV的附加EAP-EXT交换，而没有方法TLV。

在内部EAP方法生成EAP密钥材料之后，需要以AUTHTLV来保护EAP-EXT消息。需要使用从最近成功的内部方法的EAP密钥材料所生成的EAP-EXT-KEY来计算EAP-EXT消息中的AUTHTLV。这说明，如果存在依次运行在EAP-EXT内部的多个内部EAP方法，则每次在序列中的内部EAP方法生成EAP密钥材料时，生成新的EAP-EXT-KEY。任意内部EAP方法需要能够生成EAP密钥材料。

在成功EAP-EXT运行的结束，由最近成功的内部EAP方法所生成的EAP密钥材料被输出到EAP层。F比特用于指示EAP-EXT交换的结束。

图1示出采用单个内部EAP方法的EAP-EXT消息序列的示例。图2示出采用多个内部EAP方法的EAP-EXT消息序列的示例。

3.差错处理

例如由于内部EAP方法认证的失败或畸变的未知的或丢失EAP-EXTTLV而导致可能出于一些原因而产生差错。可以由对端或者由服务器来检测差错。导致差错的EAP-EXT消息被称为错误消息。设置了E比特的EAP-EXT消息用于差错指示。这些消息被称为差错指示。差错指示需要包含AUTHTLV，并且不应包含其它TLV。

需要将没有有效AUTHTLV的(包括错误差错指示的)任意错误消息默默丢弃。

对于具有有效AUTHTLV的错误请求，对端发送差错指示响应。对于具有有效AUTHTLV的错误响应，服务器发送由对端以差错指示响应来进行响应的差错指示请求。服务器响应于具有有效AUTHTLV的差错指示响应而返回EAP-失败消息。

4.完整性保护密钥

EAP-EXT定义两种类型的密钥；1)EAP-EXT-KEY以及2)EAP-REAUTH-KEY。

4.1.EAP-EXT-KEY

使用EAP-EXT-KEY来计算AUTHTLV，以用于完整性保护EAP-EXT消息。当HMAC-SHA-256(参见例如通过上述引用而合并的参考[sha256])用于完整性算法时，EAP-EXT-KEY的长度是32字节。使用如下所定义的推导算法(参见例如通过上述引用而合并的参考[I-D.salowey-eap-emsk-deriv])使用USRK(用途特定根密钥)从由内部EAP方法所生成的EMSK导出EAP-EXT-KEY。

EAP-EXT-KEY＝KDF(EMSK，“EAP-EXT-Integrity-Key”，length)。

在KDF中，EAP-EXT-KEY使用在通过上述引用而合并的参考[I-D.salowey-eap-emsk-deriv]中所指定的默认PRF。

4.2.EAP-REAUTH-KEY

EAP-REAUTH-KEY被用作用于再认证机制的EAP方法所需的预先共享的密钥。EAP-REAUTH-KEY的长度取决于再认证机制。如下使用以上所合并的参考[I-D.salowey-eap-emsk-deriv]中所定义的USRK推导算法从EAP-EXT所输出的EMSK导出EAP-REAUTH-KEY。

EAP-REAUTH-KEY＝KDF(EMSK，“EAP-EXT-Reauthentication-Key”，length)。

5.消息格式

EAP-EXT使用EAP类型X(由IANA来分配)。图3(A)示出包括[RFC3748]中所定义的公共EAP字段(例如代码、标识符、长度和类型)的消息格式。

F：

这个比特需要被设置为指示这是来自发送方的最近EAP-EXT消息。否则，无需设置该比特。

当消息是差错指示时，设置该比特。当设置该比特时，还需要设置F比特。参见对差错指示进行详细描述的部分3。

版本：

8比特字段指示EAP-EXT方法的版本。该文献定义版本1。

保留：

这个6比特字段为将来扩展而保留。需要由发送方将该字段设置为零，并且接收方需要忽略该字段。

性能：

该字段性能字段包含扩展的EAP性能。图3(B)示出性能字段格式。

每一比特与特定性能对应。每一比特的语义如下：

C：

该比特被设置为指示发送方支持在用于MSK的[I-D.ohba-eap-channel-binding]中所定义的信道绑定机制。当该比特既被设置用于请求又被设置用于响应，并且EAP-EXT方法成功完成时，对端和服务器需要使得能够信道绑定机制。用于prf+的默认散列算法是AUTH_HMAC_SHAl_160。

R：

该比特被设置为指示发送方支持再认证EAP方法。当将该比特设置在最终请求/EXT消息(即在设置了F比特的情况下的请求/EXT)中时，该消息需要包括服务器-IDTLV和对端-IDTLV，并且可以包括再认证-密钥-生存时间AVP。当将该比特设置在最终请求/EXT和响应/EXT交换中时，对端和服务器需要生成EAP-REAUTH-KEY。包含在服务器-IDTLV和对端-IDTLV中的服务器-ID和对端-ID以及EAP-REAUTH-KEY用于再认证EAP方法。可以由本领域技术人员基于该公开选择默认再认证机制。

其它比特被保留以用于将来使用，并且需要由发送方将其设置为零，并且需要由接收方忽略它们。

TLV：

零，一个或多个TLV(类型-长度-值)图3(c)示出TLV格式。

类型：

该字段指示所述TLV的类型。

长度：

该字段指示所述TLV的以字节为单位的长度，包括TLV的类型和长度字段。

值：

该字段包含对于TLV类型特定的数据。

6.EAP-EXTTLV

定义以下TLV。

6.1.方法TLV

方法TLV(类型1)包含从类型字段开始的EAP方法有效载荷(EAPMethodpayload)。

6.2.AUTHTLV

AUTHTLV(类型2)包含用于保护EAP-EXT消息的完整性数据。EAP-EXT-KEY用于计算AUTHTLV。

在包括该字段的整个EAP消息上计算TLV值字段。在计算完整性数据之前，需要将该字段初始化为全零。该字段的长度取决于所使用的完整性算法。当完整性检查失败时，需要默默丢弃消息。默认完整性算法是HMAC-SHA-256(参见例如以上所结合的参考[sha256])。

6.3.对端-IDTLV

对端-IDTLV(类型3)包含用于再认证的对端的身份。

6.4.服务器-IDTLV

服务器-IDTLV(类型4)包含用于再认证的服务器的身份。

6.5.再认证-密钥-生存时间TLV

再认证-密钥-生存时间TLV(类型5)包含以秒为单位的EAP-REAUTH-KEY的生存时间。

7.安全性考虑

性能交换在内部EAP方法输出EAP密钥材料之前是不受保护的。因此，在创建EAP密钥材料之后强制附加的受保护的消息交换，以避免在对端和服务器没有检测的情况下由攻击者改动性能信息。

EAP-EXT允许对其内部的多个EAP方法进行排序。已知包括多个嵌套的认证方法或顺序的认证方法而没有对它们进行加密绑定的混合认证方法具有对中间人攻击的弱点。EAP-EXT能够通过保护每一内部EAP方法连同外部EAP方法(即EAP-EXT)而以在所述序列中由其前述成功内部方法所生成的密钥来创建所需的加密绑定，并且最终输出由最近成功的内部EAP方法所生成的EAP密钥材料。为了实现加密绑定，EAP-EXT需要内部EAP方法能够生成EAP密钥材料。

附加的EAP-EXT实施例

详细描述的其余部分描述了附加EAP-EXT实施例，其在一些上下文中在上述原始实施例上具有一些修改。应理解，这些附加实施例在很多方面类似于以上所描述的前述实施例。在这些附加实施例中，可以通过扩展EAP功能来支持扩展功能(比如例如HOKEY再认证(参见例如[I-D.ietf-hokey-erx]))和MSK信道绑定[I-D.ietf-eap-keying]。如上所述，可以存在用于扩展EAP功能的两种方法。一种方法是定义新的EAP代码来实现除了现有EAP功能(即请求、响应成功和失败)之外的功能。然而，该方法需要对[RFC3748]进行改变，并且还可能需要对认证方和下层协议进行改变。另一方法是定义新的EAP方法来实现扩展功能。对于这两种方法，可以期望这些扩展功能是后向兼容的。在此情况下，可能需要用于在EAP对端和EAP服务器之间关于扩展功能上的性能进行协商的机制。

在这些附加实施例中，描述了用于扩展EAP功能的EAP方法。扩展功能包括例如HOKEY、再认证和MSK信道绑定。在这些实施例中所提议的EAP方法(EAP-EXT)还再次允许在其自身内多个EAP方法的排序。此外，在而这些实施例中，在内部方法实现方式生成MSK但不生成EMSK的情况下，EAP-EXT可以生成MSK和EMSK。

EAP-EXT概述：

EAP-EXT提供性能交换。一个比特(R比特)用于指示HOKEY再认证性能。一个比特(C比特)用于指示信道绑定性能。

当使用EAP-EXT时，如果在服务器发送第一EAP-请求之前服务器已知对端的身份，则可以省略EAP-身份交换。可以使用用于提供对端的身份的带外机制，例如在认证方和服务器之间传递对端的身份。

在EAP-EXT中，扩展的EAP性能(例如HOKEY再认证和MSK信道绑定和再认证)在对端和服务器之间被交换。同时，至少一个EAP方法(例如EAP-TLS)运行在EAP-EXT内部，以用于认证对端。内部方法被承载在方法TLV(类型-长度-值)中。直到内部方法生成EAP密钥材料，AUTHTLV才被包括，并且性能才受保护。因此，如果仅存在一种内部EAP方法，则在发送EAP-成功消息或EAP-失败消息之前，需要执行与AUTHTLV的附加EAP-EXT交换。

在内部EAP方法生成EAP密钥材料之后，需要以AUTHTLV来保护EAP-EXT消息。需要使用从最近成功的内部方法的EAP密钥材料所生成的EAP-EXT-AUTH-KEY来计算EAP-EXT消息中的AUTHTLV。这说明，如果存在依次运行在EAP-EXT内部的多个内部EAP方法，则每次在序列中的内部EAP方法生成EAP密钥材料时，生成新的EAP-EXT-AUTH-KEY。任意内部EAP方法需要能够生成EAP密钥材料。

在成功EAP-EXT运行的结束，从由最近成功的内部EAP方法所生成的MSK导出EAP密钥材料，并将其输出到EAP层。可以使用PRFTLV在EAP-EXT内协商用于导出EAP密钥材料和USRK(用途特定根密钥)[I-D.ietf-hokey-emsk-hierarchy]的伪随机函数。F比特用于指示EAP-EXT交换的结束。

图4示出采用单个内部EAP方法并且具有PRF协商的EAP-EXT消息序列的示例。图5示出采用多个内部EAP方法并且没有PRF协商的EAP-EXT消息序列的示例。

差错处理：

在此合并以上所描述的在原始实施例中关于差错处理的讨论。

密钥：

在一些实施例中，EAP-EXT定义以下类型的密钥。

a.从EAP-EXT输出的MSK和EMSK：

按以下方式使用[I-D.ietf-hokey-emsk-hierarchy]中所定义的KDF从MSK_i——由最近成功的内部EAP方法所生成的MSK——导出将要从EAP-EXT所输出的64字节MSK和64字节EMSK的集合。

(MSK，EMSK)＝KDF(MSK_i，“EAP-EXT-EAP-Keying-material”，128)

b.EAP-EXT-AUTH-KEY：

使用EAP-EXT-AUTH-KEY来计算AUTHTLV，以用于完整性保护EAP-EXT消息。EAP-EXT-AUTH-KEY仅被使用在EAP-EXT内，并且从不被输出。按以下方式使用在[RFC4306]中所定义的prf+从由最近成功的内部EAP方法所生成的MSK导出EAP-EXT-AUTH-KEY。

EAP-EXT-AUTH-KEY＝prf+(MSK_i，EAP-EXT-Authentication-Key”，length)；

用于prf+的默认散列算法是PRF_HMAC_SHA2_256。

字段长度将取决于在EAP-EXT交换期间由EAP服务器所选择的完整性算法。当对于完整性算法使用HMAC-SHA-256[sha256]时，长度＝32。

c.EAP-EXT-ENC-KEY：

EAP-EXT-ENC-KEY用于计算(ciphering)已加密的TLV的内容。按以下方式使用在[I-D.ietf-hokey-emsk-hierarchy]中所定义的KDF从MSK_i——由最近成功的内部EAP方法所生成的MSK——导出EAP-EXT-ENC-KEY。

EAP-EXT-ENC-KEY＝prf+(MSK_i，“EAP-EXT-Encryption-Key”，length)；

通过在EAP-EXT交换期间由EAP服务器所选择的完整性算法来确定用于生成EAP-EXT-ENC-KEY的PRF。用于prf+的默认散列算法是PRF_HMAC_SHA2_256。

字段长度将取决于在EAP-EXT交换期间所协商的协商后的加密算法。例如，当使用AES-CBC-128时，长度＝16。

d.HOKEY-REAUTH-KEY：

HOKEY-REAUTH-KEY被用作HOKEY再认证机制所需的预先共享的密钥[I-D.ietf-hokey-erx]。HOKEY-REAUTH-KEY的长度取决于HOKEY再认证机制。如下使用[I-D.ietf-hokey-emsk-hierarchy]中所定义的USRK推导算法从EAP-EXT输出的EMSK导出HOKEY-REAUTH-KEY。

HOKEY-REAUTH-KEY＝KDF(EMSK，″EAP-EXT-Reauthentication-Key″，length)。

消息格式：

EAP-EXT使用EAP类型XX(由IANA来分配)。图6(A)示出包括[RFC3748]中所定义的公共EAP字段(即代码、标识符、长度和类型)的消息格式。

F：

E：

当消息是差错指示时，设置该比特。当设置该比特时，还需要设置F比特。参见对差错指示进行详细描述的以下部分。

版本：

8比特字段指示EAP-EXT方法的版本。该文献定义版本1。

保留：

性能：

性能字段包含扩展的EAP性能。在一些实施例中，性能字段具有如图6(B)所示的性能字段(这与图3(B)相似)。在此，每一比特与特定性能对应。每一比特的语义如下：

R：

该比特被设置为指示发送方支持HOKEY再认证[I-D.ietf-hokey-erx]。当将该比特设置在最终请求/EXT消息(即在设置了F比特的情况下的请求/EXT)中时，该消息需要包括服务器-IDTLV和对端-IDTLV，并且可以包括再认证-密钥-生存时间AVP。如果将该比特设置在最终请求/EXT和响应/EXT交换中，则对端和服务器需要生成HOKEY-REAUTH-KEY。包含在服务器-IDTLV和对端-IDTLV中的服务器-ID和对端-ID以及HOKEY-REAUTH-KEY用于HOKEY再认证。

C：

该比特被设置为指示发送方支持用于MSK的信道绑定机制。当该比特被设置在请求/EXT消息中时，需要包括一个信道-绑定-机制TLV，以指示由服务器所支持的信道绑定机制。如果对端支持并且想要使得能够由服务器所支持的信道绑定机制中的一个，则其发送设置了该比特的响应/EXT消息以及包含所选择的信道绑定机制的信道-绑定-机制TLV。如果该比特被设置在与一个信道绑定机制的成功协商交换的最终请求/EXT和响应/EXT中，并且EAP-EXT方法成功完成，则对端和服务器需要实现协商的信道绑定机制。

TLV：

零，一个或多个TLV(类型-长度-值)图6(c)示出TLV格式(这与图3(c)所示的实施例相似)。

类型：

该字段指示所述TLV的类型。

长度：

值：

该字段包含对于TLV类型特定的数据。

EAP-EXTTLV：

在这些实施例中，定义以下TLV。

a.方法TLV

方法TLV(类型1)包含从类型字段开始的EAP方法有效载荷。

b.AUTHTLV

AUTHTLV(类型2)包含用于保护EAP-EXT消息的完整性数据。EAP-EXT-AUTH-KEY用于计算AUTHTLV。在包括该字段的整个EAP消息上计算TLV值字段。在计算完整性数据之前，需要将该字段初始化为全零。该字段的长度取决于所使用的完整性算法。当完整性检查失败时，需要默默丢弃消息。默认完整性算法是HMAC-SHA-256[sha256]。

c.对端-IDTLV

对端-IDTLV(类型3)包含用于HOKEY再认证的对端的身份。

d.-服务器-IDTLV

服务器-IDTLV(类型4)包含用于HOKEY再认证的服务器的身份。

e.再认证-密钥-生存时间TLV

再认证-密钥-生存时间TLV(类型5)包含以秒为单位的HOKEY-REAUTH-KEY的生存时间。

f.PRFTLV

PRFTLV(类型6)包含[I-D.ietf-hokey-emsk-hierarchy]中所定义的一个或多个一字节PRF号。当该TLV被承载在请求中时，其指示由服务器所支持的PRF号。

当该TLV被承载在请求/EXT消息中时，对应响应/EXT消息可以包含该TLV。响应/EXT消息中的PRFTLV需要确切地包含由对端在请求/EXT消息中的PRF号之中所支持和选择的一个PRF号。如果使用以上所描述的PRFTLV交换成功地协商了PRF号，则对于KDF使用协商好的PRF，以导出将由EAP-EXT和USRK所输出的EAP密钥材料。否则，对于KDF使用[I-D.ietf-hokey-emsk-hierarchy]中所指定的默认PRF。

g.信道-绑定-机制TLV

信道-绑定-机制TLV(类型7)包含一个或多个一字节信道绑定机制号。当该TLV被承载在请求/EXT消息中时，其指示由服务器所支持的信道绑定机制号。当该TLV被承载在请求/EXT消息中时，对应响应/EXT消息可以包含该TLV。响应/EXT消息中的信道-绑定-机制TLV需要确切地包含由对端在请求/EXT消息中的信道绑定机制号之中所支持和选择的一个信道绑定机制号。如果使用以上所描述的信道-绑定-机制TLV成功地协商了信道绑定机制，则使得能够协商好的信道绑定机制。

在该文献中定义了以下信道绑定机制：机制1-[I-D.ohba-eap-channel-binding]；以及机制2-[arkko-eap-service-identity-auth]。

对于信道绑定机制1，用于prf+的默认散列算法是PRF_HMAC_SHA2_256。

对于信道绑定机制2，附加信道-绑定-数据TLV被承载在请求和响应中。

h.信道-绑定-数据TLV

信道-绑定-数据TLV(类型8)包含对于[arkko-eap-service-identity-auth]所使用的字节串数据。

i.加密-算法TLV

加密-算法TLV允许对用于计算加密后的TLV的加密算法进行协商。当该TLV被承载在请求/EXT中时，其指示由EAP服务器支持的加密算法。当该TLV被承载在请求/EXT消息中时，对应响应/EXT消息可以包含该TLV。响应/EXT消息中的加密-算法TLV需要确切地包含由对端在包含在请求/EXT消息中的加密算法TLV中的选项之中所支持并且选择的一个加密算法号。注意，EAP服务器可以强迫EAP对端使用默认加密算法(AES-CBC-128)。在此情况下，EAP对端不包括请求/EXT消息中的加密-算法TLV，并且以相同方式，EAP对端在响应/EXT中也不包括它。作为参考，图7(A)描述加密-算法TLV。

其包含以下列表中所定义的一个或多个一字节号：

0保留

1AES-CBC-128(默认)

2AES-CBC-256

33DES

4IDEA

注意，如果使用加密-算法TLV没有成功协商算法，则使用默认加密算法来替代。

j.完整性-算法TLV

为了简化并且为了避免bidding-down攻击，EAP-EXT方法不允许完整性算法协商。然而，EAP服务器可以从不同完整性算法中进行选择，并且通过完整性-算法TLV将该选择通知给EAP对端。如果EAP服务器不包括这个TLV，则默认值是HMAC-SHA-256。作为参考，图7(B)描述完整性-算法TLV。

其包含以下列表中所定义的一个或多个一字节号：

0保留

1HMAC-SHA-I

2HMAC-SHA-224

3HMAC-SHA-256(默认)

4HMAC-SHA-384

5HMAC-SHA-512

k.加密的TLV

加密的TLV(类型10)包含以EAP-EXT-ENC-KEY加密的一个或多个纯文本TLV。该字段的长度取决于所使用的加密算法。参照图7(C)。

其包含以下所定义的一个或多个一字节号：

类型：

(10)加密的TLV

长度：

4+IV长度+加密后的数据长度

IV：

IV是随机比特的字节串，前面的最高有效位。IV的长度取决于所使用的加密算法。例如，对于AES-CBC-128，IV是16字节(128比特)。

加密后的数据：

可变长度的加密后的TLV。加密后的数据包括以EAP-EXT-ENC-KEY所计算的一个或多个纯文本TLV。注意，取决于加密算法和纯文本数据的长度，可以在计算运算之前将填充数据添加到纯文本数据。

安全性考虑：

EAP-EXT允许对其内部的多个EAP方法进行排序。已知包括多个嵌套的认证方法或顺序的认证方法而没有对它们进行加密绑定的混合认证方法具有对中间人攻击的弱点。EAP-EXT能够通过保护每一内部EAP方法连同外部EAP方法(即EAP-EXT)而创建与在所述序列中由其前述成功内部方法所生成的密钥的加密绑定，并且最终输出从由最近成功的内部EAP方法所生成的EAP密钥材料所导出的EAP密钥材料。为了实现加密绑定，EAP-EXT需要内部EAP方法能够生成EAP密钥材料。

该方法输出从内部方法的MSK所计算的MSK和EMSK。因此，一起输出的MSK和EMSK的强度与内部方法的MSK的强度相同。

本发明的广泛范围：

虽然在此已经描述了本发明示例性实施例，但本领域技术人员应理解，基于该公开，本发明不限于在此所描述的各个优选实施例，而是包括具有等同元件、修改、省略、(例如交叉各个实施例的方面的)结合、改动和/或改变的任意和所有实施例。权利要求中的限制将基于权利要求中所采用的语言而广义地被解释，并且不限于在该说明书中或在该申请的诉讼期间所描述的示例，该申请的示例应理解为非排除性的。例如，在该公开中，术语“优选地”是非排除性的，并且表示“优选地，但不限于此”。在该公开中以及在该申请的诉讼期间，在对于具体权利要求限制，所有以下条件出现在所述限制中的情况下，将仅采用装置加功能或步骤加功能限制：a)明确地引用“装置”或“步骤”；b)明确地引用对应功能；以及c)没有陈述结构、材料或支持该结构的动作。在该公开中以及在该申请的诉讼期间，术语“本发明”或“发明”可以用于表示该公开中的一个或多个方面。语言“本发明”或“发明”不应不正确地解释为关键性的标识，不应不正确地解释为交叉应用所有方面或实施例(即，应理解，本发明具有多个方面和实施例)，并且不应不正确地解释为限制申请或权利要求的范围。在该公开中以及在该申请的诉讼期间，术语“实施例”可以用于描述任意方面、特征、处理或步骤、其任意结合、和/或其任意部分等等。在一些示例中，各个实施例可以包括重叠特征。在该公开中，可以采用以下缩写的术语：“e.g.”，其表示“例如”。

Claims

1.一种对关于EAP扩展功能的性能进行协商的EAP客户机和EAP服务器的处理方法，包括：

采用EAP扩展方法(EAP-EXT)，所述EAP扩展方法关于扩展功能在EAP服务器和EAP客户机之间提供性能交换，

其中，所述扩展功能不具有认证机制，并且其中，至少一个内部EAP方法运行在所述EAP扩展方法内部，以用于认证所述EAP客户机；

其中，通过基于所述至少一个内部EAP方法生成的EAP密钥材料获取所述EAP扩展方法的EAP密钥材料，在所述至少一个内部EAP方法和所述EAP扩展方法之间创建加密绑定，

其中所述处理方法采用顺序运行在EAP扩展方法内部的多个内部EAP方法，以及，每次多个内部EAP方法组成的序列中的内部EAP方法生成密钥材料，就生成新的EAP扩展密钥。

2.如权利要求1所述的处理方法，进一步包括：使得所述内部EAP方法生成密钥材料，并且以AUTHTLV保护所述EAP扩展方法中的消息。

3.如权利要求2所述的处理方法，其中，使用从最近成功的内部EAP方法的EAP密钥材料生成的EAP扩展密钥(EAP-EXT-KEY)来计算外部EAP扩展消息中的AUTHTLV。

4.如权利要求3所述的处理方法，其中，所述EAP扩展密钥用于计算AUTHTLV，以用于完整性保护EAP-EXT消息。

5.如权利要求4所述的处理方法，其中，利用用途特定根密钥推导算法而从通过内部EAP方法生成的EMSK导出所述EAP扩展密钥。

6.如权利要求1所述的处理方法，其中所述EAP扩展方法定义EAP-再认证密钥，所述EAP-再认证密钥被用作对于再认证机制所使用的EAP方法所需的预先共享密钥。

7.如权利要求6所述的处理方法，其中，利用用途特定根密钥推导算法而从EAP扩展方法输出的EMSK导出所述EAP-再认证密钥。

8.如权利要求1所述的处理方法，其中，所述EAP扩展方法采用包括公共EAP字段的消息格式，所述公共EAP字段具有设置成指示其为最近消息的比特、设置成指示差错的另一比特、多个比特的版本字段、用于将来扩展的多个比特的保留字段、以及每一个与特定性能对应的多个比特的性能字段。

9.如权利要求1所述的处理方法，进一步包括：通过性能比特的设置来提供关于所述扩展功能在所述服务器和所述客户机之间的所述性能交换。

10.如权利要求9所述的处理方法，其中，所述性能比特指示发送方支持信道绑定机制。

11.如权利要求9所述的处理方法，其中，所述性能比特指示发送方支持再认证。

12.如权利要求11所述的处理方法，其中，当所述性能比特指示发送方支持再认证被设置在最终请求/EXT消息中时，并且所述最终请求/EXT消息包括服务器-IDTLV和客户机-IDTLV。

13.如权利要求11所述的处理方法，其中，当所述性能比特指示发送方支持再认证被设置在最终请求/EXT和响应/EXT消息交换中时，所述EAP客户机和所述EAP服务器生成EAP-再认证密钥，并且其中，包含在服务器-IDTLV和客户机-IDTLV中的服务器-ID和客户机-ID以及所述EAP-再认证密钥用于再认证EAP方法。

14.如权利要求1所述的处理方法，其中，所述处理方法包括：

a)所述EAP服务器发送设置了至少一个性能比特的EAP-请求/EXT消息；

b)所述EAP客户机接收所述EAP-请求/EXT消息，并且发送设置了至少一个性能比特的EAP-响应/EXT消息。

15.如权利要求14所述的处理方法，其中，所述处理方法包括：

c)所述EAP服务器接收EAP-响应/EXT消息，并且发送EAP-请求/EXT消息，所述EAP-请求/EXT消息设置了F比特、至少一个性能比特、客户机-IDTLV、服务器-IDTLV和AUTHTLV；

d)所述EAP客户机接收以上在c)中的所述EAP-请求/EXT消息，并且发送EAP-响应/EXT消息，所述EAP-请求/EXT消息设置了指示EAP-EXT交换结束的F比特、至少一个性能比特和AUTHTLV；

e)所述EAP服务器接收d)中的所述EAP-响应/EXT消息，并且发送EAP-成功消息。

16.如权利要求1所述的处理方法，进一步包括，使得所述EAP客户机或者EAP服务器发送EAP扩展消息，所述EAP扩展消息设置了在所述客户机或所述服务器检测到差错的情况下的用于差错指示的比特，并且具有AUTHTLV。

17.如权利要求1所述的处理方法，其中所述获取EAP密钥材料包括对所述至少一个内部EAP方法生成的EAP密钥材料施加伪随机函数或者推导算法。

18.一种对关于EAP扩展功能的性能进行协商的EAP客户机和EAP服务器的处理方法，包括：

进一步包括在创建密钥材料之后执行受保护的消息交换，以避免性能信息收到攻击者的攻击；

进一步包括对所述EAP扩展方法内部的多个EAP方法进行排序；

进一步包括通过保护每一内部EAP方法连同EAP扩展方法而采用在多个EAP方法组成的序列中由其之前成功内部EAP方法所生成的密钥来创建加密绑定，并且最终输出由最近成功的内部EAP方法所生成的EAP密钥材料；

其中所述处理方法采用顺序运行在EAP扩展方法内部的多个内部EAP方法，以及，每次多个EAP方法组成的序列中的内部EAP方法生成密钥材料，就生成新的EAP扩展密钥。