Method and apparatus for combining internet protocol authentication and mobility signaling

The present invention relates to a wireless network. More specifically, the present invention relates to optimization of Internet Protocol layer authentication and security of mobility signaling in wireless networks.

The evolution of the 3rd generation (3G) is currently being specified in the 3rd generation partnership project (3GPP). The idea of reliable non-3GPP access would be to have the home AAA server perform link layer subscriber authentication. (Non-3GPP access is defined as any access other than GERAN / UTRAN / EUTRAN.) Authentication for non-3GPP access is done by the first authentication on the link layer. This is, for example, the Extensible Authentication Protocol for UMTSAKA (UMTS Authentication and Key Agreement), which requires several round trips. Method) (EAP / AKA) is applied. An access router (AR) in a trusted access network is typically the path through the authentication device in EAP / AKA operation. This is followed by another authentication on the IP layer between the mobile node (MN) and the mobile IP home agent (HA) located inside the packet data network gateway (PDNGW). PDNGW is also an anchor point for 3GPP access. IP layer authentication also results in the security parameters and keys needed to ensure the security of mobility signaling. As a result, IP layer authentication will add latency to link layer authentication.

Especially in the situation of handover, the delay is a decisive factor for the real-time application, and it is useless to operate the two authentications. The authentication process for non-3GPP access is clearly inefficient, resulting in the operation of multiple authentication protocols.

The Proxy Mobile IPv6 (PMIPv6) protocol has been proposed to be used as a network-led mobility protocol in System Architecture Evolution-Long-Term Evolution (SAE / LTE). The proposal states that the protocol operates on the S5 interface (between PDNGW and S-GW) reference point and the S8b interface (between PDNGW and destination S-GW) reference point (3GPP TS23.401). reference).

PMIPv6 causes the mobile access gateway (MAG) to advertise a 64-bit home prefix to the mobile node (MN), and MN believes that MN is still connected to the home network, resulting in MN himself. It is based on having you keep your home address. MAG is located inside the access router (AR). At the same time, MAG sends a PBU (Proxy Binding Update) to MN's HA, requesting a bond between the MN's home address (HoA) and the MAG's exit interface address (ie, the MAG's exit interface is It will act as a Care of Addess (CoA).

MAG obtains the HA address of MN, the home prefix of MN, and the type of address configuration, either during or after successful link layer authentication.

Compared to standard mobile IP, this has the advantage of keeping the MN unaware of mobility events and does not require a clear security connection between the MN and its HA (this). Is currently managed by MAG and assumes that the link between HA and MAG is guaranteed to be secure).

For more information on PMIPv6, see www.ietf.org/internet-drafts/draft-ietf-netlmm-proxy-mobileipv6-17.txt.

For example, in WLAN, when multiple terminals share the same access link, all terminals on the link see each other's packets. And those packets are, in a sense, transmitted directly between the terminals. This has several implications for security. Below we assume IPv6.

When a terminal first appears on a link, it will send a router solicitation message (RtSol). You would then expect a router advertisement (RtAdv) response from the access router (AR). RtAdv contains an address prefix that the terminal should use to set its own IP address. An attacker on the link could exploit a router advertisement in response to a router solicitation message.

If the terminal receives a router advertisement and sets its IP address, it is likely that the terminal will send an address duplication detection message containing that IP address over the link. If this address has already been used by someone else on the link, the terminal will have to generate a new address and perform the address duplication detection procedure again. Again, an attacker on the same link can respond to all address replication detection messages sent over the link, effectively denying service to all other terminals.

A terminal that wants to send a packet to another terminal on the same link needs to resolve its IP address to a link layer address. This is done by the terminal asking on the link a link layer address that belongs to a particular IP address. The protocol used is intended that only the true owner of the IP address will respond. But obviously, any attacker can respond to this query.

These messages are part of the Neighbor Discovery Protocol (see RFC2461 and RFC2462). To address the attacks mentioned above, the IETF has specified a Secure Neighbor Discovery (SEND) protocol. This protocol is based on public key cryptography, where the address (CGA: Criptographically Generated Address) is tied to a private / public key pair and all messages involved in address management are digitally signed. ..

CGA generation is a little overloaded. Signing all address management messages imposes a considerable processing load on both the terminal and the access router. If signatures and certificates need to be added, the message size will increase significantly. Verification of revoked certificates requires additional round trips, imposing a burden on both the terminal and the access router.

<p> It would be advantageous to have a system and method for combining Internet Protocol authentication and mobility signaling. The present invention provides these systems and methods.</p>

<p> Describes methods and devices for combining Internet Protocol layer authentication and mobility signaling using a packet data network gateway. In one embodiment, the master key and the first interface identifier are received. The router request and the second interface identifier are received. Here, the first interface identifier and the second interface identifier are the same. The integrity of the router request is confirmed by the master key, the first interface identifier, and the second interface identifier.</p><p> Describes methods and devices for combining Internet Protocol layer authentication and mobility signaling using a packet data network gateway. The stored master key is retrieved using the first interface identifier. A new interface identifier is generated. A roaming key is generated from the master key. Roaming keys and router ads are forwarded.</p><p> Describes methods and devices for combining Internet Protocol layer authentication and mobility signaling using access routers. A message with a roaming key and a router advertisement is received. Router ads are integrity protected using the first key. The roaming key is extracted from the message. The message is forwarded.</p><p> Describes methods and devices for combining Internet Protocol layer authentication and mobility signaling using access routers. A router solicitation message with integrity protection is received. If an unverifiable authentication option is detected in the packet, the router solicitation message is tunneled to the packet data network gateway.</p><p> Describes methods and devices for combining Internet Protocol layer authentication and mobility signaling using mobile nodes. The master key is established. The mobile node moves from the first access network to the second access network. The first key is derived from the master key. Router solicitation messages are integrity protected using the first key. The router solicitation message is tunneled along with the interface identifier.</p><p> Describes methods and devices for combining Internet Protocol layer authentication and mobility signaling using mobile nodes. You will receive a router advertisement with integrity protection using the first key. The integrity of router advertisements is determined using the first key. Subsequent Router Advertising messages are received. Each subsequent router advertising message is integrity protected using a roaming key.</p><p> An object of the present invention is to reduce latency in handover. In particular, one purpose is to combine IP layer authentication and mobility signaling on one of the round trips.</p><p> Another purpose is to provide a method for transferring keys between a packet data network gateway and a mobile access gateway that can also be derived by a mobile node.</p><p> Yet another purpose is to protect router advertisements and Neighbor Discovery Protocol messages without CGA (Criptographically Generated Address) and common public key manipulation. This is to provide the benefits of the SeND (Secure Neighbor Discovery) protocol over shared links.</p><p> In the next section, the present invention will be described with reference to the typical embodiments shown in the figure.</p>

<figref num="1">It is a figure which shows the system according to one Embodiment of this invention.</figref><figref num="2">It is a figure which shows the system according to one Embodiment of this invention.</figref><figref num="3">FIG. 5 illustrates a method for synthesizing Internet Protocol layer authentication and mobility signaling using a packet data network gateway according to one embodiment of the present invention.</figref><figref num="4">FIG. 5 illustrates a method for synthesizing Internet Protocol layer authentication and mobility signaling using a packet data network gateway according to one embodiment of the present invention.</figref><figref num="5">FIG. 5 illustrates a method for synthesizing Internet Protocol layer authentication and mobility signaling using an access router according to one embodiment of the present invention.</figref><figref num="6">FIG. 5 illustrates a method for synthesizing Internet Protocol layer authentication and mobility signaling using an access router according to one embodiment of the present invention.</figref><figref num="7">FIG. 5 illustrates a method for synthesizing Internet Protocol layer authentication and mobility signaling using mobile nodes according to one embodiment of the invention.</figref><figref num="8">FIG. 5 illustrates a method 800 for synthesizing Internet Protocol layer authentication and mobility signaling using mobile nodes according to one embodiment of the invention.</figref>

The present invention aims at optimizing the security of IP layer authentication and mobility signaling. The invention also applies a combined approach that provides network-based mobility, enhanced secure Neighbor Discovery (SeND), and high-speed Internet Protocol (IP) layer authentication. These three features are crucial to enable successful deployment of 3GPP access networks and non-3GPP access networks, where there is a need for security between different types of network access technologies. Fast roaming is of great value. The present invention utilizes trust between nodes in an access network to generate a master key (Ka), which is then used to generate one or more different roaming keys. It generates and sends those roaming keys to the corresponding node with guaranteed security. However, the master key is not used directly and other keys are derived from this master key. One key is used for network connectivity, authentication, and network mobility, while the other key, called a roaming key, has similar purposes to secure Neighbor Discovery and, potentially, a network-based MIPv6 route. Used to enable optimization (RO) mode.

FIG. 1 shows a system 100 with a first access network (eg, 3GPP access based on SAE / LTE) and a second access network (eg, non-3GPP access). In this embodiment, mobile node 120 moves from access network # 1 (eg EUTRA) to access network # 2 (eg non-3GPP access). EUTRA has multiple eNB 115s. Multiple eNB 115s are connected to the movement management entity (MME) 110. The MME110 is connected to the Packet Data Network Gateway (PDNG) 105. Non-3GPP access includes multiple access points (APs) 130. AP130 is connected to AR / MAG125. AR / MAG125 is also connected to PDNGW105.

The following description also assumes that PDNGW105 is the home agent (HA) of MN120. The following description typically assumes that the MN120 connects to EUTRAN first and then performs an inter-RAT handover to non-3GPP access. However, it should be understood that the access used in the initial connection may be any access that generates key material as part of the authentication process.

Figure 2 shows a non-roaming architecture for non-3GPP access within SAE (System Architecture Evolution). This architecture includes General Packet Radio Service (GPRS) Support Node (SGSN) 205, MME210, EUTRAN215, Home Subscriber Server (HSS) 220, Serviced SAE Gateway 225, PDN SAE Gateway 230, Policy. Change Rule Function Department (PCRF) 235, Operator IP Service 240, 3GPP AAA Server 245, Evolved Packet Data Gateway (ePDG) 250, User Entity (UE) 255, Trusted or Untrusted (Trusted) Untrusted) Includes non-3GPPIP access or 3GPP access 260, trusted non-3GPPIP access 265, and untrusted non-3GPPIP access 270.

The SGSN is connected to the MME210 via the S3 interface and to the service-providing SAE gateway 225 via the S4 interface. The EUTRAN215 is connected to the MME210 via the S1-MME interface and to the service-providing SAE gateway via the S1-U interface. The MME210 is connected to the HSS220 via the S6a interface and also provides communication via the S10 interface.

The service provider SAE gateway 225 communicates with the PDNSAE gateway 230 via the S5 interface. The PDNSAE gateway 230 communicates with the PCRF 235 via the S7 interface. The operator IP service 240 communicates with the PDNSAE gateway 235 via the SGi interface and with the PCRF 235 via the Rx + interface.

Access 260, 265, and 270 are provided to PDNSAE gateway 230 via interfaces S2c, S2a, and S2b, respectively. In addition, access to the PDNSAE gateway 230 via untrusted non-3GPPIP access 270 requires communication over the ePDG using the Wn * and S2b interfaces.

The 3GPPAAA server 245 communicates with Access 265, Access 270, ePDG250, PDNSAE Gateway 230, and HSS220 via interfaces Ta *, Wa *, Wm *, S6c, and Wx *, respectively.

The protocol disclosed by the present invention is applied using the following six steps.

1. Establish a master key Ka between MN120 and PDNGW105. This can be done, for example, by deriving from the keying material that is derived during the initial authentication. In the SAE and EUTRAN settings, the first AKA is operated between MN120 and MME110. This establishes a key called K_ASME (see 3GPPTR33.821). The master key Ka is derived from this key. Ka is then transferred from MME110 to PDNGW105 (or possibly via any other node in the network). As Ka is transferred to PDNGW105, the interface identifier (IID) is transferred with it. This IID is the rightmost 64-bit part of the IPv6 address and must be unique on the link. Ka configures an IPv6 address with this 64-bit prefix. This pair (Ka, IID) is stored in PDNGW. IID will be described further below.

Although the above embodiment showed the derivation of the master key in the configuration of 3GPP access, this operation can also be performed when an MN such as UE255 connects to the PDNSAE gateway 230 using non-3GPP access. it can. In this case, the MN would typically use EAP-AKA to authenticate to the PDNSAE gateway 230. The result is a key pair of CK and IK. These keys can be the basis for deriving Ka. After operating EAP-AKA, it is also possible to run a separate protocol between the MN and the PDNSAE gateway 230 with a means of establishing a key Ka (which is traditional authentication for non-3GPP access). It would be desirable if the protocol was already in operation and at that time incorporated the invention).

2. MN120 and 255 move from EUTRAN to non-3GPP access. Instead of performing all the authentication protocol operations described in Background Techniques, the MN120 uses one of the appropriate key derivation functions (KDF) to derive the key HKa from Ka. It then provides integrity protection to the RtSol message sent to the AR125 using at least the key material derived from HKa. RtSol also contains an IID (generated in step 1). When AR125 finds an authentication option in the packet that AR125 cannot verify. It will tunnel router requests to the MN120 home PDNGW105. Since AR is MAG, it receives the address of PDNGW105 from home AAA server 245 during or after link layer authentication (as well as the MN home prefix). PDNGW105 and 230 derive the same key HKa and verify the authenticity of the router request. If the verification is successful, this means that the IID used in the router request by MN, as well as the authentication options, is correct, and MN120 and 255 are considered to have been authenticated in the new access. Note that the IID can be used as a source address in router solicitation messages or carried in a time stamp option (already specified in RFC3971).

When AR125 detects the presence of an "unknown" (ie, unverifiable) authentication option in a router solicitation message, AR125 tunnels the message to MN120's home PDNGW105. This means that AR125 will add an outer header with the AR exit interface address as the source address.

When MN moves to non-3GPP access (eg Wimax, CDMA200, and WLAN), it uses its 64-bit IID to set the MN's link-local address and sends a router solicitation message to MN's current new access. Sends to a router (AR), also known as PDNGW. Use the key HKa to protect the integrity of the message. HKa is derived from Ka using any key derivation function (KDF) that takes Ka, IID, or possibly other parameters as input. All parameters must be present in both MN and PDNGW. Other parameters are counters, nonces or other synchronization information (which can also be sent in a router request), and of a particular node or access to tie the functional range of the key. It could contain things like identifiers for types, etc.

3. When PDNGW / HA105 receives the router request, PDNGW / HA105 searches for Ka based on the IID carried in the router request and the IID stored in its binding cache memory. .. Once Ka is found, the integrity of the router request can be confirmed. PDNGW creates a new IID and derives the roaming key Kr from the master key Ka. Replace the old IID in the PDNGW cache with the new IID. The key Kr is sent to the AR along with the router advertisement. Router ads are integrity protected using HKa. The PDNGW105 also uses the MN's HoA and MAG addresses (packet source addresses) to update its binding cache memory. Therefore, the router solicitation function implicitly acts as a proxy binding update (PBU) message that is expected to be sent by MAG.

The IID acts as a replay protection because it is regenerated on each legitimate router request.

4. When the AR125 receives the router advertisement, the AR125 extracts Kr from the message and forwards the router advertisement to the MN120. When the link between PDNGW105 and AR125 is unreliable, the link must be encrypted. If not, an attacker could eavesdrop on the link.

5. MN120 uses the key HKa to check the integrity protection of router advertisements. Then generate the next IID, just as PDNGW did in step 3.

6. All subsequent unicast router advertisements sent periodically by MAG125 to MN120 are integrity protected by Kr (also derived by MN), similar to Neighbor Discovery Protocol messages (also derived by MN). See RFC2461). And these messages must be exchanged via AR (messages are thus protected by the Kr of each MN).

The following discussion provides a more detailed description of the derivation and use of interface identifiers and roaming keys. When the home PDNGW105 receives an RtSol message, it inspects its cache memory for a link-local IID. If found, PDNGW105 takes the corresponding Ka and proceeds to the step of verifying the validity of the message. The PDNGW105 then generates a roaming key (called Kr) that is used to authenticate router advertising messages. The router advertising message is then first tunneled to MN's AR125. In addition, PDN105 inserts Kr in the RtAdv message (eg, the destination option field in the outer header) and encrypts it using the shared key between PDNGW and AR (or this link). If you can assume that security is guaranteed under certain conditions, then). PDNGW must also calculate a new IID (nIID). Then memorize the new IID along with the old IID. IID updates are replay attacks Needed to avoid attack) and protect against endangered AR. For this purpose, PDNGW and MN can calculate IID and Kr as shown by the following equations.

IIDi + 1 = First [64, SHA1 (IID | IIDi | Ka)] The above formula means that the new IID is the first 64 bits of the SHA1 hash of the static identifier string (IID and the old IID and its concatenated Ka). Note that the new IID can be calculated from the old IID using any secure one-way function of the old IID and Ka. This links the IID in a chain. If you are concerned about synchronization issues with this technique (for example, if the message is lost), the IID can be derived from:

IIDi = PRF (IID, Ka, i, othr) In the above equation, PRF is any cryptographic Pseudo Random Function, i is a nonce or counter, and othr is any other information (eg, access network ID, PDNGW ID, MN). ID, access network type, or any combination of these). The purpose of the static identifier string is to ensure that the IID will be different from Kr (see below) if the same derived function is used. IID is derived in the same manner as in MN and PDNGW.

In addition, PDNGW must not send the same Kr to each AR visited by the MN (this is because the AR previously used by the MN sent the wrong router advertisement, which attacked the MN. This is to prevent it from happening). For this purpose, PDNGW and MN must also update Kr each time a new IID is generated. For PDNGW and MN, Kr can be calculated by the following formula.

Kri = PRF (Kr, Ka, i, othr) It should be noted that in the above equation, Kr can be derived by connecting them in a chain as in the case of deriving the IID above.

After receiving the tunneled router advertisement message, the AR125 removes the outer header, stores the MAC address of Kr and MN, and forwards the inner packet to the MN120.

All subsequent router advertising messages are sent by AR125 and authenticated using Kr (or a key derived from Kr and any other information known to MN (eg, network ID)). It must be. In addition, Neighbor Discovery messages sent / received by MN must be exchanged via AR and authenticated using Kr (or a key derived from Kr). This allows the benefits of SeND to be provided in the case of shared links (eg WLAN) without the need for CGA technology.

When mobile IPv6 (MIPv6) is used, MN can still use Ka to authenticate binding updates sent to PDNGW105. That is, Ka is a bidirectional security association established with PDNGW (ie HA) of MN. The MN120 must also use IID to set its own CoA. In this case, it should be noted that the following points are assumed. That is, PDNGW of MN is familiar with the ability of MN, which depends on MIPv6 / PMIPv6, so in the case of PMIPv6, the source address of AR that is held in the outer header as CoA, and in the case of MIPv6. The point is that only the prefix synthesized with MN's IID can always be used as CoA.

Figure 3 shows method 300 for synthesizing Internet Protocol layer authentication with mobility signaling using a packet data network gateway. Method 300 begins at step 305. In step 305, the master key and the first interface identifier are received. The master key Ka is established between MN120 and PDNGW105. This is done, for example, by deriving Ka from the key material derived during the initial certification. In the SAE and EUTRAN settings, the first AKA (Authentication and Key) Agreement: Authentication and Key Match) is performed between MN120 and MME110. This establishes a key called K_ASME (see 3GPPTR33.401). The master key Ka is derived from this key. Ka is then transferred from MME110 to PDNGW105 (or possibly via any other node in the network). At the same time that Ka is transferred to PDNGW105, the interface identifier (IID) is transferred with the key Ka. The IID is the rightmost 64-bit portion of the IPv6 address and must be unique on the link. Ka configures an IPv6 address with a 64-bit prefix. Pairs (Ka, IID) are stored in PDNGW105. IID will be further described below.

In step 310, the router request and the interface identifier are received, for example, from AR125. In one embodiment, the stored interface identifier and the interface identifier received from the AR125 are the same. In step 315, the integrity of the router request is verified using the master key, the stored interface identifier, and the interface identifier received from AR125. When the PDNGW / HA105 receives the router request, the PDNGW105 searches for the stored Ka based on the IID carried in the router request and the IID stored in the PDNGW105 cache memory. If Ka is found, the integrity of the router request can be confirmed.

Figure 4 shows method 400 for synthesizing Internet Protocol layer authentication and mobility signaling using a packet data network gateway. In step 405, the stored master key is retrieved using the interface identifier received from AR125 in step 310.

In step 410, a new interface identifier is generated. In step 415, a roaming key is generated from the master key Ka. PDNGW105 creates a new IID and derives the roaming key Kr from the master key Ka. Replace the old IID in the PDNGW105 cache with this new IID.

In step 420, the roaming key Kr and the router advertisement RtAdv are transferred. The key Kr is sent to AR125 along with the router advertisement. Router ads are integrity protected using HKa. The PDNGW105 also uses the MN120's HoA and MAG address (the source address of the packet) to update the PDNGW105's binding cache memory. Therefore, the router solicitation function implicitly acts as a proxy binding update (PBU) message that is expected to be sent by MAG125. Regeneration protection is achieved because the IID is regenerated on each legitimate router request.

Figure 5 shows Method 500 for synthesizing Internet Protocol layer authentication and mobility signaling using an access router. Method 500 begins at step 505. In step 505, a message with a roaming key and a router advertisement is received. Router ads are integrity protected using the key HKa. At step 510, the roaming key is extracted from the message. In step 515, the router advertisement is forwarded to, for example, the MN120. When the AR125 receives the message, it extracts Kr from the message and forwards the router advertisement to the MN120. If the link between PDNGW105 and AR125 is unreliable, the link is protected by encryption.

FIG. 6 shows method 600 for synthesizing Internet Protocol layer authentication and mobility signaling using an access router. Method 600 starts at step 605. At step 605, an integrity-protected router solicitation message is received. If in step 610 an unverifiable authentication option is detected in the packet, the router solicitation message is tunneled to the packet data network gateway.

Figure 7 shows method 700 for synthesizing Internet Protocol layer authentication and mobility signaling using mobile nodes. Method 700 starts at step 705. At step 705, the master key is established. In step 710, the MN120 moves from the first access network to the second access network. In step 715, the first key, the key HKa, is derived from the master key. At step 720, the router solicitation message is integrity protected using the key HKa. In step 725, the router solicitation message is forwarded to AR125 through, for example, AP130.

Figure 8 shows Method 800 for synthesizing Internet Protocol layer authentication and mobility signaling using mobile nodes. Method 800 begins at step 805. In step 805, a router advertisement with integrity protection using the first key, key HKa, is received. In step 810, the first key is used to determine the integrity of the router advertisement. At step 815, subsequent router messages are received. Each subsequent router advertising message is integrity protected using a roaming key.

In alternative embodiments, optimization can be achieved. This embodiment is an SCE (security credential) between PDNGW105, 230 and HSS220. It has steps to extend exchange) to two-way communication. This is because PDNGW105,230 receives a tuple of [Ka, IID] from MME110, 210 (or its equivalent in the access network to which MN120, 255 first made a connection). Will be sent to the HSS220. In this case, the MN 120, 255 insert the MN IID into the EAP response message while performing the EAP link layer authentication after the handover. When AR125 requests authentication data from home AAA245, it contains IID. The home AAA245 obtains the CoA for MN120, 255 from the source address of this message, that is, the exit interface of AR (MAG). Home AAA245 then notifies PDNGW / HA105, 230 of the new CoA of MN120, 255. This acts as a proxy binding update. When PDNGW105 and 230 get this information, they send Kr to AR (PDN) 125. The AR125 can then use Kr to provide integrity protection for router ads after link layer authentication is complete. The IID can be integrity protected by a key derived from Ka, such as HKa. This provides authentication of the user on the IP layer.

In one embodiment, the HSS 220 calculates the IID itself (instead of the PDNGW in the case described above).

The advantages of the present invention include the following points. However, it is not limited to these. -A complete AKA is not required for re-authentication when performing a handover on a non-3GPP network. PDNGW only accepts messages carrying the "next" IID, so router solicitation messages are never played. -Authenticated router solicitation also acts as a network mobility signaling message, thus significantly reducing IP handoff latency. · No need to sign duplicate address detection (DAD) or Neighbor Discovery Protocol messages. This is because all of these messages (and their responses) are sent over the AR, and each MN uses a shared key between the AR and the MN itself to provide integrity protection for these messages. Is. -64-bit IID can also be transferred within the time stamp option. Therefore, it causes the MN to send an unsolicited address when sending a router solicitation message to the AR. address) can be used. Otherwise, IID is part of the source address.