WO2008043319A1

WO2008043319A1 - Mobile ip key bootsrapping system and method

Info

Publication number: WO2008043319A1
Application number: PCT/CN2007/070879
Authority: WO
Inventors: Nakhjiri Madjid F.; Frank Li; Lucas Pan
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-10-11
Filing date: 2007-10-11
Publication date: 2008-04-17

Abstract

A system and a method of transferring key for mobile IP bootstrapping are disclosed. The method includes: performing Extensile Authentication Protocol (EAP) authentication between a mobile node and an Authentication, Authorization, and Accounting (AAA) server via an EAP authenticator; and sending a pre-shared key via the AAA server to a mobile IP home agent, wherein the home agent is different from the EAP authenticator.

Description

Mobile IP Key Bootstrapping System and Method

Field of the Invention

The present invention relates to Mobile IPv6 Authorization and Security, further concerns a system and method for implementing Mobile IP Key Bootstrapping.

Background of the Invention

Mobile IPv6 requires establishment of an ΪPsec security association (SA) between the Mobile Node (MN) and the Home Agent (HA) to protect the Mobile IPv6 signaling, for example, binding updates for mapping of MN home address (HoA) and care of address (CoA). Mobile IPv6 Security is guaranteed through MN-HA IPsec. Reference is made to Fig. I . However, typically two parties interested in establishing an IPsec SA perform an Internet Key exchange (IKE) first to be able to negotiate the keys and other properties of the IPsec SA. That is, ΪPsec needs IKE. IKE includes a mutual authentication between the two parties and this mutual authentication can be done in many different ways. However, the most desired method is one based on a pre-shared secret between the two IKE parties (in this case MN and HA) That is, MN-HA IKE needs pre-shared secret, e.g., a pre-shared key between MN and HA (MN-HA-PSK). Configuration of this pre-shared secret may be done statically and manually. However, since both the MN home address (HoA) and the HA itself may be dynamically assigned (through what is called '"the bootstrapping process") by the mobility service provider (MSP), it is desirable to have the pre-shared secret (e.g., MN-HA-PSK) established as part of the bootstrapping process as well. In most of the networks, the AAA server is the main source of trust and user profile information. Therefore, the bootstrapping is done through the AAA server. As to Mobile IPv6 Authorization, it has been suggested in such as IETF Mobile IPv6 WG that the MN performs an Extensible Authentication Protocol (EAP) authentication with the AAA server through the HA, and the HA acts as the EAP authenticator.

Specially, Fig. 2 shows a flowchart of 1KEV2 which is one of IETF solutions in the prior art, At block 201 , an EAP mutual authentication is carried out between the

MN and the AAA server, and at block 202 the MN and the AAA server create EAP Master Session Key (MSK), i.e., MN-HA-PSK. Thereafter, the AAA server sends the MN-HA-PSK to the HA at block 203, and the HA and the MN start IKE to establish IPsec at block 204.

However, it is required in the current solution, such as IKEv2, that the HA must act as an EAP authenticator, which may cause serious limitations as follows.

1 ) In an integrated scenario, where both access and mobility service are provided by the same operator and authorized by the same AAA server, the IETF has required the HA to act as the EAP authenticator, while the E.AP authenticator function is typically inserted inside inexpensive entities in charge of access control (e.g. network- access server, NAS). The IETF requirement not only makes the HA more complicated (must perform EAP authenticator and many other network access functions) but also puts limitations on how a group of NASes can be deployed, since now the NAS and HA are combined. The HA must act as an EAP authenticator in the current solution, which may add complexity to the HA.

2} In a split scenario, where access is provided by access service provider (ASP), that is different from the mobility service provider (MSP), this still causes limitation, since in a mobility service provider network, it may be desired to have more security- oriented edge devices (such as VPN gateways, or other types of gateways) to act as EAP authenticator and keep the HA either physically or logically separate.

Summary, Embodiments of the present invention propose solutions for mobile IP key bootstrapping and key transmission for mobile IP bootstrapping.

A system includes: a mobile IP home agent; and a mobile node in communications with the home agent; wherein a pre-shared key is bootstrapped between the home agent and the mobile node, with mobile node using Extensile Authentication Protocol (EAP) without requiring the home agent to have any EAP authenticator functionality.

A system of transferring key for mobile IP bootstrapping includes: an Extensile Authentication Protocol (EAP) authenticator, a mobile IP home agent, a mobile node in communications with the home agent and the BAP authenticates and an Authentication, Authorization, and Accounting (AAA) server, for providing a pre-shared key to the home agent, wherein the BAP authentieator is different from the home agent.

A method of transferring key for mobile IP bootstrapping includes. performing Extensile Authentication Protocol (EAP) authentication between a mobile node and an Authentication, Authorization, and Accounting (AAA) server via an EAP authenticate)?; and sending a pre-shared key via the AAA server to a mobile IP home agent, wherein the home agent is different from the EAP authentieator.

Therefore, the EAP authentieator function is separated from the HA function in the embodiments of the present invention, so that both the HA design and the network topology design (layout of network edge entities) can be done more simply and flexibly. On the other hand, EAP authentication and key management framework typically allows for sending the keys from the EAP/AAA server only to the EAP authentieator and therefore some signaling arrangements needs to be done for the transfer of keys to an EAP-off-path entity such as HA.

Br|ef Descri|itiθR_Lθf the_LLPrawϊπ_Lgs

Fig. 1 illustrates Mobile IPv6 Authorization and Security in the prior art.

Fig 2 illustrates a flowchart of iKEv2 in the prior art.

Fig. 3 illustrates an architecture of the network according to embodiments of the present invention.

Fig. 4 illustrates a preferred method for transferring pre-shared key according to the present invention

Fig. 5 illustrates flowchart of providing HA information from the MN to the AAA server Embodiments of the Invention

In embodiments of the invention, bootstrapping of a pre-shared key (MN-HA- PSK) Is allowed between a mobile node (MN) and a Mobile TP (especially Mobile IPv6) home agent (HA), using Extensible Authentication Protocol (EAP) without 5 requiring the HA to include EAP aυthenticator functionality. Here, without requiring the HA to include EAP authenticate!" functionality can be understood as, for example, not to combine the HA to an EAP authenticator. In this way, the network edge entity (such as NAS, VPN gateway, etc.) can act as an EAP authenticator during an EAP authentication with the AAA serv er and then request the AAA server to send the MN- 10 HA-PSK to the HA The architecture of the network according to embodiments of the present invention is illustrated in Fig.3. The messaging and procedures in the embodiments of the invention include:

1 ) The NAS sending an indication (AAA attribute- "MAS NOT HA") to the AAA server that it is not the HA and the MN-HA-PSK is to be sent to an HA, This

1 5 procedure will be thoroughly described with reference to Fig.4.

2) In case the NAS knows the HA, the NAS sending the HA identifier (HA ID) to the AAA server. This procedure will be described with reference to Fig.5.

3) In case the MN knows the HA, and the MN performs a combined access and mobility service request, the MN sends the MN HA PSK request and HA identifier 20 through layer 2 messaging. The access and mobility service request is for IKE negotiation. This procedure will be described with reference to Fig.5.

In order to allow the EAP authenticator and the HA to be two different logical or even physical entities, the AAA server needs to be notified that the HA is not the EAP authenticator, so that the AAA does not send the keys resulted from EAP 25 authentication (in this case MN-HA-PSK) to the EAP authenticator. For this we propose the NAS/ EAP authenticator to send an indication that it is not the HA to the AAA server. Since EAP messaging between the EAf* authenticator and the AAA server is typically carried over an AAA protocol, the indication can be sent to the AAA server via an AAA attribute ("NASJNOTJW). Then, the AAA server may 33 send the MN-HA-PSK to the HA according to instruction of the indication, instead of to the NAS/ EAP authenticates, hi the procedure, the HA has no need to anticipate in the HAP authentication as the prior art does, i.e , the HA is off the EAP path

Moreover, if the NAS is aware of HA information, such as the HA iP address, the HA ID or other identifiers, the NAS can send the HA iD to the AAA server as part of a different or the same attribute as the "NAS NOT HA" identification. The NAS may have the HA information pre-configured or receive the information from the MN as part of layer 2 or layer 3 signaling The MN indication of the HA information within the Mobile IP signaling is well -known, however, in cases of integrated bootstrapping, where both access and mobility services are requested at the same time, the MN could include the HA information as well as the MN-HA-PSK request within layer 2 signaling (TLV in MAC layer) instead of waiting for layer 3 signaling to bootstrap its Mobile IPv6 operation information If the NAS is unaware of HA ID, or if the NAS has not sent the HA ID to the AAA sener, the AAA server will simply assign a HA to the MN (bootstrapping) and based on the '^VNAS NOT HA" identification, the AAA sener sends the MN-HA-FSK to the HA assigned by itself directly.

In the following, reference is made to Fig.4, which is a flowchart illustrating a preferred method for transferring pre-shared key according to the present invention.

At block 401 , during EAP mutual authentication between the MN and the AAA server, the EAP authenticator sends an indication to the AAA server to notify it is not the HA.

It should be noted that the Ii-AP is performed as usual at block 401 except that an indication is sent to the AAA server. In one embodiment of the invention, the EAP authenticator is a NAS that only supports Diameter HAP application. For integrated scenario, same EAP is used for both access and mobility service; for split scenario, another node may need to act as Authenticator instead of the HA

At block 402, the AAA server creates the MN-HA-PSK The process shown in block 402 is similar to that of the prior an. At block 403, the AAA server sends MN- HA-PSK to the HA according to the indication sent from the EAP authenticator, At block 404, the HA and the MN start IKE to establish ΪPsec. Additionally, Fig.5 shows a flowchart of providing HA information from the MN to the AAA server. The HA information may be the HA IP address, the HA ID or other identifiers.

At block 501.. the MN may include an HA information option either to an EAP signaling extension, such as an EAP response, or in L2 messaging, if the MN knows which HA it belongs, i.e., the MN has the HA ID. At block 502, the MAS receives the HA ID from the MN, generates an AAA attribute including the HA ID, and sends the AAA attribute to the AAA server. At block 503, the AAA server sends the MN-HA- PSK to the HA with the HA ID.

In another case, neither the MN nor the NAS has the HA ID. Therefore, the AAA server has to perform a dynamic AAA-based HA allocation. Then, at block 403, the AAA server could know which HA it may send the MN-HA-PSK to, and send the MN-HA-PSK to the HA with the HA ID. After that, the AAA server may provide the

HA ID to the MN, and this process is similar to the prior art.

In another embodiment, a method for transferring pre-shared key according to the present invention is provided.

The EAP mutual authentication between the MN and the AAA server is performed as usual, and the AAA server creates the MN-HA-PSK. In this embodiment, the EAP authenticator does not send the indication Before sending out the MN-HA-PSK., the AAA server determines which HA the MN belongs to, and sends the MN-HA-PSK to the exact HA. When determining the HA of the MN, the AAA server may rely on HA information sent from the HAP authenticator. In another way, the AAA server may perform a dynamic AAA-based HA allocation, i.e., the AAA server may assign an HA for the MN, and send the MN-HA-PSK to the HA. Certainly, the AAA server may inform the MN of the new allocated HA in this case.

Moreover., a system is provided in an embodiment of the present invention. The system includes a mobile iP home agent, and a mobile node in communications with the home agent, wherein a pre-shared key is bootstrapped between the home agent and the mobile node, with mobile node using Extensile Authentication Protocol (EAP) without requiring the home agent to have any EAP authenticator functionality. Conclusively, some of the unique aspects of the embodiments of the present invention are listed heieinafter

1) Reducing the requirement for implementation of EAP aufhenticator within the Mobile IPv6 HA In this way, the collocation of HAs may be independent with that of

5 NASes Therefore, the HAs are not restricted to the place where network edge entities, such as NASes locate. Further, this also makes design of the path for EAP and AAA signaling more flexible

2) The idea of sending a generic application key derived from the EAP authentication method (in this case the application kex is for Mobile IP: MN-HA-PSK)

10 to an application agent that is not EAP authenticator (in this case HA ).

3) Inclusion of HA information and MN-HA-PSK request within L2 signaling frorn die MK (as L2 signaling extension) Note that this can take different forms depending on the L2 access technology in use.

4) inclusion of the indications such as "N A SJN OT _H A" and HA ΪD within the 15 AAA signaling between the NAS EAP authcnticator and the AAA server

Draft-nakhjiri~eap-ho~00. June 2005, is incorporated herein by reference The idea of sending Leys to an entity that is not FA P authenticator has been discussed earlier through an !ETF Internet draft (draft-nakhjiri-eap-ho-OO. June 200S) However, the purpose of that draft is providing the keys for base stations through a local key 20 distribution center, not Mobile IP signaling furthermore, the draft specifically talks about sending the AΛA-key (a specific key resulting from (¹AP authentication), not a generic key (such as MN- HA-PSK) from EΛP authentication to an application agent that is not FAP authenticator The AAA Key is used foi deming other keys, uhile the MN-HA-PSK is used for guaranteeing communications between the MN and the HA 25 Furtheimore, the draft does not include any I 2 signaling from the MN

While a number of prof ei red embodiments of the invention ha\ e been shown and described herein, modifications thereof may be made by one skilled in the art without departing from the spirit and the teachings of the i m ention The embodiments described herein are exemplary only and are not intended to be limiting Many 30 variations, combinations, and modifications of the invention disclosed herein arc possible and are within the scope of the invention Accordingly, the scope of protection is not limited by the description set out above, but is defined by the claims whicc follow, that scope including all equivalents of the subject matter of the claims.

Claims

1 A system comprising a mobile IP home agent, and a mobile node in communications with the home agent, wherein a pie-shared key is bootstrapped between the home agent and the mobile node, with mobile node using Extensile Authentication Protocol (EAP) without requiring the home agent to have any EAP authenticator functionality

2 A system of transferring key for mobile IP bootstrapping, comprising an Extensile Authentication Protocol (EAP) authenticator, a mobile IP home assent, a mobile node in com muni cations with the home aticnt and the FAP authenticator. and an Authentication, Authorization, and Accounting (AAA) server, for providing a pre-shared key to the home agent, wherein the HΛP authenticator is different from the home agent 3 The svstem according to claim 2. wherein the EAP authenticator is a network edge entity

4 A method of transferring ke\ for mobile IP bootstrapping, comprising performing Extensile Authentication Protocol (EAP) authentication between a mobile node and an Authentication, Authorization, and Accounting (AA A) server via an BAP authenticator, and sending a prc-shared key via the AAA server to a mobile IP home agent, wherein the home agent is different from the FΛP authenticator

5 Che method according to claim 4. further comprising sending, from the EΛP authenticator. an indication to notify the AΛA server that the ϊv\P authenticator is not the home agent, and said sending a pre-shared key v ia the AAA server to a mobile IP home agent comprises sending a pre-shared ke\ via the AAA server to a mobile TP home agent according to the indication o The method according to claim 5. further comprising sending, from the mobile node, information of a home agent to which the mobile node belongs to the EAP autbenticator; sending, from the EAP authenticator, the information of the home agent to the AAA server; and said sending a pre-shared key via the AAA server to a mobile IP home agent comprises: sending a pre-shared key via the AAA server to a mobile IP home agent with the information of the home agent sent from the EAP authenticator.

7. The method according to claim 6, wherein the information of the home agent comprises home agent identifier, or home agent ΪP address. 8. The method according to claim 5, further comprising: allocating, by the AAA server, the mobile IP home agent for the mobile node before sending the pre-shared key.

9. The method according to claim 4, further comprising: determining, by the AAA server, the mobile IP home agent to which the mobile node belongs before sending the pre-shared key

10. The method according to claim 9, further comprising: sending, from the mobile node, information of a home agent to which the mobile node belongs to the EAP aυthenticator; sending, from the EAP authenticator, the information of the home agent to the AAA server; and said determining, by the AAA server, the mobile IP home agent to which the mobile node belongs comprises: determining, by the AAA server, the mobile IP home agent to which the mobile node belongs according to the information of the home agent sent from the KAP authenticator I L The method according to claim 9, further comprising: allocating, by the AAA server, the mobile IP home agent for the mobile node before sending the pre-shared key.