WO2010045985A1

WO2010045985A1 - Lightweight authentication framework for inter-network hand-over coordination in untrustworthy heterogeneous network en-vironments

Info

Publication number: WO2010045985A1
Application number: PCT/EP2008/064466
Authority: WO
Inventors: Frank-Uwe Andersen; Andreas Köpsel; Frank Pittmann
Original assignee: Nokia Siemens Networks Gmbh & Co. Kg
Priority date: 2008-10-24
Filing date: 2008-10-24
Publication date: 2010-04-29

Abstract

An entity of a first communication network is provided. The entity comprises a verification means and an entity authentication credential. The verification means is provided for verifying at least one message originating from an UE (User Equipment) of the first communication network which is connected with a second communication network. The verifications means compares a message authentication credential element which is contained in the message with the entity authentication credential. The entity discards the message if the comparison results in a mismatch.

Description

DESCRIPTION

Lightweight authentication framework for inter-network handover coordination in untrustworthy heterogeneous network en- vironments

The application is related to an inter-network-handover coordination in untrustworthy heterogeneous network environments

With recent development of multiple access technologies, there arises a need for sophisticated mechanisms of resource allocation and of handover (HO) coordination for heterogeneous access networks. The resource allocation mechanisms are responsible for mapping UEs (User Equipments) to the differ- ent access technologies based on load conditions of access networks, load conditions of core networks, user application requirements, and current geographic locations without sacrificing user experiences with respect to Quality of Service (QoS) and to seamless service. Such resource allocation mechanisms may use information from various sources, which include wireless access networks, in order to coordinate the resource allocation of the UEs and of serving networks.

In March 2004, an IEEE (Institute of Electrical and Electron- ics Engineers) working group, known as IEEE 802.21 working group, started to develop an access technology agnostic framework for a HO-coordination among multiple wireless access technologies and multiple wired access technologies. Furthermore, the access technology agnostic framework pro- vides extensions to existing control planes for the HO coordination and execution.

The access technology agnostic framework provides a media independent access of parameters and of information that are related to the HO coordination. It can serve a variety of different HO control architectures that can support mobility management schemes or network controlled resource management schemes. The access technology agnostic framework may operate in trusted or in un-trusted heterogeneous environments, including environments as described in 3GPP TS 23.401, V8.0.0 (2007-12) , GPRS enhancements for E-UTRAN access, Release 8, http://www.3gpp.org/ and in 3GPP TS 23.402 V8.0.0 (2007-12), Architecture enhancements for non-3GPP accesses, Release 8, http://www.3gpp.org/.

The access technology agnostic framework allows access to network internal states and to network operations, such as query about available resources and about allocation of bear- ers during a HO execution. The access can be via a gateway that is depicted in IEEE P802.21/D8.0, Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services, December 2007.

The IEEE 802.21 standard provides a support for access technology agnostic handover executions between networks. The IEEE 802.21 standard uses supplementary information in order to enhance handover operation of a arbitrary mobility management protocol, such as Mobile IP (Internet Protocol) or Host Identity Protocol. The supplementary information includes technology independent radio-link evaluation information, network discovery information, and handover coordination information among a UE, a serving network, and a candidate network .

A coordination of the inter-network handover includes a request to query resources of both an UE and a serving network to determine availability and sufficiency of resources of a candidate network. This is followed by a HO commit request. During the HO commit request, a handover-coordination between the serving network and a selected candidate network occurs. The HO coordination includes allocation of resources of the selected candidate network. The resources may comprise radio bearers of a UTRAN (Universal Mobile Telecommunications System Terrestrial Radio Access Network) , QoS (Quality of Service) assignment of a core network, and IP (Internet Protocol) mobility resources, such as care-of-addresses .

A lightweight architecture to support a handover of an UE (User Equipment) from an un-trusted serving network and a trusted candidate network is believed to be required for inter-network handover coordination in a heterogeneous un- trusted environment.

The application provides a means for a network to reveal safely its resource information to an un-trusted network during inter-network handover interactions. The resource information may be of value to competitive network operators . The network reveals its resource information to those entities only that respond correctly to a challenge of the network. The un-trusted network is enabled by a trusted UE to respond correctly to the challenge. An unauthorised entity is unlikely or has difficulty to respond correctly to the chal- lenge and thus, access to the candidate network's resource information is denied.

A first method of communication between a first communication network and an un-trusted second communication network is provided. An authentication credential element is shared with an UE (User Equipment) and with the first communication network . The first method comprises the steps of sending the UE authentication credential element by the UE to the second communication network, and sending at least one message with a digital signature of the at least one message from the second communication network to the first communication network. The first method also comprises the steps of authenticating the digital signature by the first communication network using the first communication network's authentication credential element, and discarding the at least one message by the first communication network if the authentication of the digital signature fails.

The step of sending the shared authentication credential from the UE to the second communication network is initiated by the UE. The step of using the authentication credential secures HO coordination messages exchanged between the second and the first communication network. The step of authenticating the digital signature by the first communication network verifies an authorization of the second communication network to act on behalf of the UE and to access HO relevant internal data of the first communication network for coordinating the HO process.

All messages exchanged between the second and the first com- munication network for HO coordination are signed by the second communication network using the authentication credential obtained from the UE, in order to enable the first communication network to verify the second communication network' s authorization to coordinate the HO process on behalf of the UE. The HO coordination messages obtained without any proper authorization signature are discarded by the first communication network. The digital signature of the message assures a recipient of an authenticity and of an integrity of the message. The digital signature can cover the at least one message and a UE identifier .

The UE comprises a terminal that is capable of communicating with a communication network. The terminal can include a mobile phone, or a computing device that is connected to a mobile phone.

The first communication network includes a wireless access network or a wired access network. The wireless access network or the wired access network is intended for exchanging data packets with the UE. The exchange can be realized via the second communication network. The data packets can carry voice or data signals.

The UE can be related to the first communication. The relationship can be in the form of a user of the UE who is sub- scriber of services of the first communication network.

The UE can also be attached to one communication network or to multiple communication networks in parallel . The attachment can use a transportation channel between the UE and the first communication system through which it can exchange data packets. Multiple transportation channels of different technologies can exist between the UE and the first communication system. The transportation channels selected for the attachment can be heterogeneous. The selection can be based on cer- tain criteria, such as traffic load.

The second communication network can be un-trusted in that it does not have a prior roaming agreement with the first communication network. The roaming agreement can include a busi- ness agreement. The second communication network can also be unknown to the first communication network in that it is an outside entity, which can be a competitive communication network and it may have malicious intent.

The UE and the first communication network share the authentication credential for mutual authentication of messages. The messages can include commands and/or information elements. The first communication network can use its authenti- cation credential to authenticate the messages that have the UE authentication credential . The authentication credential should include an identifier of the UE and/or identifier of the first communication network, although other types of identifiers are also possible. The authentication credential element can have a limited lifetime for enhanced security control .

The first method can comprise the further step of exchanging encrypted messages between the first communication system and the second communication system. The encryption is of an appropriate strength to protect the message exchanges against an unauthorized entity from understanding the message exchange .

The message can comprise a query about a resource-information of the first communication network and/or a request for a resource allocation of the first communication network for the UE. The information from the query and the request are intended for preparing a handover of the UE from the second communication network to the first communication network.

The first method can comprise the further steps of creating the authentication credential element by the first communication network and sharing the authentication credential ele- ment with the UE and with the first communication network. A transport channel provides a communication means between the first communication network and the UE for creating and for sharing the authentication credential element. The transport channel can be inactive after the creation of the authentication credential element.

The authentication credential element should be shared over a secure communication channel, although other methods of shar- ing are also possible. The secure communication channel protects messages from any eavesdropping attempt conducted by a third party.

The aforementioned steps can be supported by MIH (Media Inde- pendent Handover) commands. The MIH commands are shown in

IEEE 802.21 documents as depicted in IEEE P802.21/D8.0, Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services, December 2007. The steps can also be supported by extensions of the MIH commands. The com- mands are also called messages or primitives.

The first communication network can include a home network. The home network can include a 3GPP (Third Generation Partnership Project) network. The second communication network can include a serving access network. The authentication credential can include an MIH-HO-Auth (Media Independent- Handover-Authentication) triplet .

The authentication with heterogeneous un-trusted networks can be fulfilled by a MIH (Media Independent Handover) Attach procedure, which creates a MIH Attach context when the UE registers with a specific network, such as the home network. The home network creates the MIH-HO-Auth triplets for the UE. The MIH-HO-Auth triplets can be used to enable the serving access network to bind the MIH commands to an identifier of the served UE and/or of the home network, independent of the access network. The MIH Attach context can remain active, even when there is no transport connection between the UE and the home network. The UE may have several MIH Attach contexts in parallel. The MIH Attach context can be used for internetwork handover coordination messages in heterogeneous network environments.

A second method of operating a first communication network is provided. An authentication credential element is shared with an UE (User Equipment) and with the first communication network. The second method comprises the steps of receiving at least one message with a digital signature of the at least one message from a second communication network, and authenticating the digital signature by the first communication network using the first communication network security credential element.

The at least one message is discarded by the first communication network if the authentication of the digital signature fails. The digital signature is generated using the UE authentication credential element that the second communication network receives from the UE.

The second method can comprise the further step of establishing a secure communication channel between the first communication network and the UE. The method can also comprise the further step of creating the authentication credential element of the UE by the first communication network and sharing the authentication credential element with the UE and with the first communication network. A third method of operating an UE (User Equipment) of a first communication network is provided. The method comprises the step of sending an authentication credential element by the UE to a second communication network. The authentication cre- dential element is shared with the UE and with the first communication network.

The third method can comprise the further step of the sharing of the authentication credential element over a secure commu- nication channel between the first communication network and the UE.

A first communication network is provided. The first communication network comprises an entity that verifies at least one message from a second communication network with an authentication credential element. The authentication credential element is shared with an UE (User Equipment) and with the first communication network.

The UE authentication credential indicates to the first communication network that the message from the second communication network is authorized by the UE.

The first communication network can handle messages compliant to IEEE 802.21 documents, as shown in IEEE P802.21/D8.0 ,

Draft Standard for Local and Metropolitan Area Networks : Media Independent Handover Services, December 2007.

The first communication network can comprises an entity that creates the authentication credential element. The first communication network can also comprises a database that stores a plurality of the authentication credentials element of the UE. The security credential can be stored in a context that is stored in the database. The context remains active, even when there is no direct transport connection between the UE and the first communication network. The UE may have several ac- tive contexts in parallel or at the same period.

An entity of a first communication network is provided. The entity comprises a verification means and an entity authentication credential.

The verification means is provided for verifying a digital signature of at least one message originating from an UE (User Equipment) of the first communication network which is connected with a second communication network. The verifica- tions means uses the entity authentication credential to verify the digital signature. The entity discards the message if the verification of the digital signature fails.

A network is also protected from denial of service attacks, according to the application. The denial of service attack occurs when a potential attacker sends a significant number of handover-commit requests to the network. The handover- commit requests are for unnecessary allocation of significant valuable resources of the network such that the network does not have sufficient resources to operate properly. According to the application, the network would allocate resources only to entities that response correctly to the challenge of the network. As the attacker is unlikely to fulfil this requirement, the resources are not allocated to the attacker.

Hence, the inter-network handover coordination may operate within an un-trusted environment. No pre-established security association between a candidate network and a serving network need to exist. Furthermore, the security association can be established quickly. No dedicated security association need to be established between the serving network and the candidate network.

A UE can establish a non-dedicated secured association with a certain network, such as its home network, over arbitrary access networks. A UE provides necessary credentials for handover coordination to the actual serving network. No specific (business) agreement has to exist between the serving network and the UE to utilize these credentials. The credentials enable a serving network to prove its authorization to conduct a handover coordination protocol exchange on behalf of the UE. The candidate network should verify that the presented credentials have been assigned to an authorized user and are still valid within a predefined time interval, although in certain cases, the credentials are not verified.

Fig. 1 illustrates an overview of a MIH (Media Independent Handover) Attachment procedure and of extended MIH

HO (Handover) procedures among a User Equipment (UE) , a serving network, and a home network,

Fig. 2 illustrates a state diagram of an extended MIH Function (MIHF) supporting the procedures of Fig.

1,

Fig. 3 illustrates abstract message sequences of the MIH

Attachment procedure and of the extended MIH HO procedures of Fig. 1,

Fig. 4 illustrates a first part of an embodiment of Fig. 1 for initiating a network handover of messages from a WiMAX network to a 3G network, Fig. 5 illustrates a second part of the embodiment of Fig. 1 for initiating the network handover of the messages from the WiMAX network to the 3G network,

Fig. 6 illustrates a first extension of the extended MIH HO procedures of Fig. 1,

Fig. 7 illustrates a second extension of the extended MIH HO procedures of Fig. 1,

Fig. 8 illustrates a third extension of the extended MIH HO procedures of Fig. 1,

Fig. 9 illustrates a fourth extension of the extended MIH HO procedures of Fig. 1,

Fig. 10 illustrates a fifth extension of the extended MIH

HO procedures of Fig. 1,

Fig. 11 illustrates a sixth extension of the extended MIH

HO procedures of Fig. 1, and

Fig. 12 illustrates a seventh extension of the extended MIH HO procedures of Fig. 1.

Figs. 1 to 12 have similar parts that are denoted with same part reference number or same name. The description of the similar parts is thus included by reference.

Fig. 1 depicts an overview 10 of a MIH (Media Independent Handover) Attachment procedure 11 and extended MIH HO (Handover) procedures 12 that supports the MIH Attachment procedure 11. The MIH Attachment procedure 11 comprises a registration step 30, an authentication step 31, and a secure transport establishment step 32. The registration step 30 includes a 4-way handshake step.

The MIH Attachment procedure 11 supports a method of handover of messages of a UE (User Equipment) 13 from an un-trusted SAN (Serving Network) 14 to a HNW (Home Network) 15 of the UE 13.

The extended MIH HO procedures 12 comprise MIH HO interactions extensions. The MIH HO interactions extensions are intended for utilizing the MIH Attachment procedures 11 and they are depicted in Figs. 6 to 12. The MIH HO procedure is described in IEEE P802.21/D8.0, Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services, December 2007.

The MIH Attachment procedure 11 is implemented among the UE 13, the SAN 14, and the HNW 15. The HNW 15 includes a MIH SA (Security Association) database 16.

The HNW 15 is a form of a candidate network (CAN) . The CAN is also called a target network. A prior trust relationship does not exist between the SAN 14 and the HNW 15. The SAN 14 is also called an access network. The UE 13 is also called a Mobile Node (MN) .

The UE 13 exchanges data packets with the SAN 14 or with the HNW 15. The UE 13 or the SAN 14 can trigger a handover of the UE 13 from the SAN 14 to the HNW 15. The UE 13 has a MIHF (MIH Function) for providing services to other functions of the UE 13. Similarly, the SAN 14 and the HNW 15 have respectively MIHF.

At least one transportation channel can exist between the UE 13 and the HNW 15. The UE 13 uses one of the transportation channels to register with the HNW 15. The selected transport connection can be based on a priority value or on a state of the last used transport connection. The transportation channel is also called a communication channel.

An authentication keying material is shared between the UE 13 and the HNW 15. The shared authentication keying material is secured with an encryption that is sufficiently strong to protect a transmission of the authentication keying material between the UE 13 and the HNW 15 against software attacks.

The pre-shared authentication keying material comprises a hierarchy of keys similar to a keying hierarchy that is shown in an IETF EAP (Extensible Authentication Protocol) framework so that different keys can be used for different authentication operations. The authentication operation can authenticate transport connections and HO (Handover) related security tokens .

The pre-shared authentication keying material can use an USIM (Universal Subscriber Identity Module) and a technology agnostic authentication that is using IETF protocols, such as an EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) over a PANA (Protocol for carrying Authentication for Network Access) .

Other means of authenticating may also be used, such as AKA (Authentication and Key Agreement) via a 3G-radio access network or a functionality for authenticating non-3G access via a packet data gateway as provided in a SAE (System Architecture Evolution) architecture.

A WLAN (Wireless Local Area Network) channel can use an AES (Advanced Encryption Standard) or a TKIP (Temporal Key Integrity Protocol) encrypted connection, according to IEEE 802.11 documents. It is believed that a WEP (Wired Equivalent Privacy) only encrypted connection with group security does not provide sufficiently strong encryption.

The secured transportation channel can include an arbitrary signalling path that include a radio access network of a home operator or a user's home wireless LAN (Local Area Network) and the Internet.

The authentication keying material is used to authenticate messages from the UE 13 to the HNW 15 via a particular network, which can be an un-trusted network, such as the SAN 14.

An authentication credential from the authentication keying material is provided by the UE 13 to the particular network. This allows the particular network to prove its authorization for sending the message on behalf of the UE 13.

A MIH Attach context 25 and a MIH Attach context 26, as shown in Fig. 3, are established for the UE 13 and the HNW 15. The MIH Attach context 25 or the MIH Attach context 26 can remain active even when there is no active transport connection between the UE 13 and the HNW 15. The attachment may be in a virtualized mode.

The MIH-HO-Auth triplets 17 are created by the HNW 15 upon a request from a UE MIHF (MIH Function) or during the MIH Attachment procedure 11. The HNW 15 also maintains the MIH-HO- Auth triplets 17 in its MIH Attach context 26, which is stored in the MIH SA database 16. The MIH-HO-Auth triplets 17 are shared between UE 13 and the HNW 15 by a secured transportation channel. The UE 13 can request for the additional MIH-HO-Auth triplets 17 from the HNW 15 when it is needed. The MIH SA database 16 may be co-located with other databases, such as a HSS (Home Subscriber Server) database or an AuC (Authentication Centre) database of 3GPP (Third Generation Partnership Project) networks. The 3GPP networks are also called 3G networks.

The MIH-HO-Auth triplets 17 comprise of a temp ID (identifier) 36, a nonce 37, a reply 38, a time-stamp 39, and other parameters. The temp ID 36 includes a user ID and a Home Net- work ID 39. The time-stamp 39 is also called a residual lifetime .

The user ID is used to hide a UE user identity from an un- trusted serving network. The user ID has a limited lifetime. Thus, the user ID is temporary and is anonymous. As an example, the user ID can protect a user of the UE 13 that is a visited third party network, such as a public WLAN (Wireless Local Area Network) hotspot, from revealing its identity. A negotiation of the anonymous temporary user IDs is an op- tional step when an enhanced security and an identity protection are required from a user of the UE 13 or from the HNW 15.

The Home Network ID is used to identify an issuer of the MIH- HO-Auth triplets 17.

The nonce 37 is created by the HNW 15 and is used as input for an authorization puzzle 35, as shown in Fig. 1. The nonce 37 comprises a number. The number can be used once and can be a random or pseudo-random number that is issued to an authentication protocol to ensure that old communications cannot be reused. The authorization puzzle 35 uses the nonce 37 and keying material that is shared between the UE and the home network as input for a challenge. The challenge can use a hash algorithm, such as SHA-I (Variant of a Secure Hash Algorithm) . A one-way authentication scheme may be used here. The nonce 37 is of sufficient size in order to hinder any attacker from using a certain brute-force approach to solve the authorization puzzle 35.

The reply 38 is used to respond to a challenge that uses the nonce 37.

The time-stamp 39 shows a maximum valid lifetime of the MIH- HO-Auth triplet 17. Once the maximum valid lifetime is reached and if the UE 13 does not refresh it, the HNW 15 would then remove the MIH-HO-Auth triplets 17.

The puzzle 35 is pre-calculated and is based on the MIH-HO- Auth triplets 17. It is used by the HNW 15 for the 4-Way- Handshake step 30 to authenticate an incoming resource allocation request messages. The puzzles 35 have matching challenge and response pairs. An incoming handshake attempt by a connecting entity, such as the public wireless LAN, to request for resource allocation of the HNW 15, is answered by a challenge from the HNW 15. The challenge is intended for the connecting entity to solve and to reply with a matching response. The request may include other parameter, such as transport addresses of a participating MIHF (MIH Function) of the connecting entity.

An attacker is denied from issuing a Denial-Of-Service (DOS) attack to the HNW 5. The DOS attack issues large number of resource requests to the HNW 15 to consume resources of the HNW 15 so that the HNW 5 cannot operate properly. According to the embodiment, the attacker is forced to invest processing power for generating matching responses to the challenges issued by the HNW 5 and is thus hindered from issuing the requests. The HNW 5 would discard the resource request if it does not receive a matching response to the challenge. In contrast, the pre-calculated puzzles 35 do not cause the HNW 15 to consume significant processing resources.

The UE 13 passes the MIH-HO-Auth triplets 17 of the UE 13 to the SAN 14 to act as credentials for binding resource requests to the HNW 15 in the authentication step 31. The MIH- HO-Auth triplets 17 are used by the SAN 14 to bind IEEE 802.21 compliant resource requests to an identifier of the served UE 13 so that the HNW 15 can accept these requests, even though the IEEE 802.21 compliant resource requests may have travelled through an un-trusted access network.

The secure transport connection establishment 32 between the SAN 14 and the HNW 15 occurs upon successful handover of messages of the UE 13 to the HNW 15. The secure transport connection can be implemented using an IPsec (Internet Protocol security) with sufficiently large exchanged parameters and data to protect against a potential eavesdropper.

Other approaches of implementing the secure transport connections are also possible. The secure transport connections 32 can be implemented using a SSL (Secure Sockets Layer) based connections. In the LTE (Long Term Evolution) /SAE context or with Unlicensed Mobile Access (UMA) , a secure connection between the UE and the home network may already exist via a Packet Data Gateway (PDG) and this may be used for negotiating the MIH Attach context 25. In a generic sense, the HNW 15 can include networks, such as a 3GPP network. The UE 13 can be registered to multiple IEEE 802.21 compliant networks in parallel, instead of a single network, irrespective of any customer relationship between the UE 13 and the IEEE 802.21 compliant networks. The IEEE 802.21 compliant networks can have parallel connection with the UE 13 in the sense that the UE 13 is simultaneously attached to the IEEE 802.21 compliant networks. The MIH-HO-Auth triplet 17 is a form of an authentication credentials.

A method of handover of messages of the UE 13 from the SAN 14 to the HNW 15 is supported by the MIH Attachment procedure 11. The MIH Attachment procedure 11 includes a registration step 30, an authentication step 31, and a secure transport establishment step 32.

In the registration step 30, the UE 13 and the HNW 15 shares an encryption keying material for protecting information in a transportation channel between the UE 13 and the HNW 15 from being understood by an unauthorised entity. The shared encryption keying material uses the USIM and the EAP-AKA over the PANA. The secure transportation channel includes an arbitrary signalling path that includes a radio access network of a home operator.

Afterwards, upon request from the MIH Attachment procedure 11, the HNW 15 creates MIH-HO-Auth triplets 17 for the UE 13 in its MIH Attach context 25. The HNW 15 then stores its MIH- HO-Auth triplets 17 in the MIH SA database 16. Later, the UE 13 is attached to the SAN 14, which is unknown to the HNW 15.

The HNW 15 then adopts a 4-Way-Handshake process with the pre-calculated puzzle 35 for incoming resource allocation re- quest messages. The pre-calculated puzzle 35 is based on the MIH-HO-Auth triplets 17. An incoming handshake attempt by a connecting entity requesting for resource allocation of the HNW 15 is answered by a challenge from the HNW 15. After suc- cessful completion of the challenge and response exchange, the HNW 15 allocates a data structure for storing the MIH Attach context 25 for the UE 13.

Later, the UE 13 passes its MIH-HO-Auth triplets 17 to the SAN 14 so that the SAN 14 can use it as credentials for binding resource requests to the HNW 15, in the authentication step 31.

After this, secure transport connections are established be- tween the UE 13 and the HNW 15, using an IPsec with sufficiently large exchanged parameters and data to protect from a potential eavesdropper, in the secure transport establishment step 32.

Fig. 2 depicts a state diagram 19 of extended MIH Function

(MIHF) supporting the MIH Attachment procedure 11 and the extended MIH HO procedures 12 of Fig. 1.

The state diagram 19 shows a "Ready" state 23 that is con- nected to a "NW (Network) Attached" state 21 and to a "NW Detached/ MIH Attached" state 20. A "MIH Attached" state 22 is connected to the "NW Attached" state 21 and to the "NW Detached/ MIH Attached" state 20.

In the "Ready state" 23, the UE 13 is not attached to any network, hence also not to the HNW 15. The UE 13 and the HNW 15 do not share an encryption keying material that is suitable for encrypting one or more mutual transport channels between the UE 13 and the HNW 15. The UE 13 is attached to the HNW 15 via a certain transport mechanism, whilst the UE 13 and the HNW 15 does not share an encryption keying material, in the "NW Attached" state 21.

In the "MIH Attached" state 22, the UE 13 is attached to the HNW 15 via a related MIH Attach context 26. The UE 13 and the HNW 15 share an encryption keying material. The MIH Attach context 26 is shown in Fig. 3.

As shown in the "NW Detached/ MIH Attached" state 20, the MIH Attach context 25 is not tied to any pre-existing link. The UE 13 is attached to the HNW 15 via the related MIH attach context 25. The UE 13 and the HNW 15 share the encryption keying material. This feature allows the UE 13 and the HNW 15 to maintain MIH related context information even when the UE 13 is not able or willing to maintain continuously a direct connection .

A soft-state approach is applied for the MIH Attach context 25 in that the UE 13 should periodically refresh the MIH Attach context 26 in the HNW 15. Lifetimes for this period are negotiated according to requirements of the UE 13 and/or of the HNW 15.

In a generic sense, the UE 13 can maintain multiple MIH Attach contexts 26 with different multiple HNWs 15 in the same period. The MIH Attach context 26 can comprise multiple transport connections for contacting the UE 13, and it can use different access points of the network.

Fig. 3 depicts abstract message sequences 24 of the MIH Attachment procedure 11 and of the extended MIH HO procedures 12 of Fig. 1. The abstract message sequences 24 illustrate steps of a method for performing a handover of the UE 13 from the SAN 14 to the HNW 15.

As depicted Fig. 3, the MIH Attachment procedure 11 creates a MIH Attach context 26, in a step Ia. The HNW 15 stores the MIH-HO-Auth triplets 17 for the UE 13 in its MIH Attach context 26, in a step Ib. The UE 13 and the HNW 15 shares the MIH-HO-Auth triplets 17, in a step 2a and in a step 2b. The UE 13 hands the MIH-HO-Auth triplets 17 to the SAN 14, in a step 3a.

The MIH-HO-Auth triplets 17 has credentials that acts to bind IEEE 802.21 compliant resource requests securely to the identity ID 36 of the served UE 13 so that the HNW 15 can verify an authorization of the IEEE 802.21 compliant resource requests. The identify ID 36 is shown in Fig. 1.

The HNW 15 calculates an accompanying reply 38 to the challenge using the nonce 37 and the credentials. The calculation can be done using a one-way hashing function, such as SHA-I (Variant of a Secure Hash Algorithm) . The nonce 37, the response 38, and the temporary user identity 36 are stored in the MIH Attach context 26 of the HNW 15. The nonce 37, the response 38, and the temporary user identity 36 are shown in Fig. 1.

When a MIH-HO-Auth triplet residual lifetime 39 has expired, the MIH-HO-Auth triplet 17 is removed automatically from the MIH Attach context 25. The UE 13 may request additional MIH- HO-Auth triplets 17 via a secure channel from the HNW 15.

In a special embodiment, a UE is present in a public wireless LAN, which has no trust relationship either to a user of the UE or to a home network of the UE user. A home network of the UE includes a 3GPP (Third Generation Partnership Project) network .

The UE user is provided here as a subscriber. The public wireless LAN is provided here as a serving access network. The 3G network is provided here as a candidate network.

A method of a handover of messages of the UE from the public wireless LAN to a 3G network, which is also the UE ' s home network, is shown below.

A HO control decision function decides to handover of the UE from the public wireless LAN to the 3G network of the home network. The UE then hands a set of a currently active MIH- HO-Auth triplets 17 to the public wireless LAN.

A MIH Function of the public wireless LAN afterward starts an exchange of a resource request with the 3G network according to procedures as described in IEEE P802.21/D8.0, Draft Stan- dard for Local and Metropolitan Area Networks: Media Independent Handover Services, December 2007. The 3G network rejects any incoming unauthenticated resource requests. Therefore, the public wireless LAN includes a temporary user identity in the resource request and sends the resource request to the 3G network.

The 3G network then selects an active MIH-HO-Auth triplet 17 from its MIH Attach context 25 sends a challenge nonce of the MIH-HO-Auth triplet 17 to the public wireless LAN. The public wireless LAN then re-send its resource request with a signature that comprises a payload and a response, which is obtained from a MIH-HO-Auth triplet 17 that is received from the UE 13. The signature is also called a digital signature. The response matches the received challenge nonce from the 3G network. The 3G network later verifies the signature with its local challenge and response pair that is stored in the MIH Attach context 26.

Upon a successful authentication, the 3G network accepts the resource request and it answers with an appropriate resource reply to the public wireless LAN. Otherwise, the resource request is rejected. Then, an IEEE 802.21 compliant HO execution is performed. If further messages are exchanged between the 3G network and the public wireless LAN, additional MIH- HO-Auth triplets 17 may be used.

The method provides a secure means for a UE to be connected with its home network when the UE is visiting another network that does not have any prior authentication arrangement with the home network.

Fig. 4 and Fig. 5 illustrate an embodiment of a network- initiated handover from a WiMAX (Worldwide Interoperability for Microwave Access) network 40 to a 3GPP (Third Generation Partnership Project) network 41. The 3GPP network 41 is also called a 3G (Third Generation) network.

A Mobile Node (MN) 42 is attached to the WiMAX network 40. A Correspondent Node (CN) 43 is attached to the 3G network 41. Other network 44 is also connected to the WiMAX network 40 and to the 3G network 41.

The WiMAX network 40 is described in IEEE 802.16 documents, which can be found at http://grouper.ieee.org/groups/802/16/. The WiMAX network 40 is deployed in a hot-spot. The 3G network 41 is deployed in a WAN (Wide Area Network) . A traffic stream 45 flows via the WiMAX network 40 to the 3G network 41. The traffic stream 45 also flows between the MN 42 and the CN 43.

The WiMAX network 40 is provided here as a serving network. The 3G network 41 is provided here as the only available candidate network. The MN 42 is a type of a UE (User Equipment) .

A method of handover of the MN 42 from the WiMAX network 40 to the 3G network 41 is shown below. The handover is initiated by the WiMAX network 40.

Initially, a resource availability check and resource reservations are performed, since services provided by the 3G net- work 41 depends on QoS requirements. After this, the WiMAX network 40 indicates a handover request to the MN 42. Then, the steps of the handover are performed, in a manner similar to the earlier handover. This enables the 3G network 41 to accept only those messages that include credentials that are negotiated between the 3G network 41 and the MN 42, and not with the WiMAX network 40.

In a generic sense, the method can support other handover situations. The handover situations can include situations with different levels of UE integration in the sense of different levels of network to UE communication.

Figs. 6 to 12 depict a plurality of MIH protocol extensions.

The MIH protocol extensions does not affect a MIES (Media Independent Event Service) nor a MIIS (MIH Information Service) as described in IEEE P802.21/D8.0, Draft Standard for Local and Metropolitan Area Networks: Media Independent Handover Services, December 2007. The MIH protocol extensions comprises a first extension that comprises an extended MIH_MN_HO_Candidate_Query_Request command 50, a second extension that comprises an extended MIH_Net_HO_Candidate_Query_Request command 55, a third extension that comprises an extended MIH_Net_HO_Candidate_Query_Response command 60, a fourth extension that comprises an extended MIH_N2N_HO_Query_Resources_Request command 65, a fifth extension that comprises a MIH_N2N_HO_Query_Resources_Auth_Challenge command 70, a sixth extension that comprises an extended MIH_N2N_HO_Query_Resources_Response command 75, and a seventh extension that comprises an extended MIH_N2N_HO_Commit_Request command 80.

The extended MIH_MN_HO_Candidate_Query_Request command 50, the extended MIH_Net_HO_Candidate_Query_Request command 55, the extended MIH_N2N_HO_Query_Resources_Request command 65, the extended MIH_N2N_HO_Query_Resources_Response command 75, and the extended MIH_N2N_HO_Commit_Request command 80 provide indication of information.

The extended MIH Net HO Candidate Query Response command 60, and the extended MIH N2N HO Query Resources Response command 75, and the extended MIH_N2N_HO_Commit_Request command 80 provide confirmation of information.

The command is also called a primitive or a message.

The "MIH_MN_HO_Candidate_Query_Request" primitive 50 is shown in Fig . 6. One MIHF (MIH Function) of the UE 13 uses the MIH_MN_HO_ Can- didate_Query_Request primitive 50 to request a MIHF of the candidate network 15 for a possible HO initiation. The request may query about QoS resources of the candidate network 15 and/or about whether IP (Internet protocol) address configuration of ongoing data sessions that can be supported in the candidate networks 15. The MIH_MN_HO_Candidate_Query _Request primitive 50 also includes a current IP configuration server address when a current IP address configuration method is supported. The IP configuration server address can include a DHCP (Dynamic Host Configuration Protocol) server address, FA (Foreign Agent) IP (Internet Protocol) address, or AR (Access Router) IP address.

An extension of the MIH_MN_HO_Candidate_Query_Request primitive 50 comprises the active MIH-HO-Auth triplets 17 for exchanging messages between the UE 13 and the candidate network 15.

The extended MIH_Net_HO_Candidate_Query_Request primitive 55 is shown in Fig. 7.

In a network-initiated handover, a network controller or the MIHF of the SAN 14 provides a list of candidate network choices to the MIHF of the UE 13 via the MIH_Net_HO_Candidate

Query Request message 55. The MIHF of the SAN 14 also uses the MIH Net HO Candidate Query Request primitive 55 to query the UE MIHF of the UE 13 about its QoS constraints. It also indicates an intent of the MIHF of the SAN 14 to initiate a handover of the UE 13.

The SAN 14 provides the MIH_Net_HO_Candidate_Query_Request primitive 55 with an extension. The extension comprises an MIH Attach information element 56 for indicating its ability to accept and to handle the MIH-HO-Auth triplets 17 for authenticating network-to-network HO coordination of the UE 13.

The extended MIH Net HO Candidate Query Response primitive 60 is shown in Fig. 8.

The MIH_Net_HO_Candidate_Query_Response primitive 60 is sent upon receipt of the MIH_Net_HO_Candidate_Query_Request primitive 55. It provides UE constraints of an intended HO proc- ess .

The MIHF of the UE 13 provides the MIH_Net_HO_Candidate_Query _Response primitive 60 with an extension, if possible. The extension comprises the MIH-HO-Auth triplets 17 for an ex- change between the UE 13 and the candidate network 15. Same restrictions for a secure L2 connection exist for both the extended MIH_Net_HO_Candidate_Query_Request primitive 55 and the extended MIH_Net_HO_Candidate_Query_Response primitive 60.

The extended MIH_N2N_HO_Query_Resources_Request primitive 65 is shown in Fig. 9.

The MIH N2N HO Query Resources Request primitive 65 is used by the MIHF of the SAN 14 to communicate with the peer MIHF of the candidate network 15. This is used to query about available link resources and about IP address related information of the candidate network 15.

The serving network MIHF uses an extension of the MIH_N2N_HO _Query_Resources_Request primitive 65 to indicate an existence of the appropriate MIH-HO-Auth triplets 17 and of an UE identity information element 66 to the candidate network 15. The UE identity information element 66 is temporary. On receipt of the indication, the candidate network MIHF verifies the existence of the valid MIH-HO-Auth triplets 17 for the specified UE identity and it issues the MIH_N2N_HO Query Resources Auth Challenge message 70. Depending on local policies of the candidate network 15, the candidate network 15 may accept unauthorized query requests.

The UE identity information element 66 indicates an identity of the UE that is requesting for HO coordination.

The MIH_N2N_HO_Query_Resources_Request message 65 may be sent twice .

In a first message exchange, the serving network MIHF sends a first MIH_N2N_HO_Query_Resources_Request message 65 without an authentication to the candidate network 15. Depending on local policies of the candidate network 15, the candidate network MIHF may accept the request.

If the candidate network MIHF does not accept the request, the candidate network 15 forces the SAN 14 to repeat its request by sending an authentication challenge request message to the SAN 14. The challenge message has a valid signature for the SAN 14 to verify an authorization of the authentication challenge request message. For this purpose, the candidate network 15 uses the MIH N2N HO Query Resources Auth _Challenge message 70.

In a second message exchange, the SAN 14 sends a second authenticated MIH N2N HO Query Resources Request message 65 to the candidate network 15. The second authenticated MIH N2N HO Query Resources Request message 65 has a signature field that is filled accordingly. A signature of the signa- ture field is calculated using an entire payload and the response byte sequence for the demanded challenge from the appropriate MIH-HO-Auth triplet 17. The signature is also called a MIH Attach HO Signature 67.

The MIH_N2N_HO_Query_Resources_Auth_Challenge primitive 70 is shown in Fig . 10.

The MIH_N2N_HO_Query_Resources_Auth_Challenge primitive 70 is used to send the challenge to the serving network MIHF to force the serving network MIHF to digitally sign all further messages for the HO coordination. The

MIH_N2N_HO_Query_Resources_Auth_Challenge message 70 contains a MIH Attach Challenge 71. The MIH Attach Challenge 71 is se- lected from the set of the active MIH-HO-Auth triplets 17.

The MIH Attach Challenge 71 comprises a random byte stream of an appropriate length. The

MIH_N2N_HO_Query_Resources_Auth_Challenge message 70 may also be used to force the serving network MIHF to repeat the MIH_N2N_HO_Query_Resources_Request message 65 when no UE identity is available. The MIH Attach Challenge 71 may include an UE identity information element 72 that the serving network MIHF sends to the candidate network 15.

On receipt of the MIH_N2N_HO_Query_Resources_Auth_Challenge primitive 70, the serving network MIHF extracts an appropriate response from the MIH-HO-Auth triplets 17 that matches the MIH Attach Challenge 71. The serving network MIHF later repeats the initial MIH N2N HO Query Resources Request mes- sage 65, with the extension of the MIH Attach HO signature 67 that is shown in Fig. 9. Thus, the serving network MIHF sends the authorisation challenge response piggybacked implicitly with the MIH N2N HO Query Resources Request message 65. The initial request MIH N2N HO Query Resources Request message 65 with the digital MIH Attach HO signature 67 is intended to bind the request MIH N2N HO Query Resources Request message 65 to the UE identity in a secure manner.

The extended MIH N2N HO Query Resources Response primitive 75 is shown in Fig. 11.

The MIH_N2N_HO_Query_Resources_Response primitive 75 is used by the MIHF of the candidate network 15 to communicate with the peer MIHF of the SAN 14 that has sent the MIH_N2N_HO

_Query_Resources_Request message 65. This is used to respond with a result of any resource preparation for an impending handover and to notify the MIHF of the SAN 14 of a link resource status of the candidate network 15. It is also used to provide IP address related information of the candidate networks 15.

The MIH_N2N_HO_Query_Resources_Response primitive 75 includes an extension. The extension comprises an UE identity informa- tion element 76 and a MIH Attach HO signature 77 calculated by the candidate network 15. The extension enables the MIHF of the SAN 14 to identify fraud response messages.

The UE identity information element 76 provides the UE iden- tity of the SAN 14 that is requesting for HO coordination.

The MIH Attach HO signature 77 is used in the second message exchange and is calculated using the payload and the response byte sequence for the demanded challenge.

The extended MIH N2N HO Commit Request primitive 80 is shown in Fig. 12. The MIH user of the SAN 14 informs a selected target network that the UE 13 is about to handover to the target network via the MIH_N2N_H0_Commit_Request primitive 80.

The MIH_N2N_HO_Commit_Request primitive 80 contains an UE identity 81 and a MIH Attach HO Signature 82 that is calculated by the SAN 14. This enables the target network MIHF to identify fraud request messages.

The UE identity information element 81 is provided to the target network by the serving network MIHF. The serving network MIHF is requesting handover coordination from the target network MIHF. The MIH Attach HO signature 82 is used in the second message exchange and is calculated using the payload and the response byte sequence for the demanded challenge. The extension allows the candidate network MIHF to identify fraud request messages.

In short words, the above embodiments provide a lightweight architecture for handover of the UE 13 from an un-trusted SAN 14 to the trusted candidate network 15. The UE 13 can have multiple parallel network attachments.

The architecture is applicable to un-trusted and dynamic net- work environments. The attachment may be in a virtualized mode. In particular, the architecture is applicable to 3GPP (Third Generation Partnership Project) networks that is IEEE 802.21 compliant. The 3GPP networks can co-operate with unknown networks in which no prior roaming agreements has been established. The dynamic network environment allows a home network to allocate resources to a serving network that does not have a prior roaming agreement.

MIH (Media Independent Handover) Attachment The architecture provides the MIH (Media Independent Handover) Attachment procedure 11 to create and to process the MIH Attach context 25.

The MIH Attach context 25 is based on a mutual authentication between the UE 13 and a network. The mutual authentication is performed using pre-shared credentials. The MIH Attach context 25 stores MIH Handover Authentication (MIH-HO-Auth) triplets 17.

Creation of the MIH-HO-Auth triplets

The UE' s network creates the MIH-HO-Auth triplets 17 inde- pendently or upon request from an UE 13. The MIH-HO-Auth triplets 17 are stored in a network side database. The MIH- HO-Auth triplets 17 are transmitted to the UE 13 for later authentication of MIH-supported HO requests.

The MIH-HO-Auth triplets 17 comprise user identifiers of the UE 13, identifiers of the home network, challenge and response pairs, as well as time-stamps that specify valid time- periods of the MIH-HO-Auth triplets 17. The user identifiers can be changed later.

MIH protocol extensions

The MIH protocol extensions provides the MIH-HO-Auth triplets 17 that are forwarded from the UE 13 to an un-trusted SAN 14 during a HO preparation using the extended MIH [MN/Net] HO

_Candidate_Query_[Request/Response] primitive 50, 55, and 60. The extended query request messages 50 and 55 may contain information for multiple candidate networks 15 and the multiple MIH-HO-Auth triplets 17 for the respective different multiple candidate networks 15. Similarly, the extended response messages 60 for a network-initiated procedure may also contain information for multiple candidate networks 15 and the multiple MIH-HO-Auth triplets 17 for the respective different mul- tiple candidate networks 15.

The extended MIH_N2N_HO_Query_Resources_Request message 65 is used by the SAN 14 to indicate possession of an authentication material to the candidate network 15. The extension in- eludes the identity of the UE. The candidate network 15 checks for existence of the valid MIH-HO-Auth triplets 17 in its local database and selects a MIH-HO-Auth triplet 17. A challenge of the selected MIH-HO-Auth triplet 17 is afterward sent to the SAN 14.

The MIH protocol extensions include the MIH_N2N_HO_Query _Resources_Auth_Challenge message 70. The candidate network 15 challenges the SAN 14 by sending the MIH_N2N_HO_Query _Resources_Auth_Challenge message 70 to the SAN 14 for an au- thentication . The MIH Function of the SAN 14 later responses by selecting an appropriate response from its stored set of MIH-HO-Auth triplets 17 and resends the MIH_N2N_HO_Query

Resources Request message 65 with an extension that comprises a digital signature that covers the payload, the UE identity, and the response to the candidate network 15. The candidate network 15 afterwards verifies the digital signature and grants an access to the requested resources, if the verification of the digital signature is successful.

A security association based on the MIH-HO-Auth triplet 17 between the SAN 14 and the candidate network 15 is provided by the MIH protocol extensions. The security association is established by a valid verification. All consecutive internetwork handover coordination messages between the SAN 14 and the candidate network 15 are digitally signed using the challenge and response pair. The digital signing covers the MIH N2N HO Commit Request message 80 and response messages exchanges for executing a handover as well as any further message exchanges between the serving-network 14 and the candidate network 15.

The candidate network 15 provides a digital signing process for any message that it sends to the SAN 14, once the secu- rity association is established, according the MIH protocol extension. This is to prevent any entity that is along a sending path from altering the sent message.

According to the MIH extensions, the UE 13 would invalidate the MIH-HO-Auth triplets 17 that are used by the MIH Function of the candidate network 15, if the UE 13 is detached from its current SAN 14.

Entities of the extended UE MIHF and of the extended candi- date network's MIHF store and process the MIH Attach context 25, the MIH-HO-Auth triplets 17, as well as the MIH protocol extensions .

The MIH Security Association (SA) database 16 may be co- located with other databases. The challenge and response pair is formed or is calculated using an encryption mechanism. The challenge and response pair includes a nonce as a challenge. The network uses a keying material to generate the nonce. The keying material is shared between the UE 13 and the candidate network 15 to protect the MIH-HO-Auth triplet 17. The MIH-HO- Auth triplets 17 are sent via an encrypted channel between the candidate network 15 and the UE 13 and are thus hidden to any third party. 

List of references

[1] 3GPP TS 23.401, V8.0.0 (2007-12), GPRS enhancements for E-UTRAN access, Release 8, http://www.3gpp.org/

[2] 3GPP TS 23.402 V8.0.0 (2007-12) , Architecture enhancements for non-3GPP accesses (Release 8), http : //www.3gpp . org/

[3] 3GPP TS 33.102 V7.1.0 (2006-12) , 3G Security architecture (Release 7), http://www.3gpp.org/

[4] IEEE P802.21/D8.0, Draft Standard for Local and

Metropolitan Area Networks: Media Independent Hand- over Services, December 2007

List of abbreviations

3GPP Third Generation Partnership Project

AES Advanced Encryption Standard

AR Access Router

AuC Authentication Centre

CN Correspondent Node

DHCP Dynamic Host Configuration Protocol

EAP Extensible Authentication Protocol

EAP-AKA Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement

FA Foreign Agent

HNW Home Network

HO Handover

HSS Home Subscriber Server

IEEE Institute of Electrical and Electronics Engineers)

IETF Internet Engineering Task Force

IP Internet Protocol

IPsec Internet Protocol security

LAN Local Area Network

LTE Long Term Evolution

MD5 Message-Digest algorithm 5

MIES Media Independent Event Service

MIH Media Independent Handover

MIH-HO-Auth MIH Handover Authentication

MIHF MIH Function

MIIS MIH Information Service

MN Mobile Node

MNO Mobile Network Operator

NW Network

PANA Protocol for carrying Authentication for Network Access PDG Packet Data Gateway

QoS Quality of Service

SA Security Association

SAE System Architecture Evolution SAN Serving Network

SHA-I Variant of a Secure Hash Algorithm

SSL Secure Sockets Layer

TKIP Temporal Key Integrity Protocol

UE User Equipment UMA Unlicensed Mobile Access

UMTS Universal Mobile Telecommunications System

USIM Universal Subscriber Identity Module

UTRAN UMTS Terrestrial Radio Access Network WAN Wide Area Network

WEP Wired Equivalent Privacy

WiMAX Worldwide Interoperability for Microwave Access

Reference numbers

10 overview

11 MIH (Media Independent Handover) Attachment procedure

12 extended MIH HO procedures

13 UE (User Equipment)

14 SAN (Serving Network)

15 HNW (Home Network) 16 MIH SA (Security Association) database

17 MIH-HO-Auth (MIH Handover Authentication) triplets

19 state diagram

20 "NW Detached/ MIH Attached" state 21 "NW Attached" state

22 "MIH Attached" state

23 "Ready" state

24 abstract message sequences

25 MIH Attach context 26 MIH Attach context

30 4-Way-Handshake step

31 authentication step

32 secure transport connection step 35 puzzle 36 temp ID (identifier)

37 nonce

38 reply

39 time-stamp 40 WiMAX network 41 3G network 42 mobile node (MN)

43 Correspondent Node

44 Other network

45 traffic stream 50 extended MIH_MN_HO_Candidate_Query_Request command

55 extended MIH_Net_HO_Candidate_Query_Request command 56 MIH Attach Information Element

60 extended MIH_Net_HO_Candidate_Query_Response command

65 extended MIH_N2N_HO_Query_Resources_Request command 66 UE identity information element

67 MIH Attach HO Signature

70 MIH_N2N_HO_Query_Resources_Auth_Challenge command

71 MIH Attach Challenge 72 UE identity information element

75 extended MIH_N2N_HO_Query_Resources_Response command

76 UE identity information element

77 MIH Attach HO Signature 80 extended MIH_N2N_HO_Commit_Request command

81 UE identity information element

82 MIH Attach HO Signature

Claims

1. A method of communication between a first communication network (15) and a second communication network (14), an authentication credential element (36; 66) being shared with an UE (User Equipment) (13) and with the first communication network (15) , the method comprises the steps of sending the UE authentication credential element (36; 66) by the UE (13) to the second communication network (14) , sending at least one message (65; 80) with a digital signature (67; 77; 82) of the at least one message (65; 80) from the second communication network (14) to the first communication network (15) , authenticating the digital signature (67; 77; 82) by the first communication network (15) using the first communication network's authentication credential element (36; 66) , and discarding the at least one message (65; 80) by the first communication network (15) if the authentication of the digital signature (67; 77; 82) fails.

2. A method of communication according to claim 1, characterized in that the method comprises the further step of exchanging encrypted messages between the first communication system (15) and the second communication system (14) .

3. A method of communication according to claim 1 or 2, characterized in that the message (65) comprises a query about a resource information of the first communication network (15) and/or a request for a resource allocation of the first communication network (15) for the UE (13) .

4. A method of communication according to one of the afore- mentioned claims, characterized in that the method comprises the further steps of creating the authentication credential element (36; 66) by the first communication network (15) and sharing the authentication credential element (36;

66) with the UE (13) and with the first communication network (15) .

5. A method of communication according to claim 4, characterized in that the sharing of the authentication credential element (36; 66) over a secure communication channel.

6. A method of communication according to one of the afore- mentioned claims, characterized in that the steps are supported by MIH (Media Independent Handover) commands (50; 55; 60; 65; 70; 75; 80) .

7. A method operating a first communication network (15), an authentication credential element (36; 66) being shared with a UE (User Equipment) (13) and with the first communication network (15), the method comprises the steps of receiving at least one message (65; 80) with a digital signature (67; 77; 82) of the least one message (65; 80) from a second communication network (14), the digital signature (67; 77; 82) is generated using the UE authentication credential element (36; 66) that the sec- ond communication network (14) receives from the UE (13) , authenticating the digital signature (67; 77; 82) by the first communication network (15) using the first communication network security credential element (36; 66) , and discarding the at least one message (65; 80) by the first communication network (15) if the authentication of the digital signature (67; 77; 82) fails.

8. A method of operating a first communication network (15) according claim 7, characterized in that the method comprises the further step of establishing a secure communication channel between the first communication network (15) and the UE (13) .

9. A method of operating a first communication network (15) according to claim 8 characterized in that the method comprises the further step of creating the authentication credential element (36;

66) of the UE (13) by the first communication network

(15) and sharing the authentication credential element (36;

66) with the UE (13) and with the first communication network (15) .

10. A method of operating a UE (User Equipment) (13) of a first communication network (15), the method comprises the step of sending an authentication credential element (36; 66) by the UE (13) to a second communication network (14) , the authentication credential element (36; 66) be- ing shared with the UE (13) and with the first communication network (15) .

11. A method operating a UE (13) of a first communication network (15) according claim 10, characterized in that the method comprises the further step of the sharing of the authentication credential element (36; 66) over a secure communication channel be- tween the first communication network (15) and the UE (13) .

12. A first communication network (15) that comprises an entity that verifies at least one message from a second communication network (14) with an authentication credential element (36; 66) , the authentication credential element (36; 66) being shared with a UE (User Equipment) (13) and with the first communication network (15) .

13. A first communication network (15) according to claim 12 characterized in that the first communication network (15) further comprises an entity that creates the authentication creden- tial element (36; 66) .

14. A first communication network (15) according to one of the claims 14 to 16, characterized in that the first communication network (15) further comprises a database (16) that stores a plurality of the authentication credentials element (36; 66) of the UE (13) .

15. An entity of a first communication network (15) that comprises a verification means and an entity authentication credential (36; 66) , the verification means being provided for verifying a digital signature (67; 77; 82) of at least one message (65) originating from an UE (User Equipment) (13) of the first communication network (15) which is connected with a second communication network (14), the verifications means uses the entity authentication credential (36; 66) to verify the digital signature (67; 77; 82), the entity discarding the message (65) if the verification of the digital signature (67; 77; 82) fails.