具体实施方式
在所有附图中,对于对应的或相似的部件将使用相同的引用符号。
根据本发明的基本思想是,为了HMIPv6鉴权和授权,基于AAA基础结构而不是依赖于复杂的PKI基础结构来“引导”移动节点的HMIPv6业务。HMIPv6引导对于在归属网络中操作的移动节点和在受访网络中漫游的移动节点都是有效的,在前一种情况中采用归属网络AAA基础结构,而在后一种情况中采用将受访网络与归属网络链接的整个AAA基础结构。
代替通过采用公共密钥基础结构(PKI)在MN和MAP之间建立安全关联和分发安全密钥,优选地基于AAA基础结构来执行HMIPv6业务的鉴权和授权,例如通过AAA基础结构传送为HMIPv6业务对移动节点鉴权和授权所需的HMIPv6相关信息。
代替常规的MAP发现过程,响应从移动节点发起的MAP指定请求(移动节点发起的MAP指定)或作为网络发起的重新指定,还优选地将AAA基础结构用于将适当的MAP指定给移动节点,稍后将进行更详细地描述。在预定的MAP域内不再对含关于MAP的信息的路由器公告有任何强制依赖性。
AAA HMIPv6引导通常是基于通过AAA基础结构的在适当的MAP与移动节点之间的安全关联即安全关系的建立,以使相关通信安全,例如允许鉴权的HMIPv6 MAP绑定。
在首选实施方式中,在与HMIPv6安全关联过程相同的往返中捎带传输包括绑定更新的HMIPv6移动性过程,由此使得可能通过在公共过程中优化鉴权、授权和移动性来缩短整个建立时间。
术语“AAA”应该取其因特网草案、RFC和其他标准化文档中的一般含义。通常,AAA(授权、鉴权、计费)基础结构的鉴权和安全密钥同意基于对称密码学,意味着在移动节点和归属网络营运商或可信方之间存在共享的初始秘密。在一些场合和应用中,例如可以禁用或不实施AAA基础结构的计费特征。AAA基础结构在归属网络、中间网络(如果有的话)和/或受访网络中一般包括一个或多个AAA服务器,而且还可以包括一个或多个AAA客户。
一般来说,如直径协议的AAA协议恰恰使移动用户能够在不一定由他们的归属服务提供商所有的网络中漫游和获得服务。因此为了在商业网络中部署移动IP,需要有对该协议的AAA支持。对于无任何分级移动性管理的移动IPv6(MIPv6)的特殊情况,提出了因特网草案[3],它规定一种直径的新应用,它启用在不是归属营运商管理的网络的网络中漫游的MIPv6。在我们于2003年6月18日提交的美国临时专利申请60/479156并且还在后来的因特网草案[4]中,建议一种用于基于AAA基础结构来执行移动IPv6授权和配置的体系结构和相关协议。归属提供商的AAA服务器与移动节点之间的为MIPv6的必要交互是使用EAP(可扩展鉴权协议)来实现的,它将用于移动IPv6协商的信息与鉴权数据一起传送。
图2是示出一种根据本发明示范实施例的HMIPv6支持的创新体系结构的示意图。移动节点130在受访网络中漫游,并通过使用将受访网络与移动节点的归属网络链接的AAA基础结构来执行HMIPv6鉴权和授权。在该示例中,AAA基础结构基本上涉及AAA归属网络服务器110、受访网络中的AAA受访网络服务器120和AAA客户122。
优选地,可以将AAA受访网络服务器(AAAv)120用作适合用于MAP指定的AAA基础结构组件,在选择MAP时考虑受访营运商的策略。MAP的选择可以例如基于可用MAP的当前负载、移动节点的位置和/或可能由移动节点给出的偏好。
AAA基础结构的主要组件是AAAh服务器110,它优选地将对MAP指定的任何请求从移动节点转发到AAAv服务器120,并还生成用于在给定的移动节点130和指定的MAP 125之间的立即的或将来的安全关联的安全密钥或类似的证书。然后通常将安全密钥经由AAAv 120从AAAh 110传送到MAP 125,并且MAP 125优选地经由AAAv 120以用于完成安全关联的信息响应AAAh 110。最后,AAAh服务器110将生成的且收集的HMIPv6授权信息通过AAA基础结构发送到移动节点130。假定采用AAA基础结构的安全隧道或其他安全措施如加密和源完整性保护来传送如安全密钥的敏感信息。
对AAA基础结构的依赖提供用于引导HMIPv6业务的不同可能性。例如,提供新的鉴权协议或提供对通过AAA基础结构承载的鉴权协议的扩展和/或增强AAA框架协议应用以承载HMIPv6相关信息是可能的,如图2示意所示。
优选地,利用扩展的鉴权协议,如适合于HMIPv6的扩展EAP(可扩展鉴权协议)协议,另外还有增强的AAA框架协议应用,如用于AAAh服务器与受访网络MAP之间的经由AAAv服务器的接口的HMIPv6直径或RADIUS应用。
例如,在移动节点与受访网络中的AAA客户之间,一种新的或扩展的鉴权协议可以由PANA(用于承载网络接入鉴权的协议)、PPP(点到点协议)、IEEE 802.1X或甚至通过GPRS/UMTS接口来承载,以及在AAA基础结构内由直径或类似的AAA框架或载体协议来承载。
备选地,在不支持任何EAP扩展的情况下,使用增强的AAA框架协议应用,如一种新的或扩展的直径或RADIUS应用。对于移动节点和AAA客户之间的路径,可以例如由ICMP(因特网控制消息协议)来承载直径或RADIUS应用。
还认识到,存在这样的情况,使MAP位于归属网络或其他网络中是有益的,例如对于受访网络不提供MAP支持的情况。图3示出MAP位于归属网络时HMIPv6支持的示范体系结构。
此处将AAA归属网络服务器(AAAh)110用于MAP指定是有益的。优选地,AAA归属网络服务器(AAAh)110还生成用于在移动节点与指定的MAP 125之间的安全关联的安全密钥或类似的安全参数或证书,并将所述安全密钥发送到MAP 125。MAP 125以用于完成安全关联的信息响应AAAh 110,并且AAAh 110随后通过AAA基础结构将HMIPv6授权信息发送到移动节点130。
因为MAP 125位于归属网络,所以AAAv 120无需查看该事务,并且具有用于HMIPv6鉴权和授权的“端到端过程”从而是可能的。这优选地通过使用扩展的鉴权协议来实现,如适合于HMIPv6的扩展EAP(可扩展鉴权协议)协议。备选地,可以利用增强的AAA框架协议应用,如HMIPv6直径或RADIUS应用。位于归属网络的MAP125还可以用于解决HA可伸缩性问题,通过减少MAP域内移动期间去往HA 115的绑定更新的数量来卸载HA。通过选择在地形上靠近MN位置的MAP,可以实现快速切换。
应该理解,本发明去除了MAP 125需要位于受访网络的现有技术的限制。现在,MAP的位置可以在归属网络、受访网络或其他网络中。在技术上来说,MN与任何MAP绑定都是可能的,只要利用AAA支持可以获得MAP上的RCoA,如果营运商允许这样的话。
在以下示范情况期间可以发生MAP的重新指定:
·MN和MAP之间的安全密钥到期-对于此情况,MN发起HMIPv6重新鉴权/授权,并且网络可以基于例如MN的当前拓扑位置指定不同的更适当的MAP。
·在移动节点请求时(MN发起的)-对于此情况,MN发起HMIPv6重新鉴权/授权,请求重新指定MAP。
·在网络请求时(网络发起的)-对于此情况,AAAh或AAAv发起MAP的重新指定,并在此需求出现时,例如当MN移动到由新MAP更好地覆盖的AR时将其“推”给MN。
再参考图2和3,下面概括段AAA客户-AAAh和AAAh-(AAAv)-MAP之间的不同协议组合的若干可能的示例:
AAA客户<->AAA h |
AAAh<->(AAAv)<->MAP |
| |
(i)AAA HMIPv6应用 |
AAA HMIPv6应用 |
| |
(ii)扩展的鉴权协议 |
AAA HMIPv6应用 |
| |
(iii)扩展的鉴权协议 |
扩展的鉴权协议 |
组合(iii)尤其适用于MAP位于归属网络的情况。当MAP位于受访网络时,在基于受访网络策略选择MAP时可能涉及AAAv。
在图4示意示出的另一个场合中,移动节点130实际位于归属网络,并且归属网络的AAA基础结构组件如AAAh服务器110利用归属网络中的MAP 125提供对HMIPv6业务的必要支持。这意味着只需要将扩展的鉴权HMIPv6协议和AAA HMIPv6应用的相关部分用于交换必要的鉴权和授权信息。
图5是根据本发首选示范实施例的AAA归属网络服务器的示意框图。在此示例中,AAAh服务器110基本上包括任选的MAP指定模块111、安全关联模块112、授权信息管理器113和输入/输出(I/O)接口114。对于MAP在归属网络中的情况,AAAh服务器110包括MAP指定模块111,它可操作用于指定和/或重新指定适合的MAP给移动节点。对于MAP在受访网络中的情况,AAAh服务器110通常在其I/O接口114上接收必要的MAP指定信息。AAAh服务器通常还从移动节点接收密钥种子和绑定更新(BU)。备选地,AAAh服务器本身生成密钥种子并将其发送到移动节点。安全关联模块112优选地生成所需的安全密钥以响应该种子,并将该密钥安全地发送到MAP(直接到归属网络中的MAP或经由AAAv服务器到受访网络中的MAP)。绑定更新(BU)也被转发到MAP。AAAh服务器110从MAP接收RCoA地址并将该数据连同其他相关授权(和/或配置)信息存储在授权信息管理器113中。AAAh服务器还可以从MAP接收用于完成安全关联的诸如IPSec信息的信息。最后,将收集的授权(和/或配置)信息传送到移动节点。
AAAh服务器还可以负责归属地址指定(除非归属地址是由MN本身配置的)和/或归属代理指定。
图6是根据本发明首选示范实施例的MAP节点的示意框图。在此示例中,MAP 125基本上包括RCoA指定模块126、安全关联模块127和输入/输出(I/O)接口128。MAP优选地与AAA归属网络服务器交互,以支持建立与移动节点的安全关联。MAP通过I/O接口128从AAA归属网络服务器接收安全密钥,以安全地存储在安全关联模块127中。MAP还准备用于完成与移动节点的安全关联所必需的信息,并将其发送回AAA归属网络服务器,又通过AAA基础结构将其转发到移动节点。为在MAP中绑定,RCoA模块126优选地指定RCoA地址给移动节点,并将该地址连同移动节点的LCoA地址存储在MAP的绑定高速缓存(未示出)中,并且还将指定的RCoA地址发送到AAA归属网络服务器,以随后转发到移动节点。
为了更好地理解本发明,将马上描述HMIPv6的扩展鉴权协议和适合于HMIPv6的AAA框架协议应用的更详细一些的示例。
HMIPv6的扩展鉴权协议
在首选示范实施例中,定义了一种HMIPv6的扩展鉴权协议,本文以新的或扩展EAP鉴权协议(称为“HMIPv6鉴权方法”或“EAP/HMIPv6”)为例,它承载便于例如发现MAP、动态分配MAP、动态分配RCoA、MN和MAP之间分发安全密钥和/或可能的捎带传输HMIPv6移动性过程的HMIPv6相关信息。
如果希望,HMIPv6和MIPv6鉴权和/或授权可以集成在相同的协议中,例如将EAP/HMIPv6定义为EAP/MIPv6协议的超集,除了MIPv6特定的类型-长度-值(TLV),它还定义新的HMIP特定的TLV属性。通过将EAP/MIPv6 TLV属性作为EAP/HMIPv6的一部分包括,将MIPv6和HMIPv6鉴权和/或授权的同时执行容纳于单个遍历中是可能的,这允许更短的建立时间。还可能的是在没有MIPv6鉴权和/或授权的情况下仅执行HMIPv6鉴权和/或授权,且反之亦然,取决于特定情况下MN的具体需求。这使单个EAP鉴权协议EAP/HMIPv6可以灵活地在各种用例场合使用。
具体地,依赖EAP扩展提供一种流线式解决方案,它易于管理且一流,向后兼容问题最少。EAP的使用使AAA客户(和AAAv)可以至少在MAP位于归属网络时对HMIPv6过程不可知(即这去除对受访网络的HMIPv6支持的依赖),并仅充当直通代理。这是使用EAP的主要优点之一。
如前面所指出的,在移动节点与受访网络中的AAA客户之间,EAP/HMIPv6可以例如由PANA、PPP、ICMP、IEEE 802.1X或甚至通过GPRS/UMTS接口来承载。虽然,PANA在一些情况中可能是首选的,但是如PPP[6]和IEEE 802.1X[7]的满足对较低层排序保证的EAP需求的其他载体协议可以用于承载MN和AAA客户之间的EAP/MIPv6。具体对于3GPP2 CDMA2000的情况,在MN和AAA客户之间,使用对于EAP[6]协议字段值设为C227(Hex)的PPP数据链路层协议封装来承载EAP/HMIPv6是可能的。
首选实施例将直径、RADIUS或类似的AAA框架或载体协议用于AAA客户与AAAh服务器之间的通信。例如,在AAA客户以外朝向AAA基础结构和在AAA基础结构内,直径EAP应用[5]可以用于将EAP/HMIPv6封装在直径内,即PAA/AAA客户和AAAh之间。直径协议还可以被AAAh用于经由MIP过滤器规则任选地将MIP分组过滤器指定给PAA/EP和HA,它们对应于过滤器增强点。为PAA安全,直径协议还可以被AAAh用于将安全密钥分发给PAA,以及任选地发送QoS参数信号。
应该注意,尽管直径是首选,但是有时改为使用另一种具有对本领域技术人员显而易见的修改的如RADIUS的AAA协议可以是适当的。
再者,在EAP/HMIPv6中捎带传输HMIPv6移动性过程使得可能通过在公共过程中优化鉴权、授权和移动性来缩短整个建立时间。
示范EAP/HMIPv6协议的详细信息
在下文中,提供示范EAP/HMIPv6协议的详细信息,以说明整体流程的示例和概念的可行性(viability of concept)。
EAP TLV属性
在第一实现示例中,根据EAP/HMIPv6定义一组新的EAP TLV属性。凭借这些属性,除了主要的IPv6鉴权信息,EAP协议还可以承载HMIPv6相关信息和任选地还可以承载MIPv6相关信息。
对于EAP/HMIPv6,不同的鉴权协议是可能的。在首选实施例中,本发明提出通过MD5询问鉴权的实施方式,但是其他协议也属于本发明的范围。
下表1中给出EAP/HMIPv6 TLV的示范概括矩阵:
EAP/HMIPv6类型-长度-值 |
源 |
目的地 |
目的 |
注释 |
HMIPv6特定的TLV:·RCoA请求EAP-TLV属性·RCoA响应EAP-TLV属性·RCoA EAP-TLV属性·MAP地址请求EAP-TLV属性·MAP地址响应EAP-TLV属性·MAP-MN预共享密钥生成现用值EAP-TLV属性·MAP-MN预共享密钥EAP-TLV属性·MAP IKE KeyID EAP-TLV属性·MAP-MN IPSec SPI EAP-TLV属性·MAP-MN IPSec协议EAP-TLV属性·MAP-MN IPSec密码EAP-TLV属性·MAP-MN IPSec密钥有效期EAP-TLV属性·HMIP-绑定-更新EAP-TLV属性·HMIP-绑定-确认EAP-TLV属性 | MNAAAhAAAhAAAhMNAAAhAAAhMNAAAhAAAhMAPAAAhMAPAAAhMAPAAAhMAPAAAhMNMNMAPAAAh | AAAhMNMNMAPAAAhMNMNAAAhMAPMNMN经AAAhMNMN经AAAhMNMN经AAAhMNMN经AAAhMNMAP经AAAhAAAhMN经AAAhMN | 请求RCoA指定RCoA从AAAv转发RCoA指定RCoA请求MAP地址指定MAP地址从AAAv转发MAP地址MN-MAP密钥的种子指定MN-MAP密钥指定IKEKeyID指定SPI从MAP转发指定IPSec协议从MAP转发指定IPSec密码从MAP转发指定IPSec密钥有效期从MAP转发捎带传输HMIP绑定更新捎带传输HMIP绑定更新捎带传输HMIP绑定确认从MAP转发 | MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于归属网络MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于受访网络 |
MIPv6特定的TLV(任选):·MIPv6归属地址EAP-TLV属性·HA-MN预共享密钥EAP-TLV属性·HA-MN IPSec协议EAP-TLV属性·HA-MN IPSec密码EAP-TLV属性·MIP-绑定-更新EAP-TLV属性·MIP-绑定-确认EAP-TLV属性 | AAAhAAAhHAHAMNHA | HAHAMN经AAAhMN经AAAhHA经AAAhMN经AAAh | 指定MN归属地址指定HA-MN密钥指定IPSec协议指定IPSec密码捎带传输MIP绑定更新捎带传输MIP绑定确认 | |
基本MIPv6TLV(任选):·MD5询问EAP-TLV属性 | AAAh | MN | 发布询问 | |
EAP/HMIPv6类型-长度-值 |
源 |
目的地 |
目的 |
注释 |
·MD5响应EAP-TLV属性·MIPv6归属地址请求EAP-TLV属性·MIPv6归属地址响应EAP-TLV属性·MIPv6归属代理地址请求EAP-TLV属性·MIPv6归属代理地址响应EAP-TLV属性·HA-MN预共享密钥生成现用值EAP-TLV属性·IKE KeyID EAP-TLV属性·HA-MN IPSec SPI EAP-TLV属性·HA-MN IPSec密钥有效期EAP-TLV属性·PAC-PAA预共享密钥生成现用值EAP-TLV属性 |
MNMNAAAhMNAAAhMNAAAhHAHAMN |
AAAhAAAhMNAAAhMNAAAhMNMN经AAAhMN经AAAhAAAh |
提供对询问的响应请求MN归属地址指定MN归属地址请求HA地址指定HA地址HA-MN密钥的种子用于从AAAh获得HA-MN预共享密钥的信息指定SPI指定IP Sec密钥有效期PAC-PAA密钥的种子 | |
注意:IKE KeyID包括一些八位位组,它告知HA/MAP如何从AAAh检索(或生成)HA-MN预共享密钥/MAP-MN预共享密钥。
可以为HMIPv6定义以下示范EAP-TLV属性的一个或多个:
·RCoA请求EAP-TLV属性:
这表示对鉴权的MN的动态分配的RCoA地址的请求。在MN请求被鉴权和被给予HMIPv6业务时,由MN向AAAH请求它。
·RCoA响应EAP-TLV属性:
这表示鉴权的MN的动态分配的RCoA地址。在对例如已经请求的MN成功鉴权时,从AAAh将其通知给MN。
·RCoA EAP-TLV属性:
这表示鉴权的MN的动态分配的RCoA地址。在对例如已经请求的MN成功鉴权时,从AAAh将其通知给MAP,以在MAP中指定RCoA地址。
·MAP地址请求EAP-TLV属性:
这表示当成功鉴权时对MN的动态分配的MAP的地址的请求。在MN请求被鉴权和被给予HMIPv6业务时,由MN向AAAH请求它。因为HMIPv6协议具有动态MAP发现方法来分配MAP,所以该属性是任选的。
·MAP地址响应EAP-TLV属性:
这表示鉴权的MN的动态分配的MAP地址。当MN请求被鉴权和被给予HMIPv6业务时,从AAAh将其通知给MN。因为HMIPv6协议具有动态MAP发现方法来分配MAP,所以该属性是任选的。
·MAP-MN预共享密钥生成现用值EAP-TLV属性:
这表示MN随机生成的作为用于生成MAP-MN之间的预共享密钥的种子的八位位组串。通过对该现用值和MN与AAAh之间的共享密钥的组合使用适当的散列算法,MN可以内部生成MAP-MN预共享密钥。当已经存在有效的MAP-MN预共享密钥时,该属性是任选的。
·MAP-MN预共享密钥EAP-TLV属性:
这表示MAP-MN之间动态生成的预共享密钥。当MN请求被鉴权和被给予HMIPv6业务时,从AAAh将其通知给MAP。通过对由MAP-MN预共享密钥生成现用值EAP-TLV属性给出的现用值和MN与AAAh之间的共享密钥的组合使用适当的散列算法,AAAh可以内部生成MAP-MN预共享密钥。当已经存在有效的MAP-MN预共享密钥时,该属性是任选的。
·MAP IKE KeyID EAP-TLV属性:
这表示[8]中定义的ID有效负荷。KeyID由AAAh生成,并当成功鉴权时被发送到MN。KeyID包括一些八位位组,它告知MAP如何从AAAh检索(或生成)MAP-MN预共享密钥。该属性是任选的,以及当MN未提交MAP-MN预共享密钥生成现用值即已经存在有效的MAP-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。对于MAP-MN预共享密钥由AAAh传送到MAP时的情况也不需要该属性。
·MAP-MN IPSec SPI EAP-TLV属性:
这表示MAP-MN之间的IPSec的安全参数索引。对于MAP-MN预共享密钥由AAAh传送到MAP时的情况,这优选地由MAP生成,并通知给MN。该属性是任选的,以及当MN未提交MAP-MN预共享密生成现用值即已经存在有效的MAP-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。
·MAP-MN IPSec协议EAP-TLV属性:
这表示MAP-MN之间的IPSec协议(例如ESP或AH)。对于MAP-MN预共享密钥由AAAh传送到MAP时的情况,这被通知给MN。该属性是任选的,以及当MN未提交MAP-MN预共享密钥生成现用值即已经存在有效的MAP-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。
·MAP-MN IPSec密码EAP-TLV属性:
这表示MAP-MN之间的IPSec的密码算法。对于MAP-MN预共享密钥由AAAh传送到MAP时的情况,这被通知给MN。该属性是任选的,以及当MN未提交MAP-MN预共享密钥生成现用值即已经存在有效的MAP-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。
·MAP-MN IPSec密钥有效期EAP-TLV属性:
这表示MAP-MN之间的IPSec的密钥有效期。对于MAP-MN预共享密钥由AAAh传送到MAP时的情况,这被通知给MN。该属性是任选的,以及当MN未提交MAP-MN预共享密钥生成现用值即已经存在有效的MAP-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。
·HMIP-绑定-更新EAP-TLV属性:
这表示MN生成的MAP绑定更新分组。这在鉴权和授权交换中经由AAAh从MN转发到MAP。该属性是任选的,以及当MN将MAP绑定更新分组直接发送到MAP时,一般不需要该属性。
·HMIP-绑定-确认EAP-TLV属性:
这表示MAP生成的MAP绑定确认分组。这在鉴权和授权交换中经由AAAh从MAP转发到MN。该属性是任选的,以及当MAP将MAP绑定确认更新分组直接发送到MN时,一般不需要该属性。
对于特殊的MIPv6,可以定义以下任选的EAP-TLV属性:
·MIPv6归属地址EAP-TLV属性:
这表示鉴权的MN的动态分配的MIPv6归属地址。在对例如已经请求的MN成功鉴权时从AAAh将其通知给HA,以在HA中指定MIPv6归属地址。
·HA-MN预共享密钥EAP-TLV属性:
这表示HA-MN之间的动态生成的预共享密钥。当MN请求被鉴权和被给予MIPv6业务时,从AAAh将其通知给HA。通过对由HA-MN预共享密钥生成现用值EAP-TLV属性给出的现用值和MN与AAAh之间的共享密钥的组合使用适当的散列算法,AAAh可以内部生成HA-MN预共享密钥。当已经存在有效的HA-MN预共享密钥时,该属性是任选的。
·HA-MN IPSec协议EAP-TLV属性:
这表示HA-MN之间的IPSec协议(例如ESP或AH)。对于HA-MN预共享密钥由AAAh传送到HA时的情况,这被通知给MN。该属性是任选的,以及当MN未提交HA-MN预共享密钥生成现用值即已经存在有效的HA-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。
·HA-MN IPSec密码EAP-TLV属性:
这表示HA-MN之间的IPSec的密码算法。对于HA-MN预共享密钥由AAAh传送到HA时的情况,这被通知给MN。该属性是任选的,以及当MN未提交HA-MN预共享密钥生成现用值即已经存在有效的HA-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。
·MIP-绑定-更新EAP-TLV属性:
这表示MN生成的绑定更新分组。这在鉴权和授权交换中经由AAAh从MN转发到HA。该属性是任选的,以及当MN将绑定更新分组直接发送到HA时,一般不需要该属性。
·MIP-绑定-确认EAP-TLV属性:
这表示HA生成的绑定确认分组。这在鉴权和授权交换中经由AAAh从HA转发到MN。该属性是任选的,以及当HA将绑定确认分组直接发送到MN时,一般不需要该属性。
可以定义以下用于HMIPv6/MIPv6鉴权的EAP-TLV属性:
·MD5询问EAP-TLV属性:
这表示AAAh随机生成并发送到MN以实现MD5询问的八位位组串。
·MD5响应EAP-TLV属性:
这表示作为MD5散列函数的结果生成的连同AAAh和MN之间的预共享秘密密钥的八位位组串。
对于动态MN归属地址分配,可以定义以下任选的EAP-TLV属性:
·MIPv6归属地址请求EAP-TLV属性:
这表示对鉴权的MN的动态分配的MIPv6归属地址的请求。在MN最初请求被鉴权和被给予MIPv6业务时,由MN向AAAh请求它。当MN已经具有先前指定的归属地址时,例如MIPv6切换期间,该属性是任选的。
·MIPv6归属地址响应EAP-TLV属性:
这表示鉴权的MN的动态分配的MIPv6归属地址。在对例如已经请求的MN成功鉴权时,从AAAh将其通知给MN。当MN已经具有先前指定的归属地址时,例如MIPv6切换期间,该属性是任选的。
对于动态HA分配,可以定义以下任选的EAP-TLV属性:
·MIPv6归属代理地址请求EAP-TLV属性:
这表示当成功鉴权时对MN的动态分配的HA的地址的请求。在MN最初请求被鉴权和被给予MIPv6业务时,由MN向AAAH请求它。当MIPv6协议具有动态HA发现方法以分配HA时,该属性是任选的。当MN已经具有先前指定的HA时,例如MIPv6切换期间,该属性也是任选的。
·MIPv6归属代理地址响应EAP-TLV属性:
这表示鉴权的MN的动态分配的HA地址。当MN最初请求被鉴权和被给予MIPv6业务时,从AAAh将其通知给MN。因为MIPv6协议具有动态的归属代理发现方法以分配归属代理,所以该属性是任选的。当MN已经具有先前指定的HA时,例如MIPv6切换期间,该属性也是任选的。
可以定义以下任选的EAP-TLV属性以在HA和MN之间分发安全密钥:
·HA-MN预共享密钥生成现用值EAP-TLV属性:
这表示MN随机生成的作为用于生成HA-MN之间预共享密钥的种子的八位位组串。通过对该现用值和MN与AAAh之间的共享密钥的组合使用适当的散列算法,MN可以内部生成HA-MN预共享密钥。当已经存在有效的HA-MN预共享密钥时,例如MIPv6切换期间,该属性常是任选的。
·IKE KeyID EAP-TLV属性:
这表示[8]中定义的ID有效负荷。KeyID由AAAh生成,并当成功鉴权时被发送到MN。KeyID包括一些八位位组,它告知HA如何从AAAh检索(或生成)HA-MN预共享密钥。该属性是任选的,以及当MN未提交HA-MN预共享密钥生成现用值即已经存在有效的HA-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。在HA-MN预共享密钥由AAAh经由[9]中定义的AAAh-HA接口传送到HA时的情况中也不需要该属性。
·HA-MN IPSec SPI EAP-TLV属性:
这表示HA和MN之间的IPSec的安全参数索引。对于HA-MN预共享密钥由AAAh经由[9]中定义的AAAh-HA接口传送到HA时的情况,这由HA生成并被通知给MN。该属性是任选的,以及当MN未提交HA-MN预共享密钥生成现用值即已经存在有效的HA-MN预共享密钥时,例如MIPv6切换期间,一般不需要它。当未使用[9]中定义的AAAh-HA接口时,也不需要它。
·HA-MN IPSec密钥有效期EAP-TLV属性:
这表示HA和MN之间的IPSec的密钥有效期。对于HA-MN预共享密钥由AAAh经由[9]中定义的AAAh-HA接口传送到HA时的情况,这由HA生成并被通知给MN。该属性是任选的,以及当MN未提交HA-MN预共享密钥生成现用值即已经存在有效的HA-MN预共享密钥时,例如MIPv6切换期间,一般不需要该属性。当不使用[9]中定义的AAAh-HA接口时,也不需要它。
最后,可以定义以下任选的EAP-TLV属性以在PAC和PAA之间分发安全密钥以实现PANA安全:
·PAC-PAA预共享密钥生成现用值EAP-TLV属性:
这表示MN/PAC随机生成的作为用于生成PAC-PAA之间的预共享密钥的种子的八位位组串。通过对该现用值和MN与AAAh之间的共享密钥的组合使用适当的散列算法,MN/PAC可以内部生成PAC-PAA预共享密钥。需要该属性来实现PANA安全。
备选地,AAAh服务器可以配置用于不仅生成MN-MAP安全密钥,还生成完成安全关联所需的信息。
从上述示例可以看出,HMIPv6相关配置通常被视为整个授权过程的一部分。
EAP通用容器属性(EAP GCA)
在备选的EAP实现中,EAP被用作HMIPv6相关信息的载体(任选地还有MIPv6信息),其中不创建新的所说的EAP方法,而是通过在可以与任何EAP方法一起使用的通用容器EAP属性中承载信息来实施。
在该基于接入网中AAA支持的示范实现中,EAP以通用容器属性来增补,通用容器属性可以用于承载任何(也许非EAP相关的)数据,例如HMIPv6特定的数据和任选地还有MIPv6特定的数据(如果还希望MIPv6引导的话)。这使MN和AAAh可以至少对于MAP在归属网络的情况以对受访域透明的方式通信,受访域包括接入网、AAA客户和AAAv。在AAA客户和AAAh之间,EAP优选地在AAA协议中承载,例如直径EAP应用或甚至RADIUS[10]、[11]。
该新属性应该优选地可用于所有EAP方法,而且可以被包括在任何EAP消息中,包括EAP成功/失败消息。在此解决方案中,该新通用容器属性用于在MN和AAAh之间传送HMIPv6特定的数据(任选地还有MIPv6数据)。该解决方案还可以包括用于在AAAh和HA之间交换AAA和相关数据的直径或RADIUS应用。
下文中,根据目前的EAP协议[12]来讨论通用容器属性(GCA)的可能实施方式。如所述,通用容器属性应该优选地可用于所有方法,而且应该可能在任何EAP消息中包括,包括EAP成功/失败消息。这意味着它应该是EAP层而非EAP方法层的一部分[12]。重要的问题是向后兼容(这是指就MN和EAP鉴权者(通常位于NAS)而言的向后兼容。MN和EAP鉴权服务器(即AAAh)假定为总是兼容的)。在这些给定的示例中,GCA的使用一般假定,以向后兼容和对EAP鉴权者透明的方式在EAP中引入该新属性。引入含有这些特性的GCA需要一些特殊的考虑,将在下面讨论。
例如,GCA的格式可以是两字节的GCA长度指示符,后跟GCA接受方指示符和GCA有效负荷。GCA接受方指示符指示EAP模决应将接收到的GCA的有效负荷发送到什么内部实体(即该指示符对应于IP报头中的协议/下一个报头字段或UDP和TCP报头中的端口号)。GCA有效负荷则是不由EAP层解释的通用数据块。没有GCA优选地可以通过将GCA长度指示符设为零来指示。
为了实现向后兼容,GCA应该优选地以对直通EAP鉴权者透明的方式被包含在EAP分组中。直通EAP鉴权者是在MN和后端EAP鉴权服务器(AAA服务器)之间中继(几乎所有)EAP分组的EAP鉴权者(驻留在NAS中;通常是WLAN AP或接入路由器)。根据[12]中所述,EAP鉴权者的直通行为是基于EAP层报头来中继EAP分组,即EAP分组的开始位置中的代码、标识符和长度字段。这意味着,如果将GCA置于EAP层报头之后(即在代码、标识符和长度字段之后),则可能实现所期望的透明性(和由此实现向后兼容)。
但是,EAP鉴权者一般还需要检查EAP响应分组的类型字段(在EAP层报头之后),以识别EAP身份响应分组,据此提取AAA路由选择所需的NAI。当EAP鉴权者识别EAP身份响应分组时,它从类型字段之后的类型-数据字段提取NAI。因此,将GCA置于紧随EAP层报头之后(以对EAP鉴权者透明的方式)仅在EAP请求分组中可能。因此,一般首选是将GCA安排在类型字段之后或甚至(可能空终止)类型-数据字段之后。
将GCA置于紧随类型字段之后允许在除EAP身份响应分组外的所有EAP响应分组中使用GCA。在EAP身份响应分组中使用GCA会被禁止,因为从这些分组中,EAP鉴权者需要从类型-数据字段提取NAI,而遗留EAP鉴权者预期在紧随类型字段之后查找它。考虑到EAP一般具有相当少的往返,这可能限制GCA的使用。可能,GCA可以被置于EAP身份响应分组中的空终止类型-数据字段之后,而在其他EAP分组中保持其在类型字段之后的位置。
会经常希望可以在所有EAP分组中一致使用的GCA位置。从上述讨论看起来,可以以向后兼容的方式将GCA置于所有EAP分组中的位置是在分组的末端,或多或少作为尾部。但是,该GCA位置对于没有类型-数据参数的显式长度指示符而依赖于EAP层报头中的长度字段的那些EAP分组可能导致问题。在这些分组中,不能将GCA与类型-数据字段区分。
为了解决此问题,应该反转GCA长度指示符、GCA接受方指示符以及GCA有效负荷的次序,使得GCA长度指示符最后出现。从而,当将GCA置于EAP分组的末端时,EAP分组的最后两个八位位组(其长度由EAP层报头中的长度字段指示)始终会是GCA长度指示符。除非GCA长度指示符为零,GCA接受方指示符会出现在GCA长度指示符之前而GCA有效负荷(其大小由GCA长度指示符确定)位于GCA接受方指示符之前。通过该原理,识别EAP分组中的GCA并将GCA与类型-数据字段区分总是可能。GCA的使用仍是对直通EAP鉴权者透明的。
与该GCA解决方案的向后兼容还要求,EAP鉴权者不尝试从EAP请求/响应分组提取信息(除了EAP层报头和NAI),并且它接受成功/失败分组中的长度字段指示大于4的值。
处理向后兼容问题的备选方式是,使用EAP GCA测试请求/响应分组(即具有类型字段的新定义值的新EAP分组)来判断MN是否支持GCA。
在初始的EAP身份请求/响应分组交换前或后,支持GCA的EAP鉴权者将EAP GCA测试请求分组(即具有专用类型值的EAP请求分组)发送到MN。([13]中的EAP对等状态机器指示两种备选的发送时间都是可行的)。如果MN支持GCA,则它以EAP GCA测试响应分组响应。否则,MN将EAP GCA测试请求分组解释为使用未知EAP方法的请求,并由此MN以EAP Nak分组响应。基于来自MN的响应,EAP鉴权者可以判断MN是否支持GCA。
支持GCA的MN可以根据EAP GCA测试请求分组的有无来判断EAP鉴权者是否支持GCA。如果当期望时(即在EAP身份请求/响应交换前或后)接收到EAP GCA测试请求分组,则EAP鉴权者支持GCA。否则,EAP鉴权者不支持GCA。
如果MN和EAP鉴权者都支持GCA,则可以将其置于所有随后的EAP分组中的EAP层报头之后(GCA分量为原始顺序)。否则,GCA可以仍被包含在EAP分组中,这些EAP分组使它可以以向后兼容方式被包含(如上所述)。
所述处理向后兼容问题的备选方式有一些局限。首先,浪费了一个MN-EAP鉴权者往返。再者,如果在初始的EAP身份请求/响应分组交换之后交换EAP GCA测试请求/响应分组,则GCA无法在EAP身份响应分组中使用。该实施例还可以要求EAP鉴权者(可能是NAS)使用EAP的修改版本,例如EAPv2。因此,虽然其他备选方式是可能的,但是将GCA安排在EAP分组中的首选方式通常会是在分组末端作为尾部,GCA长度指示符在最后,在GCA有效负荷和GCA接受方指示符之后。
如果对于在GCA中交换的数据,EAP往返的数量不够,则为了传送GCA,AAAh可以通过EAP通知请求/响应交换来增加EAP往返的数量。
另一种变体实际是在EAP协议栈的方法层上的EAP方法中引入GCA。如果GCA设为方法特定的,则GCA不会引入任何向后兼容问题,因为它将通常是类型-数据字段的一部分。
EAP/HMIPv6的示范信令流
图7示出针对MAP位于归属网络时的情况的示范EAP/HMIPv6(直径)信令流。
AAA客户使用EAP(请求身份)请求MN鉴权,以及MN以EAP(响应身份)响应。
MN响应经由AAA基础结构发送到AAAh。AAAh根据MN的身份和基于营运商策略确定EAP/HMIPv6方法适于MN的鉴权和授权(即AAAh知道MN的能力)。AAAh经由AAA基础结构向MN发送建议的EAP方法(例如EAP/HMIPv6)的指示连同询问。EAP方法或方案的指示可以通过为扩展的EAP方案(例如EAP/HMIPv6)指定新的EAP类型编号来实施。这样,移动节点将知道AAAh提出的是哪种EAP方案。备选地,向移动节点发送专门格式化的询问,移动节点识别该询问指示给定的EAP方案。
MN希望引导HMIPv6,并以询问响应以及适当的EAP属性(TLV)来答复AAAh建议和询问,适当的EAP属性(TLV)传送指定适当的MAP的请求连同用于与指定的MAP安全关联的必要信息。在此过程中,MN还可以引导MIPv6,如果先前尚未执行过的话。MN响应经由AAA基础结构发送到AAAh。虽然MAP指定请求实际可以是隐含的,但是一般推荐利用显式的MAP指定请求。对于移动节点已经知道MAP地址并且例如可以只更新与MAP的安全关联的情况,将不会有MAP指定请求,而仅有重新鉴权和/或重新授权。
AAAh验证MN的询问响应,并且如果成功,则这意味着MN是可信的,并且AAAh然后继续处理MN的其他请求。
首先,AAAh在归属网络中选择MAP,并向MAP发送增强的包括例如安全密钥的EAP(注意这是不同于已经在MN和AAAh之间正进行的EAP会话的EAP会话)消息,并且MAP优选地通过提供用于完成与MN的安全关联的信息(如果是需要的或在其他方面是适当的)来对AAAh响应。例如,对于IPSec安全关联,可能需要利用EAP属性,如上表1中定义的IPSec协议、IPSec密码、IPSec密钥有效期EAP TLV属性。
在该说明性示例和以下的说明性示例中,假定移动节点(MN)和AAAh具有公共共享秘密。例如这可能是移动节点中安装的身份模块与归属网络营运商之间共享的对称密钥。身份模块可以是本领域已知的任何防篡改身份模块,包括GSM(全球移动通信系统)移动电话中使用的标准SIM卡、通用SIM(USIM)、还称为WIM的WAP(无线应用协议)SIM、ISIM(IP多媒体子系统身份模块)以及更普遍的UICC(通用集成电路卡)模块。对于MN-MAP(MN-HA)安全关联,可以由MN向AAAh传送种子或现用值(或从相反方向,即由AAAh始发种子并传送到MN),AAAh据此可以基于共享秘密创建MN-MAP(MN-HA)安全密钥。移动节点可以独自生成相同的安全密钥,因为它始发种子/现用值(或从AAAh接收种子)并也具有共享秘密。备选地,AAAh可以自己生成安全信息,并将其安全传送到相关节点。
其次,如果请求MIPv6引导,则AAAh通过使用另一个增强EAP会话选择HA来继续为该MIPv6引导请求服务,并且HA通过提供创建与MN的安全关联所需的信息来响应AAAh。任选地,在鉴权和授权交换中捎带传输“MAP绑定更新”以及“HA绑定更新”是可能的。这意味着HMIPv6绑定集成在与MN-MAP安全关联相同的往返中(在来自移动节点的绑定更新中只需LCoA)。对于此情况,AAAh在与MAP的第一次操作中获得的HMIPv6 RCoA自动是在与HA的第二次操作中更新的MIPv6绑定。
在如上所述AAAh与MAP和HA通信之后,AAAh经由扩展的EAP将授权(和/或配置)信息如MAP地址、RCoA、HA地址、MN归属地址和安全关联信息以及鉴权成功指示发送回MN。图7中交换的额外最后一个往返是为确保根据目前的EAP协议规范平滑实现EAP协议。
图8示出针对MAP位于受访网络时的情况的示范EAP/HMIPv6(直径)信令流。
AAA客户使用EAP(请求身份)请求MN鉴权,以及MN以EAP(响应身份)响应。
MN响应经由AAA基础结构发送到AAAh。AAAh根据MN的身份和基于营运商策略确定EAP/HMIPv6方法适于MN的鉴权和授权(即AAAh知道MN的能力)。AAAh经由AAA基础结构向MN发送建议的EAP方法(即EAP/HMIPv6)的指示连同询问。
MN希望引导HMIPv6,并以询问响应以及适当的EAP属性(例如TLV)来答复AAAh建议和询问,适当的EAP属性传送指定适当的MAP的请求连同用于与指定的MAP安全关联的必要信息。在此过程中,MN还可以引导MIPv6,如果先前尚未执行过的话。MN响应经由AAA基础结构发送到AAAh。
AAAh验证MN的询问响应,并且如果成功,则这意味着MN是可信的,并且AAAh继续处理MN的其他请求。
首先,AAAh将对受访网络中MAP的请求转发到适当的AAAv,这优选地经由直径应用(为简单被称作直径HMIPv6应用)来进行。这样做的原因是,在受访网络中选择MAP时需要考虑受访营运商的策略,并且由此AAAv需要可以查看该事务(在EAP情况下这些交换是端到端的,因此这是不可能的)。AAAv在受访网络中选择MAP,并将含有例如安全密钥的直径HMIPv6应用消息转发到MAP。MAP优选地通过提供用于完成与MN的安全关联的信息(如果是需要的或在其他方面是适当的)来对AAAh响应。其次,如果这样的请求存在,则AAAh通过使用另一个增强EAP会话选择HA来继续为该MIPv6引导请求服务,并且HA通过提供创建与MN的安全关联所需的信息来响应AAAh。注意到,在鉴权和授权交换中捎带传输“MAP绑定更新”以及“HA绑定更新”是可能的。对于此情况,AAAh在与MAP的第一次操作中获得的HMIPv6 RCoA自动是在与HA的第二次操作中更新的MIPv6绑定。
在如上所述AAAh与MAP和HA通信之后,AAAh经由扩展的EAP将授权(和/或配置)信息如MAP地址、RCoA、HA地址、MN归属地址和安全关联信息以及鉴权成功指示发送回MN。图8中交换的额外最后一个往返是为确保根据目前的EAP协议规范平滑实现EAP协议。
虽然一些详细示范实施例主要是参考目前的EAP版本来讨论,但是应该理解,本发明非常适用于其他EAP版本,如EAPv2,以及以所述方式扩展或配置的其他鉴权协议。EAP仅仅是可能的实施方式的示例,并且本发明一般不局限于此,而是可以备选地涉及非EAP方案。
HMIPv6的AAA框架协议应用
在另一个示范实施例中,创建一种新的AAA框架协议应用,本文以适合HMIPv6的直径应用(称为“直径HMIPv6应用”)为例,它承载便于例如发现MAP、动态分配MAP、动态分配RCoA、MN和MAP之间分发安全密钥和/或可能的捎带传输HMIPv6移动性过程的HMIPv6相关信息。虽然下文涉及的是直径,但是应该理解,还可以使用RADIUS或其他类似的AAA框架协议来作为新的或扩展的HMIPv6应用的基础。
如果希望的话,HMIPv6和MIPv6鉴权和/或授权可以集成在相同的AAA框架协议应用中。这可以通过采用[3]中所述的直径MIPv6应用以及另外还定义新的HMIP特定的命令代码、AVP和/或标志来实现。通过将直径MIPv6应用的命令代码、AVP和标志作为直径HMIPv6应用的一部分包括,将MIPv6和HMIPv6鉴权和/或授权的同时执行容纳于允许更短建立时间的单个遍历中。在没有MIPv6鉴权和/或授权的情况下仅执行HMIPv6鉴权和/或授权也是可能的,且反之亦然,具体取决于特定情况下MN的具体需求。这使单个应用(直径HMIPv6应用)可以灵活地在各种用例场合使用。
再者,在直径HMIPv6应用中捎带传输HMIPv6移动性过程使得可能通过在公共过程中优化鉴权、授权和移动性来缩短整个建立时间。
直径HMIPv6应用的详细信息
在下文中,提供示范直径HMIPv6应用的详细信息,以说明整体流程的示例和概念的可行性。优选地,定义新的HMIP特定的命令代码、AVP和/或标志,它们承载便于例如发现MAP、动态分配MAP、动态分配RCoA、MN和MAP之间分发安全密钥和/或可能的捎带传输HMIPv6移动性过程的信息。直径MIPv6应用[3]的命令代码、AVP和标志可以任选地作为直径HMIPv6应用的一部分包括。
下表2中给出直径HMIPv6应用命令代码和AVP的示范概括矩阵:
直径HMIPv6应用命令代码和AVP |
源 |
目的地 |
目的 |
注释 |
HMIPv6特定的命令代码: |
|
|
|
|
MAP-HMIPv6-请求命令(MAR)MAP-HMIPv6-应答命令(MAA) |
AAAhAAAhMAPMAP |
MAPMAP经AAAvAAAhAAAh经AAAv |
HMIP AVP的交换HMIP AVP的交换HMIP AVP的交换HMIP AVP的交换 |
MAP位于归属网络MAP位于受访网络MAP位于归属网络MAP位于受访网络 |
HMIPv6特定的AVP:HMIP-绑定-更新AVPHMIP-绑定-确认AVPRCoA AVPMAP地址AVPHMIPv6-特征-矢量AVPMAP-请求的标志MAP-MN预共享密钥生成现用值AVPMAP-MN预共享密钥AVPMAP IKE KeyID AVPMAP-MN IPSec SPI AVPMAP-MN IPSec协议AVPMAP-MN IPSec密码AVPMAP-MN IPSec密钥有效期AVP |
|
|
由MN发送到MAP的HMIP绑定更新消息由MAP发送到MN的HMIP绑定确认RCoAMAP地址对动态MAP指定的请求MN-MAP密钥的种子指定MN-MAP密钥指定IKE KeyID指定SPI指定IPSec协议指定IPSec密码指定IPSec密钥有效期 |
|
现有的直径MIPv6应用命令代码:AA-登记-请求命令(ARR)AA-登记-应答命令(ARA)归属-代理-MIPv6-请求命令(HOR)归属-代理-MIPv6应答命令(HOA) |
AAA客户AAAhAAAhHA |
AAAh(经AAAv)AAA客户(经AAAv)HAAAAh |
|
|
现有的直径MIPv6应用AVP:MIP-绑定-更新AVPMIP绑定-确认-AVPMIPv6-移动-节点-地址AVPMIPv6-归属-代理-地址AVPMIPv6-特征-矢量AVP归属-代理-请求的标志 |
|
|
由MN发送到HA的移动IP绑定更新消息由HA发送到MN的移动IP绑定确认移动节点的归属地址移动节点的归属代理地址对动态归属代理指定的请求 |
|
对于附加信息,因特网草案[5]定义了在网络接入服务器(NAS)与后端鉴权服务器之间承载EAP分组所需的命令代码和AVP。
直径HMIPv6应用的示范信令流
图9示出针对MAP位于归属网络时的情况的示范直径HMIPv6应用信令流。
AAA客户经由例如因特网控制消息协议(ICMP)、PANA等的协议向要鉴权的MN发布询问。MN以询问响应以及HMIPv6可能还有MIPv6引导请求来响应。
AAA客户理解HMIPv6和MIPv6引导请求,并使用直径HMIPv6应用命令代码(ARR)经由AAA基础结构将MN响应转发到AAAh。在该过程中,AAA客户还包括使AAAh可以检验MN的可信性的询问。
AAAh验证MN的询问响应,并且如果成功,则这意味着MN是可信的,并且AAAh然后继续处理MN的其他请求。
首先,AAAh在归属网络中选择MAP,并将含有例如安全密钥的适当的直径HMIPv6应用命令代码(MAR)发送到MAP,并且MAP经由命令代码(MAA)优选地通过提供用于完成与MN的安全关联的信息(如果是需要的或在其他方面是适当的)来对AAAh响应。其次,如果请求MIPv6引导,则AAAh通过使用直径HMIPv6应用命令代码((HOR))选择HA来继续为该MIPv6引导请求服务,并且HA经由命令代码(HOA)通过提供创建与MN的安全关联所需的信息来响应AAAh。注意到,在鉴权和授权交换中捎带传输“MAP绑定更新”以及“HA绑定更新”是可能的。对于此情况,AAAh在与MAP的第一次操作中获得的HMIPv6 RCoA自动是在与HA的第二次操作中更新的MIPv6绑定。
在如上所述AAAh与MAP和HA通信之后,AAAh经由直径HMIPv6应用命令代码(ARA)和例如ICMP、PANA等将授权(和/或配置)信息如MAP地址、RCoA、HA地址、MN归属地址和安全关联信息以及鉴权成功指示发送回MN。
图10示出针对MAP位于受访网络时的情况的示范直径HMIPv6应用信令流。
AAA客户经由例如ICMP或PANA向要鉴权的MN发布询问。MN以询问响应以及HMIPv6可能还有MIPv6引导请求来响应。
AAA客户理解HMIPv6和MIPv6引导请求,并使用直径HMIPv6应用命令代码(ARR)经由AAA基础结构将MN响应转发到AAAh。在该过程中,AAA客户还包括使AAAh可以检验MN的可信性的询问。
AAAh验证MN的询问响应,并且如果成功,则这意味着MN是可信的,并且AAAh然后继续处理MN的其他请求。
首先,AAAh将对受访网络中MAP的请求转发到适当的AAAv,这优选地经由直径HMIPv6应用命令代码(MAR)来进行。AAAv在受访网络中选择MAP,并将包括例如安全密钥的命令代码(MAR)转发到MAP,并且MAP优选地使用命令代码(MAA)通过提供用于完成与MN的安全关联的信息(如果是需要的或在其他方面是适当的)来经由AAAv对AAAh响应。其次,如果被请求,则AAAh通过使用直径HMIPv6应用命令代码(HOR)选择HA来继续为该MIPv6引导请求服务,并且HA经由命令代码(HOA)通过提供创建与MN的安全关联所需的信息来响应AAAh。注意到,在鉴权和授权交换中捎带传输“MAP绑定更新”以及“HA绑定更新”是可能的。对于此情况,AAAh在与MAP的第一次操作中获得的HMIPv6RCoA自动是在与HA的第二次操作中更新的MIPv6绑定。
在如上所述AAAh与MAP和HA通信之后,AAAh经由直径HMIPv6应用命令代码(ARA)和例如ICMP或PANA的协议将授权(和/或配置)信息如MAP地址、RCoA、HA地址、MN归属地址和安全关联信息以及鉴权成功指示发送回MN。
概括上述一些方面,可以看出,对AAA基础结构的依赖提供了用于引导HMIPv6业务的若干可能性。例如,可能的是,提供对通过AAA基础结构承载的普通鉴权协议(如目前或将来的EAP版本)的扩展和/或增强AAA框架协议应用,如直径和RADIUS应用。
图11是用于支持移动节点的HMIPv6业务的方法的基本示例的示意流程图。在该示例中,步骤S1-S4所示的信息传送和操作涉及移动节点的鉴权(S1)、MN-MAP安全关联的建立(S2)、HMIPv6配置(S3)和HMIPv6绑定(S4)。步骤S2-S3通称为授权阶段。如果希望的话,可以或多或少以并行方式执行步骤S1-S4,例如在与HMIPv6安全关联过程相同的往返中捎带传输HMIPv6绑定,以可以缩短整个建立时间。在步骤S1,通过AAA基础结构传送信息,以在归属网络端对移动节点鉴权。在步骤S2,传送HMIPv6相关信息,以立即建立或允许将来建立MN和MAP之间的安全关联。在步骤S3中,执行附加的HMIPv6配置,例如通过向移动节点传送配置参数以在其中进行适合的存储。在步骤S4,移动节点发送绑定更新,并在MAP中建立HMIPv6绑定。
在其他应用领域中,本发明可应用于诸如WLAN、CDMA2000、WCDMA等的所有接入网,其中可以使用HMIPv6以及任选地还有MIPv6,包括诸如AAA和IPv6移动性的技术、诸如CMS11、WCDMA和GSM系统的系统、诸如服务/应用子系统和终端的子系统以及诸如AAA服务器、归属代理服务器和终端节点的产品。
作为上述MN-HA密钥分发的示例过程的备选方式,与目前的3GPP2解决方案类似的机制结合IKE框架可以用于分发MN和HA的动态预共享密钥。
上述实施例仅是作为示例给出,并且应该理解,本发明并不局限于此。而且保留本文公开的和要求保护的基本基础原理的其他修改、更改和改进都属于本发明的范围。
[1]“IPv6中的移动性支持(Mobility Support in IPv6)”,D.Johnson,C.Perkins,J.Arkko,2003年6月30日,<draft-ietf-mobileip-ipv6-24.txt>。
[2]“分级移动IPv6移动性管理(Hierarchical Mobile IPv6 mobilitymanagement)(HMIPv6)”,Hesham Soliman,Claude Castelluccia,Karim El-Malki,Ludovic Bellier,2003年6月,<draft-ietf-mobileip-hmipv6-08.txt>。
[3]“直径移动Ipv6应用(Diameter Mobile IPv6 Application)”,Stefano M.Faccin,Franck Le,Basavaraj Patil,Charles E.Perkins,2003年4月,<draft-le-aaa-diameter-mobileipv6-03.txt>。
[4]“基于EAP的MIPv6授权和配置(MIPv6 Authorization andConfiguration based on EAP)”,G.Giaretta,I.Guardini,E.Demaria,2004年2月,<draft-giaretta-mip6-authorization-eap-00.txt>。
[5]“直径可扩展鉴权协议(Diameter Extensible AuthenticationProtocol)(EAP)应用”,P.Eronen,T.Hiller,G.Zorn,2004年2月16日,<draft-ietf-aaa-eap-04.txt>。
[6]“PPP可扩展鉴权协议(PPP Extensible AuthenticationProtocol)(EAP)”,RFC2284,L.Blunk,J.Vollbrecht,1998年3月。
[8]“因特网安全关联和密钥管理协议(Internet SecurityAssociation and Key Management Protocol)(ISAKMP)”,RFC2408,D.Maughan,M.Schertler,M.Schneider,J.Turner,1998年11月。
[9]“直径移动IPv4应用(Diameter Mobile IPv4 Application)”,P.Calhoun,T.Johansson,C.Perkins,2003,<draft-ietf-aaa-diameter-mobileip-14.txt>。
[10]“远程鉴权拨号用户服务(Remote Authentication Dial In UserService)(RADIUS)”-RFC2865,C.Rigney,S.Willens,A.Rubens,W.Simpson,2000年6月。
[12]“可扩展鉴权协议(Extensible Authentication Protocol)(EAP)”-RFC2284,L.Blunk,J.Vollbrecht,B.Aboba,J.Carlson,H.Levkowetz,2003年9月,<draft-ietf-eap-rfc2284bis-06.txt>。
[13]“EAP对等和鉴权者的状态机器(State Machines for EAP Peerand Authenticator)”,J.Vollbrecht,P.Eronen,N.Petroni,Y.Ohba,2003年10月<draf-ietf-eap-statemachine-01.pdf>。