Authentication and secure channel setup for communication handoff scenarios

Persistent communication layer credentials generated on a persistent communication layer at one network may be leveraged to perform authentication on another. For example, the persistent communication layer credentials may include application-layer credentials derived on an application layer. The application-layer credentials may be used to establish authentication credentials for authenticating a mobile device for access to services at a network server. The authentication credentials may be derived from the application-layer credentials of another network to enable a seamless handoff from one network to another. The authentication credentials may be derived from the application-layer credentials using reverse bootstrapping or other key derivation functions. The mobile device and/or network entity to which the mobile device is being authenticated may enable communication of authentication information between the communication layers to enable authentication of a device using multiple communication layers.

BACKGROUND

A user is generally able to use a service continuously while roaming across networks. When a user moves from a location being serviced by a current network to a location being serviced by a target network, a handoff may be performed, for example, at the access layer. When the handoff is performed, the user may need to be authenticated to the target network servicing the location into which the user is moving. An authentication on the access layer may occur in each handoff, and the user device may use pre-provisioned credentials for accessing the target network at the access layer.

The user's communication device may communicate using layered communication mechanisms. In many cases, the different layers of communication each require their own security. Handoffs may occur between one node in a layered network to another node. While techniques may exist to realize such handoffs, the communications may require a break of the currently used security associations or mechanisms.

According to one example, access-layer handoffs may cause such a break in the currently used security mechanisms by using an additional security establishment when a handoff takes place at the access-layer to another network. For example, the additional security establishment may include another session of authentication and/or security key agreement each time a handoff takes place at the access-layer. As access-layer handoffs may become more frequent, establishing additional security sessions each time an access-layer handoff occurs may introduce delays and/or unnecessary over-the-air communications and/or burden on the network authentication infra-structure. This may make it difficult to realize seamless handoffs.

SUMMARY

This Summary is provided to introduce various concepts in a simplified form that are further described below the Detailed Description.

Systems, methods, and apparatus embodiments are described herein for generating an authentication credential at a mobile device for authenticating the mobile device for access to services at a network server. The persistence of an authentication and the associated credentials at one layer may be used to establish credentials at another layer. As described herein, a persistent communication layer credential may be established that is shared with a network server. For example, the persistent communication layer credential may be an application-layer credential generated at an application layer or other credential generated at a persistent communication layer that survives a handoff from one network to another. The persistent communication layer credential may be established via a persistent communication layer on a first network. The persistent communication layer credential may be configured to authenticate the mobile device for receiving a service from the network server using the first network. A network communication entity on a second network may be discovered and an authentication credential may be generated based on the persistent communication layer credential. The authentication credential may be used for authenticating with the second network via a communication layer other than the persistent communication layer to enable the mobile device to receive the service from the network server using the second network.

According to another example embodiment, an authentication credential may be obtained at an application server for use in authenticating a mobile device at an application server residing on a communication network. For example, an authentication credential may be obtained that is derived from an application-layer credential. The authentication credential may be obtained via an application layer associated with the application server. The authentication credential may be configured to authenticate the mobile communication device for accessing services from the application server. The authentication credential may be sent from the application layer to another communication layer for authenticating the mobile device on the other communication layer.

According to an example embodiment, the other communication layer may be an access layer. The access layer may be a physical, data link, and/or network layer. When the other communication layer is an access layer, the authentication credential may be an access-layer credential used for authentication at the access layer.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Described herein are various implementations for using federated identity and Single Sign On (SSO), such as the OpenID protocol for example, to enable seamless user/device authentication and secure mobility across heterogeneous networks. The embodiments described herein may leverage credentials on one network to perform authentication on another. In one example embodiment, persistent communication layer credentials generated at a persistent communication layer on one network may be used to perform reverse bootstrapping and complete the security layer authentication and/or secure tunnel setup in an on-demand and seamless fashion on another network. According to an example embodiment, the persistent communication layer credential may be an application-layer credential generated at an application layer or another credential generated at a communication layer that survives a handoff from one network to another. While the embodiments herein describe the use of an application-layer credential to perform authentication at another layer (e.g., non-persistent communication layer) in a handoff scenario, it will be understood that any other credential may be used that is established at a persistent communication layer that survives a handoff between networks.

According to an embodiment, systems and methods are described for generating access-layer authentication credentials for use in authentication of a mobile device during a handoff (e.g., access-layer handoff). The authentication credentials may be generated so that a service that is accessed by the mobile device continues seamlessly uninterrupted during the handoff. As described herein secure communication may be established at an access layer with a first network entity. A secure application-layer communication may also be established with an application server based on the secure communication with the first network entity. The service may be received using the secure communication. A second network entity may be discovered. An authentication credential (e.g., access-layer credential) may be generated for authentication with the second network entity. The authentication credential may be generated using application-layer information associated with the application-layer communication. The authentication credential may be generated while the service is seamlessly uninterrupted during the handoff.

According to an example embodiment, authentication may be performed during a handoff from one network to another, using a single sign on (SSO) protocol for example, to enable access to services from an application server by a wireless communications device. For example, the handoff may be from a cellular communications network (e.g., 3GPP network) to a wireless local area network (WLAN) (e.g., browser-based WLAN or 802.1x/EAP-based WLAN). The SSO protocol may be based on a Generic Bootstrapping Architecture (GBA). The SSO protocol may also implement OpenID. The SSO protocol may be used to implement key derivation functions, such as reverse bootstrapping for example, for generation of authentication credentials used for authenticating a user and/or device at the application server. The application server may include an authentication, authorization, and accounting (AAA) server acting as an OpenID provider (OP) or a relying party (RP). According to another embodiment, the application server may include a wireless local area network (WLAN) gateway or a WLAN access point (AP) acting as an RP. The WLAN AP may allow SSO exchanges between the UE and another SSO entity.

A description of terms used herein is provided. Local identity provider (local IdP) is a term for a client-localized entity and functions of such entity that enables identity assertion for a user/device made locally, i.e., on or very near to the device. RP is Relying Party in the OpenID protocol or other application service provider attempting to verify a user's/device's identity and having a trust relationship with an identity provider. OP is an OpenID provider in the OpenID protocol or an identity provider who may authenticate the user and/or device on behalf of an application service provider. GW is a Gateway, such as an entity controlling internet traffic between connected entities for example. BA is a browsing agent. U is a generic mobile user. UE is a generic mobile user's mobile device.

Local Mobile SSO is a term used to collectively indicate methods whereby part or whole of the single sign-on (SSO) and/or related identity management functions traditionally performed by a web-based SSO server may be performed locally on the device. The Local Mobile SSO may be performed by a locally-based entity and/or module, which may be a part or whole of the communicating device itself for example. The locally-based entity/module may be physically and/or logically located (i.e., locally located) in close vicinity of the communicating device and/or its user (e.g., where such entity/module is embedded in the device, or attached or connected by local interfaces or wiring or short-range wireless means to the device).

Local OpenID is a term used to indicate a subset of Local Mobile SSO whereby the SSO or identity management may be based on the OpenID protocol. The part or whole of the functions of an OpenID Identity Provider (OP or OpenID IdP) may be performed by the locally located entity/module.

Local OP is a term used to indicate the entity or module that performs the part or whole of the functions of an OpenID server. The local OP may be a local IdP that is implemented using an OpenID protocol. While the term local OP may be implemented in embodiments described herein, it will be understood that the local IdP may be used in similar embodiments that do not implement the OpenID protocol. OPloc may also be used to denote a local OP. One of the functions of a local OP may be to facilitate authentication of the user and/or the wireless communications device through assertion(s) about the identity of the user and/or the device. Such an assertion may be sent from the local OP to the device (e.g., at the device's browser agent) which may forward the assertion to the external Relying Party (RP). When the function(s) provided by a local OP are primarily limited to providing such identity assertion, a local entity performing such function(s) may be called a local Assertion Provider (LAP).

A local OP may process (e.g., create, manage, and/or send) one or more assertion message(s). The local OP may use these messages to assert to the state of verification of one or more identities relating to a user and/or a device. This assertion may be made to one or more external recipient of such messages. A third-party entity, such as a Relying Party (RP) for example, may be one of the recipients of such assertion message(s). The local OP may sign such assertion messages, such as by using a cryptographic key for example.

Local OpenID methods may use one or more cryptographic keys. One such key, which may be called a root session key and may be denoted by Krp, may be a session key intended for use between the RP and the OP to serve as a root session key out of which other keys may be derived. Another such key, which may be called an assertion key and denoted by Kasc, may be the signing key which may be used to sign one or more of the assertion message(s) for authentication of the user. Kasc may be derived from the Krp.

Local OpenID may also be implemented using a service called OpenID Server Function (OPSF), whose role may be to generate, share, and/or distribute secrets to be used by the local OP and optionally by the Relying Party (RP). The OPSF and the local OP may be viewed by the external RP as a single entity. The OPSF may be able to verify signatures issued by the local OP, and may be directly reachable for the RP via public internet or other wired or wireless communication for example. The device (e.g., via its browser) may be redirected to the local OP, such as by modifying the local DNS resolving cache on the device such that the address of the OPSF may map to the local OP for example. Local OpenID may also use a service denoted by OP-agg, whose role may be to facilitate discovery of local OP on behalf of the RP.

The aforementioned terms and descriptions may be referenced in the embodiments described herein. While the embodiments herein may be described using OpenID terms and/or portions of the OpenID protocol, it will be understood that these embodiments are not limited to the use of OpenID protocol or OpenID entities.

According to an example embodiment, as further described herein, a mobile communication device, such as a smart phone for example, may communicate using layered communications. The mobile communication device may establish communication at an access layer, such as with an access-layer network for example. The mobile communication device may also establish communication at an application layer or access layer, such as with an application service provider and/or such provider's application-layer network or access network respectively. At each layer the communications may each have their own security. Such layer-specific security may implement authentication and/or security key agreement at each layer. Authentication and/or security key agreement at the higher layer, such as the application-layer for example, may utilize security keys and/or other security-related information, such as security association contexts at a lower layer for example, to derive the keys or other security-related parameters for the application-layer. Such techniques may be referred to as bootstrapping techniques for example.

According to an example embodiment, when the mobile device switches its access-layer communication from one access network to another, such a process may be referred to as an access-layer handoff. Access-layer handoffs may occur due to movement of the communicating device for example. Access-layer handoffs may occur between one access-layer node, such as a base station for example, in an access-layer network to another such node, such as another base station for example. The two access-layer nodes may be in the same network, between one access-layer network and another, or in a different access-layer network for example. It may be desirable for access-layer handoffs to be transparent to the user of the mobile communicating device. It may also be desirable for the access-layer handoffs to be non-interruptive to perform continuous, smooth operation of application-layer communication.

Application-layer security credentials may be used to help establish access-layer security, such as during an access-layer situation for example. According to an example embodiment, a delegated authentication, which may implement OpenID for example, may be performed at the application-layer to aid discovery and/or attachment at the access of the subsequent network during handoff.

According to an embodiment, bootstrapping may be used. Access-layer security keys may be derived out of security material available at the existing application-layer communication. For example, the access-layer security keys may be derived out of security material established using a delegated form of authentication, such as GBA or OpenID for example.

According to another embodiment, reverse bootstrapping may be used. Access-layer security keys may be derived out of security material available at the existing application-layer communication. For example, the access-layer security keys may be derived out of security material established using a delegated form of authentication, such as OpenID for example.

A local assertion provider may also be used when performing authentication as described herein. For example, a local OP may be used as part of the OpenID protocol used at the application-layer. The local OP may facilitate seamless authentication and/or key agreement during an access-layer layer handoff. Access-layer authentication and/or key agreement as well as access-layer authorization may be enabled during a seamless handoff.

The processor118may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and/or the like. The processor118may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU102to operate in a wireless environment. The processor118may be coupled to the transceiver120, which may be coupled to the transmit/receive element122. WhileFIG. 1Bdepicts the processor118and the transceiver120as separate components, it will be appreciated that the processor118and the transceiver120may be integrated together in an electronic package or chip. The processor118may perform application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or communications. The processor118may perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.

The communications systems and/or devices described above may be used in authenticated handoff scenarios as described herein. Authenticated handoffs may enable a user to use a service and/or application, continuously, while the user changes between access networks and/or access points in the same, or a different, access network. The handoff decision may be performed at the access layer and/or the application layer for example. This may mean that an authentication on each layer may occur in each handoff, and/or that the user device may be pre-provisioned with credentials for the target network/access point. This may call for a centralized infrastructure and/or credential pre-provisioning. An independent delegated authentication entity may be used to avoid the establishment of multiple service level agreements (SLAs) with mobile network operators (MNOs) or a tight coupling with the MNO authentication infra-structure in facilitating seamless authentication while roaming across multiple forms of networks. A federated identity management scheme, such as OpenID for example, and/or access to the Internet may be supported by the authentication embodiments described herein.

One example of a device performing an access layer handoff using pre-provisioned credentials is illustrated inFIG. 2, where a device215switches between two access networks.FIG. 2is a flow diagram illustrating a handoff scenario for an application layer session. The handoff scenario illustrated inFIG. 2includes device215, that includes or is in communication with an application214capable of communicating on an application layer and access layer module216capable of communicating on an access layer. The handoff scenario illustrated inFIG. 2may also include an MNO A217, a Hotspot B218, and an application server219. The MNO A217and/or the Hotspot B218may be enabled with OpenID server functionality capable of delegated authentication server in their application layer functions. The delegated form of authentication method may be OpenID for example. Therefore, MNO A217may be denoted as MNO OpenID Provider (OP) A217(that is, this entity may have an MNO A's access-layer functionality as well as an OpenID server functionality) and/or Hotspot B218may be denoted as Hotspot OP B218. The device215may communicate with MNO A217and/or Hotspot B218via access layer module216. The device215may also communicate with the application server219via application214.

As illustrated inFIG. 2, the device215may switch between a cellular network, from a Mobile Network Operator (MNO) A217for example, and a femto or WLAN network, such as a Hotspot B218for example. The device215may use access layer credentials220that are bootstrapped on the device application and/or network application server219to create application layer credentials221for authentication at the application layer. The device215may then attach to a subsequent network (e.g., WLAN network) at Hotspot B218and perform authentication using pre-provisioned credentials222between the device215and the Hotspot B218.

As shown in the handoff scenario illustrated inFIG. 2, at201the device215may discover the access network of MNO A217. The device215may attach and/or authenticate to the access network of MNO A217at202and203, respectively. For example, the device215may attach and/or authenticate to the access network of MNO A217via the access layer module216. The device215may authenticate to MNO A217using authentication credential220. The authentication credential220may be a pre-provisioned credential between the device215and the MNO A217for example. If the authentication at203is successful, the device215and the access network of MNO A217may set up secure access layer communication via access layer module216at204.

The device215may use the MNO A217network to attempt to login to the application server219to access services from the application server219. For example, an application214on the device215may log in to the network-based application server219at205. The application server219may act as a Relying Party (RP) and the MNO A217may act as an OpenID Identity Provider (OP). For example, at206the application server219may discover MNO A217and/or request MNO A217to authenticate the user. The request and/or authentication may be performed using OpenID for example. At207, between the device's application214and MNO A217, acting as an OP, application-layer authentication credentials221may be bootstrapped (e.g., generated or derived) from the access-layer credentials220that had enabled access-layer authentication for the device's access layer module216to the access layer of MNO A217. The device215and/or its application214may be redirected to MNO A217and may authenticate to the MNO A217at the application-layer at208using the application-layer authentication credential221boot-strapped from the access-layer credentials220. The bootstrap of the credentials221at207may be performed as a part of the authentication at208or independently. MNO A217may assert the authentication status of the device215to the application server219that is acting as a relying party (RP) (not shown). Secure communication at the application layer may be established between the device's application214and network-based application server219at209.

At210the device's access-layer module216may discover Hotspot B218. Hotspot B218may be a node on a WLAN and may also enable the device215to access services on the application server219. According to an example embodiment, the device215may discover the Hotspot B218when it comes into range of the Hotspot B218's servicing area. The device215may attempt to attach to the Hotspot B218based on user preferences, application requirements, Hotspot conditions, and/or service provider policies stored on the device215. At211, the device215may attach to the Hotspot B218at the access layer via access-layer module216. According to one embodiment, the application-layer connectivity that is set up at209may survive the subsequent access-layer attachment (to Hotspot B218) that occurs at211.

At212, the device215may use credentials222to authenticate to the Hotspot B218via access-layer module216. The credential222used at212may not have anything to do with the credentials220or credentials221used for authentication at203and208respectively. Therefore, at212the authentication to device215may use pre-provisioned access-layer credentials222that may be suitable for authentication to the subsequent target access network (e.g., Hotspot B218). If authentication is successful at212, the device215and Hotspot B218may establish secure communications at the access layer at213.

As described above,FIG. 2illustrates an authentication protocol for enabling a device215to perform handoffs and/or access layer authentication on subsequent networks using pre-provisioned credentials222. Various implementations are also described herein for leveraging persistent credentials such as access-layer or application-layer credentials for handoff to complete the authentication and/or secure tunnel setup at other layers (e.g., access layer) in an on-demand and seamless fashion.

According to an example embodiment, the application-layer credentials may be leveraged to generate access layer credentials (e.g., by performing a reverse boot-strap of the application-layer credentials) that may be used in a follow-on subsequent access-layer authentication procedure. As illustrated inFIG. 3, a handoff scenario may implement reverse bootstrapping of application-layer credentials331to perform authentication at a subsequent network. The handoff scenario illustrated inFIG. 3includes device321, which includes or is in communication with an application320, capable of communicating on an application layer, and access layer module322, capable of communicating on an access layer. The access layer module322may include and/or be in communication with a connection manager (CM) on the device321. The handoff scenario illustrated inFIG. 3also includes an MNO A323, a Hotspot B324, and an application server325. The MNO A323may communicate with other network entities via access layer326and/or application layer327. MNO A323may act as an OpenID provider. The Hotspot B324may communicate with other network entities via access layer328and/or application layer329. The Hotspot B324may act as a Relying Party (RP). The access layer module322may communicate with MNO A323access layer326and/or Hotspot B324access layer328. The application320may communicate with the application server325, MNO A323application layer327, and/or Hotspot B324application layer329. The application server325may also act as the Relying party (RP) according to some embodiments described herein.

As illustrated inFIG. 3, application layer credentials may be generated and reverse bootstrapped to generate access layer authentication credentials333for authentication with a subsequent access network Hotspot B324, such as in a handoff scenario for example. Reverse bootstrapping may include the application layer authentication by MNO A323on behalf of the target access-layer network Hotspot B324to generate material to be used to generate subsequent access-layer authentication credentials333. Reverse-bootstrapping may be conditioned on at least one of: 1) the identity of the user/device321in the source network MNO A323, and/or 2) the application-layer identity (e.g., an OpenID identity) of the user/application320as regards to the application server325or MNO A323for example.

A previous successful application layer authentication by MNO A323may be used to authorize access to the network Hotspot B324. Additional authentication information may also be provided to the network Hotspot B324to aid in access-layer authentication of device321. For example, the application layer authentication may be used to authorize access to the network Hotspot B324when assertions (e.g., “user comes from network MNO A323and is authenticated”) are provided to network Hotspot B324.

According to one embodiment, a call flow may be provided as illustrated inFIG. 3. At301-309call flows may set up an access layer security association and an application-layer security association using an application layer bootstrapping procedure, which may bind the access layer credentials to the OpenID process. For example, the access layer security association may be established between the device321and the MNO A323at301-304. At301, the access layer module322may discover the MNO A323network via access layer326. The access layer module322may attach to MNO A323at302and perform authentication at303. The access layer authentication at303may be performed using access layer credentials330that are shared between the device321and the MNO A323. The access layer credentials330may be pre-provisioned credentials or credentials established by reverse bootstrapping the application-layer credentials from another network as described herein. If access-layer authentication is successful between the device321and the MNO A323, a secure communication on the access layer326may be established at304between device321and the MNO A323.

The application layer security association may be established between the device321and the application server325at305-309. For example, at305the application320may attempt to login to application server325. At306, the MNO A3230P server may be discovered by the application server325via application layer327and the application server325may redirect the user/device321to the MNO A323for authentication. The MNO A3230P may authenticate the user/device321and/or assert authentication for the user/device321to the application server325at306. The user/device321may then be redirected to the Hotspot B324.

At307, between the application320and MNO A323, application-layer credentials331may be bootstrapped (e.g., generated or derived) from the access-layer credentials330that had enabled access-layer authentication between the device321and the MNO A323and/or the authentication assertion from MNO A323. The application320and the application server325may setup an application layer security association at308using the application-layer credentials331. The application layer security association at308may result in application layer credentials shared between the application320and application server325. The bootstrapping of credentials331at307may be performed as part of the application layer security association at308or independently. Secure communication at the application layer may be established between the device's application320and network-based application server325at309.

At310, the device321may discover Hotspot B324. For example, a local component on the device321, such as the access layer module322for example, may discover Hotspot B324, and/or its identification information (e.g., an SSID or an IP address). Hotspot B's application layer329may be discoverable, and may have been discovered and/or reached using access-layer328network discovery information, such as its IP address, via the public Internet for example. The access layer module322may include a connection manager (CM), that may be implemented in discovering Hotspot B324and/or making connection decisions. Hotspot B324and/or its identification information may be discovered via access layer signaling, such as a beacon channel for example. Some discovery may be performed based on the relationship between the MNO A323, Hotspot B324, and the discovered information about Hotspot B324from the device321. Based on the discovered information (e.g., strength of signal, location, etc.) from Hotspot B324, the access layer module322on the device321may decide that the device321should switch to the Hotspot B324for network communications. The access layer module322may communicate this command to the device's application320. For example, the CM may send the application-layer network discovery info to the device's application320at311.

The device321may be configured in such a way that the transfer of bootstrap credentials (e.g., generated using a key derivation process) between the application-layer and access-layer is feasible. The application320may process the network discovery information to generate an identity suitable for the access-layer network. According to one embodiment, the identity suitable for the network's access layer may be the OpenID URL or email address login of the user/device321that may be further processed/manipulated (e.g., hashed to a unique user/device identity) to a format suitable for identification to the Hotspot B324on the access layer328. Optionally, information elements such as a nonce or sequence counter value may be mixed into the hashing and/or some of these information elements may be communicated to the Hotspot B324. The device's application320may determine the suitable access-layer identity based on its application-layer identity established at308and/or Hotspot B324's access layer discovery information. The access-layer identity may be bound to the application-layer identity and sent to the access layer module322at312for a subsequent transmission.

At313, the device321may attach to the access layer328of Hotspot B324using the access-layer suitable identity, and the device's access layer module322may relay the access-layer identity suitable for that network's access layer to Hotspot B's access layer328. The access layer identity of the device321may then be passed to the Hotspot B's application layer329at314to inform the application layer329so that it can identify the device321by its access layer identifier. The application layer329of the Hotspot B324may be physically separated from the access layer328but logically associated. At315, the application320of the device321may send application-layer identity information, and optionally the access layer identity, to the Hotspot B's application layer329. This application-layer identity may be provided to logon to the Hotspot B324for example. The application-layer identity may be bound to the access-layer identity of device321.

When the application-layer identity and the access-layer identity information are communicated via the application layer329, the application-layer identity and/or the discovered Hotspot B324information may be used to perform OpenID-based discovery of MNO A323at316. The sending of identity information at315may occur at the same or a different time as call flows313to314for example. Examples of the application layer identity information may include the OpenID URL or email address login identity or assertion for example. The identity information may also include supplemental information of the user/device321.

The Hotspot B324may consolidate and/or correlate (e.g., at the access layer) both the access-layer identity information received from its access layer328and the bound application-layer identity and access-layer identity information received from the application layer329. The Hotspot B324may determine whether the messages received at313and315are from the same user/device321. For example, at the application layer329, the Hotspot B324may identify the application-layer identity received at315as being bound to the access-layer identity received at314. After confirming that it is talking to the same user/device321on its access layer328and its application layer329, the Hotspot B324may act as an RP together with the MNO A323, acting as an OP. The Hotspot B324may perform discovery of the MNO A323and the MNO A323may be directed to the user/device321for authentication (e.g., by running an OpenID protocol) at316. The device application320may authenticate with the MNO A application327(e.g., at the OP at the application layer327). Subsequent to a successful authentication, the device321may be redirected back to the Hotspot B324application329. At317, the Hotspot B324and the device321may each generate an access-layer credential333from the successful application layer authentication using a key derivation function. For example, the application320and the application layer329of Hotspot B324may perform a reverse bootstrapping procedure at the application layer, which may allow the user/device321and/or Hotspot B324to create access-layer credentials333. Thus, the access-layer credentials333may be a by-product of the application-layer authentication procedure performed at316. These access-layer credentials333may be sent to the access layer module322of the device321and/or the access layer328of Hotspot B324. At call flows318and319, using the access-layer credentials333generated at the application layer, the device321and Hotspot B324may perform authentication and set up an access-layer secure association for communication. After authentication, the access-layer credentials333may be stored and/or associated with the user/device321when it subsequently attempts to authenticate with the Hotspot B324at the access layer328.

According to an embodiment, a user with a mobile device321may connect to MNO A323. The user may authenticate to a service provider, such as a video service provider for example, with a bootstrap authentication procedure. This authentication may use the pre-provisioned access layer credentials330on the device321, using any of various techniques that are known to a person of ordinary skill in the art, as long as credentials are bootstrapped as illustrated at307inFIG. 3, which may uniquely associate the application layer identity to the network identity. The MNO A323may act as an OpenID provider. The Hotspot B324may act as a Relying Party (RP). According to an example embodiment, while accessing the service, such as viewing the video from the video service provider for example, the user may move in reach of a Hotspot B. Network Hotspot B may provide, for example, higher bandwidth at lower cost, and/or may be affiliated with, for example, an OpenID network (or associated with MNO A323or another MNO for example). The user may be in principle allowed to access the affiliated OpenID network (or associated MNO A323). For example, the user may prove that the user is associated with the OpenID provider, MNO A323.

The device321may discover the subsequent network Hotspot B324, such as by listening to the beacon and/or broadcast messages for example, and/or ascertain information about the subsequent network. The information may be passed on, through a connection manager (CM) for example, from the access layer module322to the application320which may use this information to contact Hotspot B324at the application layer329with the user/device321application-layer identity. The device321may send identity information over the access layer322and328to Hotspot B324.

When the identity information is communicated via the access layer328, but not the application layer329, the user/device321identity information may be passed up to the application on the Hotspot B324, as illustrated at314for example. The Hotspot B324may format the information in a manner suitable for OpenID-based discovery of the MNO A323. The identity information may be sufficient for the Hotspot B324to discover the MNO A323and/or attempt to authenticate the requesting user/device321at316. The Hotspot B324, which may be acting as a Relying Party for example, may run the OpenID protocol to redirect the user/device to be authenticated by the MNO A323. The MNO A323, which may be acting as an OpenID server for example, may run the OpenID protocol to authenticate the user/device321. If the user/device321is successfully authenticated, then Hotspot B324may establish a secure connection between the device321and the network at319.

The Hotspot B324and user/device321may create shared credentials based on the successful OpenID based authentication. For example, the user/device321and/or Hotspot B324may reverse bootstrap subsequent access layer credentials333. Some discovery may be done based on the relationship between the Hotspot B324and the MNO A323. This information may be obtained via the user/device321application-layer identity and/or discovered Hotspot B324information from the application320on the device321. If the user/device321is authenticated by MNO A323, then a secure connection may be established between the device321and the network through (reverse) bootstrapping of credentials from the Hotspot B324application to its access network.

According to one embodiment, for Hotspot B324to reverse bootstrap access-layer credentials333from application-layer credentials331, the Hotspot B324may have a capability where its access-layer functions and application-layer functions are designed such that cross-layer communication and data manipulation/processing is possible and/or where there is a relationship between the layers. The reverse bootstrapping may occur seamlessly to the user without the need to pre-provision or install credentials332in the device321for the subsequent network Hotspot B324and/or manual intervention.

The embodiments described herein for performing authentication at an access layer of a subsequent network may have remarkable properties at the user level. For example, a user may enter a user or device identifier (e.g., OpenID identifier) to log on to a service and the user may be able to access previously unknown access networks (e.g., the Hotspot B324) while the service may continue seamlessly uninterrupted. Authentication credentials, such as access layer credentials333for example, may not be pre-provisioned at the subsequent network since they may be reverse bootstrapped from the already running application service security or from the application layer authentication. The service may be fixed wire and/or wireless. The service may even be an isolated access point (AP) at a user's home that may be reachable via the public Internet and/or similar access means for example.

According to an embodiment, if application-layer security is to be re-established after a handoff (e.g., access-layer handoff), forward bootstrapping that binds security credentials for such subsequent application-layer authentication to security credentials established at various previous instances (e.g., credentials used in the handoff access layer authentication, credentials used in previous application-layer authentication, or even credentials used in access-layer authentication before the handoff) may be used.

In the embodiments described herein, an independent identity provider may be used. For example, the MNO A323may not be an OpenID Identity Provider and/or the identity management function may be performed by another third party. The third party identity provider may play the role of an OpenID provider using a pre-established relationship with the MNO A323, and use a protocol such as OpenID/EAP-SIM or OpenID/GBA bootstrapping capability for example, to authenticate and bootstrap application-layer credentials331from the MNO A323provisioned access layer credentials330. The same, or similar, bootstrapping process may be used later to bootstrap access layer credentials333for the Hotspot B324utilizing the MNO A323provisioned credentials on the device321.

According to another embodiment, a network-initiated handoff may be implemented. In a network-initiated handoff, the handoff may be initiated by a network, such as an access network or application server for example. In one example, the MNO A323may continually monitor the device321, which may include such information as the device's location, measurement information, quality of service, and/or the like. The MNO A323may be aware of the local environment around the device321. If the MNO A323is also an OpenID provider, the MNO A323may send a message to the user/device at the application layer to instigate a handoff with Hotspot B324, with appropriate parameters to enable the device321to discover and initiate a handoff. A seamless handoff may be performed as described herein. In another embodiment, the MNO A323may send the handoff trigger information to the device321via the access layer communications with the device321.

According to another embodiment, the MNO A323may place a request to the nearby local access node(s) to attempt to attach and/or authenticate with the device321when the device is in range of the node. It may not be the MNO A323which triggers the handoff. Any network component with sufficient information about the device321, the device's local communications environment, and/or an entity having the ability to communicate with the user/device321may be able to trigger the handoff. In these cases, the network component may discover the subsequent access network (e.g., Hotspot B324) and/or negotiate security capabilities and radio access capabilities for communication to the user/device321. The network component may communicate this information as well as the handoff information to the user/device321.

According to another embodiment, an application-assisted credential bootstrapping may be performed. In application-assisted credential bootstrapping, the application320on the device321may tell the application server325that the application server325may bootstrap a set of credentials for the subsequent access network Hotspot B324with the help of the application320to facilitate the handoff. The application320may send the identity relating to the discovered Hotspot B324, such as an IP address for example, and optionally its OpenID login-like request, to the application server325. The application server325may act like an OpenID provider to negotiate security capabilities of the Hotspot B324. The application server325may reverse bootstrap a set of access-layer credentials333for the Hotspot B324and the device321at the access layer. The application320on the device321and Hotspot B324may authenticate with each other and/or establish a secure channel as illustrated at318. Some discovery may be performed based on the relationship between the application server325and the target Hotspot B324. This information may be obtained via the discovered information from the application320on the device321.

The credentials for a subsequently discovered network authentication may be pre-processed at both endpoints to enable faster completion of the authentication procedures later. This may be based upon knowledge that the network holds of the local area where the device is located or in which the device is moving towards. If pre-configured on the device to look for handoff opportunities, the device may at some periodic frequency search for alternate networks and, if detected, seek a handoff. The pre-processing on the network side may be carried out at or for more than one alternate access node. The device and/or network may cache credentials used for the networks it has used previously. The device and/or network may later re-use these credentials for authentication. This re-use of credentials may be useful when a device returns to a node which it had left earlier for example. The re-use of credentials may also be useful for alternative dynamic selection of one or more nodes (e.g., in a locally dynamically varying noisy channel or quality of service environment).

The embodiments described herein may use local OpenID. For example, a standalone local OpenID may be implemented. As described herein, a protocol flow may utilize a local OpenID and grant access/authorization.

FIG. 4is a flow diagram illustrating protocol realization using standalone local OpenID. As illustrated inFIG. 4, the flow diagram may include communications between a local IdP432, an application433(e.g., a browsing agent), an access layer module434, an MNO435, a hotspot436, and/or an application server437. The local IdP432may be located on a user's wireless communications device. The application433and/or the access layer module434may be located on the same, or different, wireless communication device as the local IdP432.

The protocol illustrated inFIG. 4enables seamless handoff and/or set-up of a subsequent access-layer security association. The protocol may implement access-layer security between the device and the device's current access-layer network and/or application-security previously established between the user/device and an external application server (AS)437, such as by using a client-localized OpenID (i.e., local OpenID) protocol for example.

As illustrated inFIG. 4, the device may be authenticated at the application layer with the application server (AS)/RP437using a combination of steps401-419and the device may be authenticated with a subsequent network (e.g., hotspot436) at the access layer using a combination of steps419-431. At401a device access layer module434may attach to the MNO435. The device's access layer module434and MNO435may use shared credentials to authenticate. As a result of authentication, access-layer key K may be established on the device's access-layer module434and/or the MNO435. At402, the access layer key K may be stored on the device. For example, the access layer key K may be stored on a trusted environment on the device, such as a subscriber identity module (SIM) card, a universal integrated circuit card (UICC), trusted platform module (TPM), or other trusted environment for example. The trusted environment may be included on the device, or connected to the device as a separate module or a separate device/equipment for example. The trusted environment may include the local IdP432. According to an example embodiment, the trusted environment and the local IdP432may be the same entity. However, the trusted environment may also include the application433, access layer module434, and/or other entities located on the device for example.

At403, MNO435and device access layer module434may both derive an application-layer key K_app from access layer key K (i.e., K_app=f(K), where f is some function known to both the MNO435and the device's access layer module434). Application-layer key K_app is made available to local IdP432. Access-layer security association is established between the device access layer module434and MNO435using access-layer key K at404.

At405, a user may login, via application433, to application server (AS)437. The user may login with an OpenID provider (OP) identifier (e.g., URL or email address) for example. The AS437may be acting as a Relying Party (RP), and thus may be referred to herein as AS/RP437. At406AS/RP437may perform identity discovery of MNO435. At407an association between MNO435and AS/RP437may be setup and an association handle may be generated. MNO435may derive a session key K_session from application key K_app and the association handle at408. At409, K_session may be passed to AS/RP437using an association security protocol and K_session may be used as a subsequent association key. At410, AS/RP437may store session key K_session and the subsequent association information. Application433may be redirected on the device at411to authenticate with the local IdP432. The redirect message may include the session nonce and/or association handle. At412, the application433may request connection to local IdP432through card access layer module434. The request may include the session nonce and/or association handle for example. At413, redirection to local IdP432may be performed. The redirection may also include the session nonce and/or association handle. At414, local IdP432may derive a signing key K_session using application-layer key K_app and the association handle. Local IdP432may have access to application-layer key K_app on the device. Local IdP432may create an OpenID assertion message, and sign it using K_session at415. At416, local IdP432may redirect the signed OpenID assertion message back to the device's access-layer module434through card access. The device's access-layer module434may transparently redirect the signed OpenID assertion to the device's application433at417. The device's application433may redirect the signed OpenID assertion message at418, along with the nonce received in step411, to the external AS/RP437. AS/RP437may store the received signed assertion message at419.

Once the device is authenticated at the application layer with the AS/RP437, the device may be authenticated with a subsequent network (e.g., hotspot436) at the access layer using credentials or keys from the application-layer authentication. As illustrated inFIG. 4, at420the access layer module434of the device may discover the hotspot436. A local entity (e.g., connection manager (CM)) on the device may decide that the device should switch to the discovered hotspot436. At421, the device's access layer module434may pass hotspot436information to the device's application433. At422, the device's application433may pass the OpenID identifier (e.g., URL or email address), along with the last used application server437identification, to the access layer of the hotspot436for subsequent discovery. The device's application433may alert the AS/RP437with initiation of handoff at423. The initialization of the handoff at423may be performed using the discovered hotspot436information. The device's application433may determine the access-layer suitable identity based on its application-layer identity established at418and/or Hotspot B436's access layer discovery information. The access-layer identity may be bound to the application-layer identity and sent to the access layer module434at422for a subsequent transmission.

As illustrated in steps424-429ofFIG. 4, the AS/RP437may facilitate access layer authentication of the device. For example, the AS/RP437may forward assertion messages to the access layer module434. The MNO435may verify the assertions, thus assuring the identity for the access layer. At424, the device's access layer module434may issue a login request to the hotspot436. Included in this message may be the OpenID identifier (e.g., URL or email address), as described at422for example, and/or the last application server used identification. At425, the hotspot436may request authentication information for the device and its user from the AS/RP437. For example, the hotspot436may request an assertion for the OpenID identifier (e.g., URL or email address) that it has received from the access layer434of the device. At426, the AS/RP437may return the signed assertion message, which was received by the AS/RP437at step418and which corresponds to the OpenID identifier received in step425, to the hotspot436. At427, the hotspot436may request signature verification from the OpenID service in the MNO435, for the signed assertion message corresponding to the OpenID identifier (e.g., URL or email address). At428, the MNO435may verify the signature (e.g., at the OpenID server). MNO435may have session key K_session from step408. The MNO435may provide (e.g., using its OpenID server) a signature verification message to the hotspot436at429.

If the authentication was successful, the hotspot436may send authentication success acknowledgment at430to the access layer module434of the device. The device's access-layer module434and hotspot436may setup an association at431to secure their common channel. Derivation of symmetric key structure may secure communication. At step431of the protocol illustrated inFIG. 4, various alternative methods, known to a person of ordinary skill in the art, may be used for deriving an access-layer key/credential. For example, a key derivation function may be used on a signature-verified application-layer assertion message.

The implementation of reverse bootstrapping may be explicit or implicit as described herein. For example, the protocol illustrated inFIG. 4may implement reverse bootstrapping implicitly. Reverse bootstrapping may be performed implicitly when the access-layer security association is envisioned to be established based on assertions provided from the application layer, rather than explicitly deriving access-layer keys and/or credentials directly from application-layer credentials for example. Explicit reverse bootstrapping may occur when an access-layer key is derived via an explicit process of reverse bootstrapping, such as directly from application-layer credentials for example.

According to another embodiment, a protocol may enable seamless handoff that also grants access/authorization. For example,FIG. 5is a flow diagram illustrating a protocol that enables seamless handoff using implicit reverse bootstrapping that also grants access/authorization. Use of the protocol illustrated inFIG. 5may enable the hotspot536to obtain access-layer handoff and authorization for access to services or user's private data for example.

As illustrated inFIG. 5, at501a device's access-layer module534may attach to the MNO535, such as at the access-layer for example. The device's access-layer module534and the MNO535may use shared credentials to perform mutual authentication. The shared credentials may be access-layer shared credentials for example. As a result of authentication, access-layer key K may be established on both the device's access-layer module534and the MNO535, such as at the MNO's access layer for example. At502, the access-layer key K may be stored on the on the device. For example, the access layer key K may be stored on a trusted environment on the device. The trusted environment may be included on the device, or connected to the device as a separate module or a separate device/equipment for example. The trusted environment may have local IdP532functionality. The trusted environment may be the same entity as the local IdP532, as illustrated inFIG. 5.

At503, MNO535and/or device access layer module534may derive application-layer key K_app from access-layer key K (i.e., K_app=f(K), where f may be some function known to both the MNO535and the device's access layer534), where K_app may be made available to local IdP532. Access layer association may be established between device access layer module534and MNO535using K_app at504. A user may login at505to AS/RP537on the application layer via application533. For example, the user may login with OP identifier (e.g., URL or email address). At506, AS/RP537may perform discovery of MNO535. At507, association between MNO535and AS/RP537may be setup and an association handle may be generated. MNO535may derive K_session from K_app and the association handle at508. At509, K_session may be passed to AS/RP537, such as by using original association security and K_session as a subsequent association key for example. At510, AS/RP537may store K_session and the subsequent association information. Application533(e.g., BA) may be redirected by AS/RP537on the device to authenticate with local IdP532at511. The message may include the nonce and/or association handle. The application533may request connection at512to local IdP532through the access layer534. The request may include the nonce and/or association handle. At513, redirection to local IdP532is performed. The redirection message may also include the nonce and/or association handle.

At514, local IdP532may derive a signing key K_session (e.g., for signing assertion messages) using K_app and the association handle. Local IdP532may have access to K_app. Local IdP532may create an OpenID assertion message, and sign the assertion message using K_session at515. At516local IdP532, acting as provider of locally produced access/authorization token, may derive a signing key K_token. The signing key K_token may be later used to sign an access/authorization token. One way to derive such K_token may be by using a key generation function (KGF) which takes both K_app and K_session as inputs. For example, K_token=f(K_app, K_session). At517, local IdP532, acting as provider of locally produced access/authorization token, may create an access/authorization token, and/or sign it with K_token. Local IdP532may redirect the signed assertions (both the signed OpenID assertion and the signed access/authorization token) back to the device's access-layer through the access layer534(e.g., card access) at518. At519the device's access-layer534may redirect the signed assertions (the OpenID assertion and the access/authorization token) to the device's application533(in a transparent redirection). At520the device's application (e.g., BA) may redirect the signed assertions (the OpenID assertion and the access/authorization token), along with the nonce received at511, to the external application AS/RP537. The AS/RP537may store the received signed assertion message.

At521, the device may discover the hotspot536via its access layer module534. The connection manager (CM) on the device may decide that the device should switch to the discovered hotspot536. The device's access layer module534may pass subsequent hotspot information to the device's application533at522. At523, the device's application533may pass the OpenID identifier, along with the last used application server identification, to the hotspot536access layer. The device's application533may alert the AS/RP537with initiation of handoff to the discovered hotspot536at524. This may be done by the device's access-layer module534sending a login request, such as to the hotspot536for example. Included in this message may be the OpenID identifier and/or the access token. The application533may have this token from step519. The hotspot536may discover the MNO535's OpenID/OAuth server at525. At526, the hotspot536may request the MNO535's OpenID/OAuth server to authenticate the user/device and authorize access using the OpenID identifier and/or the signed access token. The MNO535's OpenID/OAuth server may compute the signing key K_token at527. The signing key K_token may be computed in the same way the K_token was computed in step516for example. At528, the MNO535's OpenID/OAuth server may verify the signature of the received access token using the K_token it has computed from step527. The MNO535's OpenID/OAuth server may send a positive assertion for the access-token, along with any additional identity information for the user/device, to the hotspot at529. At530, if the authentication is successful, the hotspot536may send an authentication success acknowledgment to the device at the access layer module534. At531, the device531's access-layer module534and the hotspot536may mutually set up a security association. Derivation of keys and/or secure communication may follow.

As described herein, application-layer credentials may be used to generate credentials used in a follow-on access-layer or IP-layer authentication in Universal Access Method (UAM)-based and/or Extensible Authentication Protocol (EAP)-based public hotspots, as described herein.

The implementation options for OpenID integration with UAM-based public hotspots may include various implementations in which different network entities may act as a relying party (RP) or an OpenID provider (OP). For example, a hotspot authentication, authorization, and accounting (AAA) server may act as an RP, a hotspot wireless local area network (WLAN) gateway may act as an RP, a hotspot captive portal may act as an RP, a hotspot access point (AP) may act as an RP (e.g., for a small hotspot, such as a hotspot used in a café), and/or a hotspot AAA server may act as an OP. Example embodiments of OpenID-UAM integration using a hotspot AAA server and a WLAN gateway that implement RP functionality may be illustrated inFIGS. 6 and 7. It will be understood that the other embodiments may be similar in implementation but have different deployment models.

According to an example embodiment, a user with a mobile device may connect to an MNO A acting as an OP server. The user may authenticate to a service with a bootstrap authentication procedure using pre-provisioned access layer credentials on the device. The bootstrap authentication procedure may uniquely associate the application layer identity to the network identity. By way of example, authentication may be performed using OpenID, but any other similar authentication protocol may be used. When OpenID is being implemented, the MNO A may act as an OpenID provider and/or a WLAN gateway at Hotspot B may act as a Relying Party.

After the device connects to the MNO A, the device may discover another network (e.g., by listening to the beacon or broadcast messages) and/or ascertain information about the newly discovered network at the access layer. The information may be passed on, through a connection manager (CM) for example, to the application on the device. The application on the device may use the information about the discovered network to contact a WLAN gateway at a Hotspot B at the application layer with the user/device identity. This identity information may be sufficient for an AAA server acting as RP, as illustrated inFIG. 6, and/or a WLAN gateway acting as an RP, as illustrated inFIG. 7, to discover the MNO A and attempt to authenticate the requesting user/device. An OP←→RP protocol may be run by the MNO A (acting as an OpenID server) and at least one of the WLAN gateway or the AAA server at Hotspot B (acting as a Relying Party) to authenticate the user/device. Once the user/device has been successfully authenticated, it may be allowed access to the Hotspot B. For example, inFIG. 6once the AAA server authenticates the user and sends an indication of successful authentication (e.g., an Access Accept message) to the WLAN gateway at Hotspot B, the user may be allowed access at the Hotspot B. Similarly, inFIG. 7once the WLAN gateway at Hotspot B authenticates the user/device, then it may be allowed access at the Hotspot B. This authentication may occur seamlessly to the user and/or without the need to pre-provision or install credentials in the device for authentication with the subsequently discovered network (Hotspot B) or manual intervention.

FIG. 6is a flow diagram illustrating UAM-OpenID integration with an AAA server617acting as an RP. As illustrated inFIG. 6, a UE614, an AP615, a WLAN GW616, an AAA server/RP617, and/or OP server618may perform communications to enable UE614to authenticate to a wireless network. A local component on the UE614(e.g., a CM) may discover a hotspot AP615based on its identification information (e.g., an “MNO-WiFi” SSID). The identification information may be discovered via access layer signaling, such as a beacon channel for example. The local component on the UE614(e.g., the CM) may decide that the UE614should switch to the hotspot and may communicate this command to the application layer of the UE614. The local component on the UE614may send the application-layer network discovery info to an application (e.g., browser) on the UE614.

As illustrated inFIG. 6, at601the UE614may associate with the open mode access point (AP)615. For example, the UE614may perform such association and/or open mode access using the identification information (e.g., “MNO-WiFi” SSID) obtained on the access layer. If the UE614is configured to get an IP address (e.g., using DHCP) the WLAN Gateway (GW)616may allocate a private IP address to the UE614at602. The user may not be able to access the Internet using the private IP address as the state of the UE614in the WLAN GW616may be set to “unauthorized.”

The user may open a web browser application on the UE614and at603the WLAN GW616may receive a request for a webpage (e.g., user homepage) from UE614. The WLAN GW616may redirect the browser on the UE614at604to a portal page (e.g., IP/URI) that prompts the user for login credentials. The user may enter its OpenID identifier (e.g., URL or email address) on the login page. At605, the WLAN GW616may receive the login credentials from UE614and the WLAN GW616may use the login credentials received to generate an access request message for the configured AAA server/RP617. The WLAN GW616may send the access request message to the AAA server/RP617at606.

The AAA server617, acting as an RP, may perform discovery and/or association with OP server618at607(e.g., using an OpenID protocol). At608, the AAA server/RP617may redirect UE614to the OP server618. The UE614may authenticate towards the OP server618at609(e.g., using OpenID credentials). The OP server618may redirect UE614to the AAA server/RP617at610with an authentication assertion. The UE614may present the assertion and an indication that it has been successfully authenticated to the AAA server/RP617at611.

At612, the AAA server/RP may send an indication of successful authentication (e.g., an Access Accept message) to the WLAN GW616and/or an indication to change the user/UE614status to an “authorized” state in the WLAN GW616. The WLAN GW616may indicate successful authentication to the user/UE614by redirecting the user's browser to a start page and enabling the user to access the Internet over the WLAN network at613.

By integrating OpenID RP functions into AAA server617, the AAA server617may not have to communicate with the HLR/HSS for authentication. Additionally, the user authentication may be secure as the user may be authenticated and/or access the WLAN GW/RP without sending its credentials to the WLAN GW/RP.

FIG. 7is a flow diagram illustrating UAM-OpenID integration with the WLAN GW714acting as an RP. As illustrated inFIG. 7, a UE712, an AP713, a WLAN GW/RP714, and/or OP server715may perform communications to enable UE712to authenticate to a wireless network to access a service. A local component on the UE712(e.g., a CM) may discover a hotspot AP713based on its identification information (e.g., an “MNO-WiFi” SSID). The AP713may be discovered via access layer signaling, such as a beacon channel for example. The local component on the UE712(e.g., the CM) may decide that the UE712should switch to the hotspot AP713and may communicate this command to the application layer of the UE712. The local component on the UE712may send the application-layer network discovery info to an application (e.g., browser) on the UE712.

As illustrated inFIG. 7, at701the UE712may associate with the open mode access point (AP)713. For example, the UE712may perform such association using “MNO-WiFi” SSID and/or open mode access. If the UE712is configured to get an IP address using DHCP, the WLAN GW/RP714may allocate a private IP address to the UE712at702. The user may not be able to access the Internet using the IP address. At this point, the state of the UE712in the WLAN GW/RP714may be set to “unauthorized,” so it may not be able to access services via the WLAN GW/RP714.

The user may open a web browser application on the UE712. At703, the WLAN GW/RP714may receive a request for a webpage (e.g., user homepage) from UE712. The WLAN GW/RP714may redirect the browser on the UE712at704to a portal page (e.g., IP/URI) that may prompt the user for login credentials. The user may enter its OpenID identifier (e.g., URL or email address) on the login page.

At705, the WLAN GW/RP714may receive the login credentials from UE712and the WLAN GW/RP714may use the login credentials received to perform discovery and/or association with the OP server715. At706, the WLAN GW/RP714, acting as an RP, may perform discovery and/or association with OP server715(e.g., using OpenID protocol). The WLAN GW/RP714may redirect the UE712at707to the OP server715. The UE712may authenticate towards the OP server715(e.g., using OpenID credentials) at708. The OP server715may redirect UE712to the WLAN GW/RP714at709. The redirect message at709may include authentication assertion information. The UE712may present the assertion information and/or an indication of successful authentication with the OP server715to the WLAN GW/RP714at710. Based on the received assertion information and/or the indication of successful authentication, the WLAN GW/RP714may change the user status to an “authorize” state. The WLAN GW/RP714may indicate successful authentication to the user/UE712by redirecting the browser on the UE712to a start page and user may be able to access the Internet over the WLAN network. At711, the user712may be enabled Internet access over the WLAN network.

By integrating OpenID RP functions into a hotspot WLAN GW714as illustrated inFIG. 7, a AAA server may not have to be used for authentication. The WLAN GW714may not use RADIUS functions. Similar to the embodiment illustrated inFIG. 6, the authentication implementation inFIG. 7may include secure authentication as the user may be authenticated and/or access the hotspot without sending its credentials to the WLAN GW714. In the implementation illustrated inFIG. 7, the WLAN service/hotspot provider may reach a large customer base, due to simplified authentication. For example, multiple OPs may be supported by one hotspot, allowing service to be provided to customers from multiple MNOs (e.g., acting as OP server715), while benefitting from the authentication infrastructure provided by the MNOs.

Also described herein are authentication embodiments that generate credentials (e.g., using reverse boot-strapping) from application-layer credentials for use in a follow-on access-layer or IP-layer authentication in EAP-based public hotspots. At the user level, a user may enter an OpenID identifier to log on to a service, and may be able to access previously unknown access networks, such as a Hotspot B for example, while the service continues seamlessly uninterrupted. The access-layer or IP-layer credentials may not be pre-provisioned at the subsequent access network, since these credentials may be bootstrapped from the already running application service security.

The authentication embodiments described using EAP-based public hotspots may include implementation options for OpenID integration. The implementation options for the OpenID integration with 802.1x/EAP public hotspots may include the use of a hotspot AAA server acting as an RP, the use of a hotspot AAA server acting as an OP, and/or using EAP-OpenID.

FIG. 8is a flow diagram illustrating EAP-OpenID integration with the AAA server820acting as an RP. The integration of the RP function into a hotspot AAA service may enable support of seamless authentication and/or service continuity, such as between 3GPP and WLAN networks for example. A user may be seamlessly authenticated in a public hotspot that integrates RP module into the AAA server820by: leveraging keys derived on the UE818and/or an OP server821to complete EAP-SIM/AKA authentication, using an active connection (e.g., 3GPP connection) to exchange OpenID authentication, and/or enabling a hotspot AP819to allow UE-OpenID exchanges.

As illustrated inFIG. 8, UE818and/or its user may be authenticated using communications between a UE818, an AP819, an AAA/RP server820and/or an OP server821. The UE818, the AAA/RP server820, and/or the OP server821may each include an application capable of communicating at the application layer. The UE818, the AP819, and/or the AAA/RP server820may each include an IP-layer communication module capable of communicating at the IP layer. The UE818and/or the AAA/RP server820may be configured to enable communications between its application and IP-layer communication module. The OpenID Identity Provider (OP) may be the MNO or an Application Service Provider associated with the MNO for example. The OP server821may serve multiple MNOs, allowing for a broad customer base to use hotspots. The AAA Server820may be implemented as an RP and may leverage keys822(e.g., derived at the application layer) on a UE818and/or an OP server821. According to an example embodiment, the application-layer keys822may be leveraged to complete EAP-SIM/AKA authentication.

As illustrated inFIG. 8, at801the UE818may successfully complete authentication towards the OP server821via access network communications (e.g., 3GPP access network communications). The UE818and the OP server821may establish shared keys822at801. The shared keys822may be application-layer credentials established at the application layer between the UE818and the OP server821for example. A local component on the UE818(e.g., a connection manager (CM)) may discover the AP819based on its identification information, such as an “MNO-WiFi” SSID for example, at802. The identification information of the AP819may be discovered via access layer signaling, such as a beacon channel for example. The UE818(e.g., implementing the CM) may decide that it should switch to the AP819for accessing services. The UE818may be an unauthorized client of the AP819network.

The AP819(e.g., authenticator) may issue an EAP request at803asking for the identity of the UE818. At804, the UE818may return an identifier, such as its permanent identity (e.g., international mobile subscriber identity (IMSI)), a pseudonym identity, a fast authentication identity, or other similar identifier of the UE818for example. The access-layer identifier may be returned with additional authentication information, such as its realm for example. The realm may include additional information for use in performing authentication, such as a hint to use a single sign-on (SSO) authentication (e.g., IMSI@sso.MNO.com) for example.

The AP819may send the access-layer identifier to AAA/RP server820at805. The access-layer identifier, and other communications between the AP819and the AAA/RP server820, may be sent using a RADIUS access request, access challenge, and/or access accept messages for example. The AAA/RP server820may send the access-layer identifier to the application layer on the AAA/RP Server820. Based on the access-layer identifier and/or operator policy, the RP function of the AAA server820may perform discovery and/or association with OP server821at806. The discovery and/or association may be performed using OpenID protocol for example. During discovery and/or association at806, the AAA/RP server820may send the access-layer identifier to the OP server821. For example, the access-layer identifier may be sent at the application layer between the AAA/RP server820and the OP server821. The OP server821may use the access-layer identifier and/or the application-layer credential822to generate keying material that may be used to authenticate the UE818at the AAA/RP server820. For example, the OP server821may use the access-layer identifier to determine the application-layer credential822associated with the UE818. The keying material may be derived from the application-layer credential822using a key derivation function. According to an example embodiment, the keying material may include a session key that may be used for authentication between the UE818and the AAA/RP server820. The OP server821may send keying material to the AAA/RP server820at807.

The AAA/RP server820may use the keying material received from the OP server821to send an EAP-SIM/AKA challenge to the UE818. The EAP-SIM/AKA challenge may be sent to enable a re-authentication procedure, without having to interface or communicate with the HLR/HSS for example. At808, the AAA/RP server820may send the access challenge to the AP819. The access challenge may include the identifier associated with the UE818and/or the keying material received at807. The AP819may send the EAP message received from the AAA/RP server820(e.g., EAP-request/challenge) to the UE818at809via the radio access network. After receiving the EAP-request/challenge message, the UE818may check the keying material to validate the message and generate an EAP response at810using the application-layer credential822. For example, the UE818may send the challenge to a trusted environment residing on the UE818(e.g., trusted processing module, UICC, SIM, smartcard, etc.) which may derive keying material from the application-layer credential822using a key derivation function. The keying material may be the same keying material generated at the OP server821using the application-layer credential. For example, the keying material may include a session key that may be used for authentication between the UE818and the AAA/RP server820. The keying material may be used to generate the response at810. The response may be generated at the application layer of the UE818and transmitted to the access-layer for transmission to the AP819.

The UE818may return the response in the form of an EAP-response message to the AP819at811using a re-authentication procedure for example. The response may include the UE identifier and/or the keying material (e.g., session key) generated at the UE818. The AP819may forward the EAP-response/challenge message to the AAA/RP server820at812, such as in the form of an access request message for example. The access request at812may include the EAP ID and/or the keying material from the UE818at811. The AAA/RP server820may validate the message received and/or check whether the response received matches the expected response at812and, if the checks are successful, the AAA/RP server820may indicate successful authentication and/or that the UE818may access services using the WLAN network. For example, the AAA/RP820may send an access accept message to the AP819at813. The Access Accept message may include an EAP success indicator and/or the keying material. The AP819may forward the EAP success indicator to the UE818at814. At815, the status of the UE818at the AP819may become authorized for use of the AP819. As the UE818is authorized, the UE818may obtain an IP address using DHCP at816. The UE818may access the Internet over the WLAN network at817using the IP address for example.

Using the call flow illustrated inFIG. 8, or portions thereof, the hotspot AAA server820may not have to connect to an MNO HLR/HSS to perform authentication using the EAP protocol. For example, by using OpenID as described herein, the AAA server820, or other RP entity for example, may avoid communication with an HLR/HSS, or other SS7 entity for example, for performing user authentication. Instead, the AAA server820may communicate with an internet protocol (IP)-based HTTP(S) interface, such as the IP-based HTTP(S) interface for OpenID for example.

FIG. 9is another flow diagram illustrating EAP-OpenID integration with the AAA server923acting as an RP. As illustrated inFIG. 9, UE921and/or its user may be authenticated for communication on a WLAN using communications between a UE921, an AP922, an AAA/RP server923, and/or an OP server924. The UE921, the AAA/RP server923, and/or the OP server924may each include an application capable of communicating at the application layer. The UE921, the AP922, and/or the AAA/RP server923may each include an IP-layer communication module capable of communicating at the IP layer. The UE921and/or the AAA/RP server923may each be configured to enable communications between their application and IP-layer communication module. According to an example embodiment, the AP922may be configured to allow OpenID exchanges for an unauthorized UE921in which the UE921may be able to reach and communicate with the AAA/RP server923and/or OP server924via the AP922.

In the embodiment illustrated inFIG. 9, there may not be fresh keys that have been previously shared between the UE921and OP server924, as illustrated inFIG. 8for example. Thus, the UE921and/or OP server924may perform authentication and generation of an application-layer identity key925. The AAA server923may be acting as an RP and may use a connection (e.g., 3GPP connection) to perform OpenID authentication. The UE921may be a device that is able to establish a connection with multiple networks simultaneously (e.g., UE921may be a multi-RAT device capable of establishing a connection via 3GPP networks and via WLAN hotspots simultaneously). As illustrated inFIG. 9, an established 3GPP connection may be used to exchange OpenID messages and complete the EAP-SIM/AKA authentication. WhileFIG. 9uses credentials established in an active 3GPP connection to perform authentication for communication over a WLAN, it will be understood that other forms of wireless connections may be used in a similar manner to perform authentication as illustrated inFIG. 9.

At901, a UE921may have an active 3GPP connection established and it may reach AAA/RP server923and/or OP server924over this connection. According to another example embodiment, the AP922may allow OpenID exchanges for authentication of the UE921, rather than using the 3GPP connection established at901. In either embodiment, the protocol flow may be the same, or similar, to that illustrated inFIG. 9. Continuing with the protocol flow ofFIG. 9, a local component on the UE921(e.g., a CM) may discover the AP922at902, and/or its identification information, such as an “MNO-WiFi” SSID for example. AP922may be discovered via access layer signaling, such as a beacon channel for example. The local component on the UE921(e.g., CM) may decide that the UE921should connect to the AP922. The UE921may be an unauthorized client at the AP922and may not have access over the network.

At903, the AP922(e.g., authenticator) may issue an EAP request asking for the IP-layer identity of the UE921. The UE921may return its IP-layer identity via an EAP response at904. The IP-layer identity of the UE921may include its international mobile subscriber identity (IMSI) and/or additional authentication information. The additional information may include the realm of the UE921for example. The realm may include additional authentication information, such as a hint to use SSO authentication (e.g., IMSI@sso.MNO.com) for example. The AP922may send the IP-layer identity (EAP ID) to the AAA/RP server923at905. The IP-layer identity, as well as other communications between the AP922and AAA/RP server923, may be sent using RADIUS access messages, such as RADIUS access request messages, RADIUS access challenge messages, and/or RADIUS access accept messages for example.

The AAA/RP server923may discover and perform association with OP server924at906. For example, the RP function of the AAA server923may perform discovery and association with OP server924using OpenID protocol. An application on UE921may send a login request at907to the AAA/RP server924which may act as a Relying Party (RP). The login request at907may be sent over a 3GPP connection with OpenID for example. The application on the UE921may send the login request based on an indication to initiate the communication from a local entity (e.g., the CM) on the UE921. Communicating with the UE921over a 3GPP wireless connection, the AAA/RP server923may redirect the UE921to the OP server924at908.

The UE921may authenticate (e.g., using OpenID credentials) with the OP server924at909over the 3GPP connection. For example, the UE may authenticate with the OP using OpenID credentials. Upon successful completion of authentication towards the OP server924, application-layer credentials925may be established on the UE921and/or OP server924. The OP server924may generate keying material based on the application-layer credential925. The keying material may be used for authentication between the UE921and the AAA/RP server923. The keying material may be derived from the application-layer credential925using a key derivation function. According to an example embodiment, the keying material may include a session key used for authentication using the AAA/RP server.

The OP server924may send the keying material based on the application-layer credential925to the AAA/RP server923at910. The AAA/RP server923may receive the keying material at the application layer and communicate the keying material to its IP-layer communication module for transmitting to the AP922. The AAA/RP server923may use the keying material to send an EAP-SIM/AKA challenge to the UE921, via the AP922, at911. The challenge may be based on a re-authentication procedure, wherein the AAA/RP server923may perform authentication without having to communicate with the HLR/HSS for example. The challenge at911may include the EAP ID and/or the keying material received at910. The AP922may receive the challenge at911and send the EAP message (EAP-request/challenge message) received from the AAA/RP server923to the UE921at912.

After receiving the EAP-request/challenge message at912, the UE921may generate a response using the application-layer credential925at913. The UE921may check the keying material received from the AAA/RP server and may send the challenge to a trusted environment (e.g., trusted processing module, UICC, SIM, smartcard, etc.) that uses the application-layer credential925to generate the response. For example, the trusted environment on the UE921may derive the keying material from the application-layer credential925using a key derivation function. The keying material may be the same keying material generated at the OP server924using the application-layer credential925. For example, the keying material may include a session key that may be used for authentication between the UE921and the AAA/RP server923. The keying material may be used to generate the response at913. The response may be generated at the application layer of the UE921and transmitted to the access-layer for transmission to the AP922.

The UE921may return the response at914in an EAP-response message to the AP922based on a re-authentication procedure. The EAP-response message may include the IP-layer identifier and/or the keying material generated from the application-layer credential925. The AP922may forward the EAP-response/challenge message to the AAA/RP server923at915. The AAA/RP server923may authenticate the UE921by checking the keying material in the EAP-response/challenge message and, if the check is successful, the AAA/RP server923may enable the UE921to access services over the WLAN network. For example, the AAA/RP server923may send an access accept message including an EAP success and the keying material to the AP922at916. The EAP success message may be forwarded to the UE921at917. At918, the status of the UE921may become authorized on the AP922. The UE921may obtain an IP address from the AP922at919using DHCP for example, and may access the Internet over the WLAN network at920.

OpenID is used herein to create the shared credential (e.g. application-layer credential925) between the UE921and the OP server924. The application-layer credential925may be used for authentication of the user/UE921at the AAA/RP server923. The embodiments illustrated inFIG. 9enable the UE921to authenticate towards the OP server924and share the secret925. Authentication between the UE921and the OP server924enable application-layer credential925to be generated upon successful authentication between the UE921and OP server924(e.g., using OpenID-AKA). The OP server924may then use the application-layer credential925to sign the assertion which is sent to the AAA/RP server923at910and then verified by the AAA/RP server923using the application-layer credential925. Upon secret key925generation between OP server924and UE921, as part of the OpenID procedures for example, another network entity may be used to deliver the EAP credentials (e.g., keying material) to UE921(e.g., to the CM on the UE921).

Again, using the protocol flow illustrated inFIG. 9, or portions thereof, the hotspot AAA server923may not have to connect to an MNO HLR/HSS to perform authentication using the EAP protocol. Instead, the AAA server923may communicate with a simple internet protocol (IP)-based HTTP(S) interface, such as the IP-based HTTP(S) interface for OpenID for example. Hotspot AP922may allow OpenID exchanges in addition to AP messages or unauthenticated devices.

FIG. 10is a flow diagram illustrating EAP-OpenID integration with the AAA server1022acting as an RP and implementation of a local OpenID provider (local OP). As illustrated inFIG. 10, UE1018and/or its user may be authenticated using communications between the UE1018, an AP1021, an AAA/RP server1022and/or an OP server1023. As illustrated inFIG. 10, a UE1018may include a local OP1019and a browsing agent (BA)/connection manager (CM)1020, each configured to communicate with each other and/or other network entities to perform authentication and gain access to services. While the BA/CM1020is illustrated inFIG. 10as a single entity, the BA and the CM may be separate entities that perform independent functions within the UE1018. The local OP1019may be installed on the UE1018within a secure environment (e.g., trusted processing module, UICC, SIM, smartcard, etc.). The local OP1019may act as an OP server for the UE1018. The local OP1019may include a long term secret1024which may be shared with the OP server1023on the network. The local OP1019may create and/or sign identity assertions after a successful local user authentication.

At1001, the UE1018may have an active 3GPP connection and may reach AAA/RP1022and/or OP server1023over this connection (e.g., via BA/CM1020). While authentication and service continuity may be established between a 3GPP and a WLAN connection inFIG. 10, it will be recognized that similar communications may be used for authentication and service continuity between other networks. The BA/CM1020may discover the AP1021(e.g., at the access network) and/or its identification information at1002. At this point, the UE1018may be an unauthorized client on the WLAN network. The identification information of the AP1021may include an “MNO-WiFi” SSID. The AP1023and/or its identification information may be discovered via access layer signaling, such as a beacon channel for example. The BA/CM1020may decide that the UE1018should connect to the AP1021. At1003, the AP1021(e.g., authenticator) may issue an EAP request asking for a UE1018identity. The UE1018may return its IP-layer identity at1004. The UE1018IP-layer identity may include an international mobile subscriber identity (IMSI) and/or additional authentication information, such as its realm for example. The realm may include a hint to use SSO authentication (e.g., IMSI@sso.MNO.com) for example.

The AP1021may send the EAP ID (e.g., IP-layer identity) to AAA/RP server1022at1005. The BA/CM1020on the UE1018may send an HTTP GET request to the AAA/RP1022with the OpenID identity at1006. The RP function of the AAA server1022may perform discovery and/or association with OP server1023at1007. As a result, an association key1024and/or association handle may be created and shared between OP server1023and AAA/RP server1022. According to an example embodiment, the OP server1023may receive the access-layer identity associated with the UE1018and send the association key1024and/or association handle to the AAA/RP server1022at the application layer. The AAA/RP server1022may derive an EAP key1025and/or challenge from this association key1024. For example, the EAP key1025may be derived from the association key1024using a key derivation function or a reverse bootstrapping procedure. The AAA/RP server1022may redirect the UE1018to the local OP1019at1008for authentication. This redirect message to the local OP1019from the AAA/RP1022may include the association handle, but may not include the association key1024.

The UE1018and/or BA/CM1020may authenticate locally with the local OP1019and/or generate a signed assertion at1009. The UE1018may derive the local assertion key1024from the association handle and use the assertion key1024to sign the assertion. The redirect request to the local OP1019may include the association handle, which the local OP1019may use to derive the same signature key1024as is shared between OP server1023and AAA/RP server1022. Upon successful completion of authentication, the signed assertion message may be created by the local OP1019. The local OP1019may also derive the same EAP key1025as the AAA/RP server1022generated at1007. In a variation to step1009, to complete an OpenID protocol run, the local OP1019may redirect the BA/CM1020to the AAA/RP server1022at1009(b) with the signed assertion message for verification. The local OP1019and network OP server1023may share a long term secret1024which may be used to derive the signature key1025.

The AAA/RP server1022may generate an EAP challenge based on the generated EAP key1025. The EAP challenge may be an EAP-SIM/AKA challenge and may be sent to the UE1018without having to communicate with the HLR/HSS. For example, the AP1021may receive the access challenge from the AAA/RP1022at1010and send the EAP request at1011to the BA/CM1020on the UE1018. The access challenge and the EAP request may include the EAP identity and/or the EAP challenge. After receiving the EAP-request/challenge message, the UE1018may validate the message and/or generate a response using the EAP key1025. For example, the UE1018may send the challenge to the secure environment on the UE1018(e.g., trusted processing module, UICC, SIM, smartcard, etc.) that may use the EAP key1025to generate the EAP response.

The UE1018may return an EAP response at1012to the AP1021. The EAP response may include the EAP identity and/or the EAP key1025generated from the shared key1025. At1013, the AP1021may forward the EAP-response/challenge message to the AAA/RP server1022. The AAA/RP server may validate the message and compare the received response with the expected response based on the derived EAP key1025. When the authentication checks performed at the AAA/RP server1022are successful, the AAA/RP server1022may send an indication of successful authentication to the AP1021at1014. For example, the AAA/RP server1022may send an access accept message including an EAP success and the keying material to the AP1021. The indication of successful authentication may be forwarded to the UE1018at1015. After successful authentication has been performed, the status of the UE1018may become authorized for communication on the AP1021. The UE1018may obtain an IP address at1016(e.g., using DHCP) and may access the Internet over the WLAN using AP1021at1017.

Using the protocol flow illustrated inFIG. 10, or portions thereof, the hotspot AAA server1022may not have to connect to an MNO HLR/HSS to perform authentication using the EAP protocol. Additionally, the use of the local OP1019enables the UE1018to perform local key generation for the EAP process, as well as local authentication of the user.

FIG. 11is another flow diagram illustrating EAP-OpenID integration with the AAA server1121acting as an RP. The AAA/RP1121may initiate pre-fetch associations with known OP servers prior to a request for services from the UE1018. As illustrated inFIG. 11, UE1117and/or its user may be authenticated for access to the services using communications between the UE1117, an AP1120, an AAA/RP server1121and/or an OP server1122. According to the example embodiment illustrated inFIG. 11, the UE1117may use the local OP1118to perform local authentication and key generation for EAP keys1124from OpenID signature keys1123on the UE1117. Additionally, the embodiments illustrated inFIG. 11may use the identifier select mode of OpenID to set up associations between the AAA/RP server1121and OP server1122before the UE1117authenticates towards the AAA/RP server1121. This may enable the avoidance of OP discovery by having an association between the OP server1122and the AAA/RP server1121pre-established. This may result in reducing the time for completing SSO procedure when a UE, such as UE1117for example, moves to an access network and enable networks handoff to be seamless to the user.

According to an example embodiment, the AAA/RP server1121may initiate multiple associations with known OP servers, such as OP server1122for example. The AAA/RP server1121may initiate such associations using an identifier select mode of OpenID (where the provider URL may be used instead of the full identifier URL, which may be completed by the local OP1118later on) for example. The AAA/RP server1121may store the association handles and association secrets that it obtained from the OP servers. One of the discoveries and associations performed by the AAA/RP server1121may include the discovery and association with OP server1121at1101. The AAA/RP1121may store the association handle and/or the association secret1123received from the OP server1122.

At1102, a local component on the UE, such as the BA/CM1119for example, may discover the AP1120based on its identification information. The AP1120may be identified via the access layer signaling for example. At this point, the UE1117may be an unauthorized client on the network associated with the AP1120(e.g., WLAN). The BA/CM1119may decide that the UE1117should connect to the AP1120. At1103, the AP1120may request the IP-layer identity of the UE1117. The UE1117may return its IP-layer identity and/or additional authentication information to the AP1120at1104. The AP1120may send the IP-layer identifier of the UE1117to AAA/RP server1121at1105.

The BA/CM1119on the UE1117may send a request to the AAA/RP1121at1106with the OpenID provider URL, email address, or other login identifier (e.g., in identifier select mode). The AAA/RP server1121may select one of the pre-established association handles and association keys. For example, the AAA/RP server1121may select the association handle and association key1123that has been pre-established with OP server1122based on the login identifier received from the UE1117. AAA/RP server1121may derive an EAP key1124and/or EAP challenge from this association key1123. The EAP key1124may be derived from the association key1123using a key derivation function or a reverse bootstrap procedure for example. The AAA/RP1121may redirect the UE1117at1107to the local OP1118for authentication. Since a local OP1118is deployed, the authentication may be redirected to the local OP1118. This redirection to the local OP1118may include the association handle, but may not include the association secret1123.

The UE1117and/or the BA/CM1119may authenticate locally with the local OP1118at1108. The redirect request to the local OP1118may include the association handle, which the local OP1118may use to derive the association key1123that is shared between OP server1122and AAA/RP1121. The local OP1118and network OP server1122may share a long term secret which may be used to derive the signature key1123. Upon successful completion of authentication, the local OP1118may derive the EAP key1124from the signature key1123that is also derived at the AAA/RP server1121. The EAP key may be derived using a key derivation function for example. The local OP1118may use the EAP key1124to generate a signed assertion message for sending to the AAA/RP server1121.

The AAA/RP1121may generate an EAP challenge based on the generated EAP key1124and may send the EAP challenge to the UE1117without having to communicate with the HLR/HSS. For example, the access challenge may be sent from the AAA/RP1121to the AP1120at1109. The access challenge may include the EAP ID and/or the challenge. The AP1120may send the EAP message (EAP-request/challenge) received from the AAA/RP server1121to the BA/CM1119at1110.

After receiving the EAP-request/challenge message, the UE1118may validate the message and generate a response using the EAP key1124. The UE1118may send the EAP challenge to a trusted environment (e.g., trusted processing module, UICC, SIM, smartcard, etc.) that may use the EAP key1124to generate the EAP response. The UE1117may return a response message to the AP1120at1111. The response message may include the EAP ID and/or the EAP response. At1112, the AP1120forwards the EAP-response/challenge message to the AAA/RP server1121. The AAA/RP may perform authentication using the EAP key1124. When the authentication checks performed at the AAA/RP server1121are successful, the AAA/RP server1121may send an indication of successful authentication at1113. For example, the AAA/RP server1121may send a message indicating successful authentication to the AP1120. For example, the indication of successful authentication may include an EAP success and the keying material. The indication of successful authentication may be forwarded to the UE1117at1114. After successful authentication has been performed, the UE1117status may become authorized on the AP1120. The UE1117may obtain an IP address for communication on the AP1120(e.g., using DHCP) at1115and may access the Internet at1116using the AP1120.

FIG. 12is a flow diagram illustrating an authentication protocol that implements an AAA server1218as the OP server. The flow diagram illustrated inFIG. 12may be implemented using a UE1216, an AP1217, and an AAA/OP server1218. The AP1217may be a hotspot or other node capable of communicating over a WLAN network for example. The integration of the OP server functionality into a hotspot AAA service may enable support of seamless authentication and/or service continuity between networks, such as between 3GPP and WLAN networks for example. The AAA/OP server1218may use previously generated keys1219on UE1216and/or the AAA/OP server1218to perform authentication for accessing services over the WLAN network. According to an example embodiment, the previously generated keys1219may be application-layer credentials. WhileFIG. 12describes network communications for seamless authentication and/or service continuity between 3GPP and WLAN networks, it will be understood that similar communications may be used for seamless authentication and service continuity between other types of wireless networks.

As described herein, a user may be seamlessly authenticated at a public hotspot (e.g., AP1217) with an OP module that is integrated into the AAA server1218. According to an embodiment, authentication may be performed using the AAA/OP server1218to leverage keys1219derived on UE1216and/or AAA/OP server1218to complete authentication (e.g., EAP-SIM/AKA authentication). An active 3GPP connection may be used to exchange authentication messages (e.g., OpenID authentication messages) for authentication at the WLAN network.

As illustrated inFIG. 12, the UE1216may successfully completed authentication towards the AAA/OP server1218at1201over a 3GPP access network. Shared keys1219may be established on the UE1216and/or the AAA/OP server1218during the authentication protocol over the 3GPP access network. At1202a local component on the UE (e.g., a CM) may discover the AP1217based on its identification information. For example, the identification information of the AP1217may be an “MNO-WiFi” SSID. The AP1217may be discovered via access layer signaling, such as a beacon channel for example. The local component on the UE1216(e.g., the CM) may decide that the UE1216should switch to the hotspot.

The AP1217(e.g., authenticator) may issue an EAP request at1203asking for UE1216's IP-layer identity. The UE1216may return its IP-layer identity and/or additional authentication information to AP1217at1204. For example, the UE1216may return its international mobile subscriber identity (IMSI). The additional authentication information may include the realm. The realm includes a hint to use SSO authentication (e.g., IMSI@sso.MNO.com). According to an example embodiment, the UE1216may provide additional information to aid in discovery of the UE1216authentication capabilities, such as by pre-pending a bit (e.g., a ‘0’ or a ‘1’) to the IMSI to hint to the server to use EAP-AKA or EAP-SIM procedures respectively.

The AP1217may send the EAP ID (e.g., access-layer identity) to AAA/OP server1218at1205. The OP function of the AAA server1218may generate a challenge at1206based on previously generated key1219shared with the UE1216. For example, the AAA/OP server1218may derive a session key for use in authentication at the access-layer. The session key may be derived using a key derivation function or a generic bootstrap procedure for example. The AAA/OP server1218may use a re-authentication procedure to send the challenge to the UE1216in EAP-SIM/AKA challenge message. For example, the AP1217may receive an EAP message that includes the session key generated from the shared key1219and/or the EAP ID from the AAA/OP server1218at1207. The AP1217may then forward the EAP message received from the AAA/OP server (EAP-Request/Challenge) to the UE1216at1208.

After receiving the EAP-request/challenge message, the UE1216may perform authentication using the session key. The UE1216may send the challenge to a secure environment resident thereon (e.g., trusted processing module, UICC, SIM, smartcard, etc.) which may use the shared key1219with the AAA/OP server1218to generate the EAP response at1209. For example, the EAP response message may include a response generated from the shared key1219.

The UE1216may return an EAP message to the AP1217at1210in response to the AP1217based on a re-authentication procedure. The EAP message may include the EAP ID and/or the response generated using the shared key1219. At1211, the AP1217may forward the EAP-response/challenge message to the AAA/OP server1218. The AAA/OP server may validate the message and/or compare the response received in the EAP-response/challenge message with the expected response. When the checks performed at the AAA/OP server1218are successful, the AAA/OP server1218may send an indication of successful authentication to the UE1216via the AP1217. For example, the AAA/OP server1218may send an access accept message at1212including an EAP success and/or the key material to the AP1217. The EAP success message may be forwarded to the UE1216at1213. Upon successful authentication, the UE1216status may become authorized on the AP1217. The UE1216may obtain an IP address (e.g. using DHCP) from the AP1217at1214and may access the Internet over the WLAN network at1215.

As described herein, a shared credential1219may be generated between the UE1216and the AAA/OP server1218. The shared credential may be established during or after authentication at another network for example. The UE1216may authenticate towards the AAA/OP server1218, which may use the shared credential1219to sign an assertion which is sent to an RP and then verified by the RP using the shared credential1219. The authentication between UE1216and AAA/OP1218may generate the shared credential1219upon successful authentication (e.g., using OpenID-AKA). Upon shared credential1219generation between AAA/OP1218and UE1216, another entity may deliver the EAP credentials to the UE1216(e.g., at the CM).

The embodiments described herein may eliminate the implementation of complex MAP/Diameter interface on a hotspot AAA server or to interface and communicate with the MNO HLR/HSS for AV fetching. Additionally, seamless authentication and service continuity between 3GPP and WLAN hotspots may be enabled. As illustrated inFIG. 12, an OP module may be implemented in a hotspot AAA server1218. As an alternative to, or in addition to, integrating OP into hotspot AAA server, OP functionality may be implemented into MNO AAA server and hotspot AAA server may act as an AAA proxy that relays requests to the MNO AAA server.

FIG. 13illustrates an example embodiment of a protocol flow for integration of OpenID messages into the EAP protocol messages. The protocol flow, or one similar thereto, may be implemented to enable some of the network communications illustrated inFIGS. 11 and 12for example.

As illustrated inFIG. 13, UE1316, AP/RP1317, and/or OP server1318may perform communications to enable authentication of the UE1316at the network. The UE1316may discover the access network associated with AP/RP1317at1301. At this point, the UE1316may be unauthorized for communication on the network. At1302, the AP/RP1317may send a request for an EAP ID (e.g., an access-layer identity). The UE1316may send an OpenID identifier in an EAP response to the AP1317at1303. Using the OpenID identifier, the AP1317may perform the discovery and/or association steps of the OpenID protocol with the OP server1318at1304. In order to perform discovery and/or association, the AP1317may unwrap the OpenID messages (e.g., the OpenID identifier) from the EAP protocol and communicate with the OP server1318via HTTP(S). The establishment of an association in the OpenID protocol may be optional.

After association, the OP server1318may generate a challenge at1305and the AP1317may receive the OpenID challenge from the OP server1318at1306. The AP1317may send an EAP request (corresponding to the OpenID redirect in the OpenID protocol), to the UE1316at1307. With the help of a local OP, the UE1316may generate the correct response at1308and send the EAP response with the signed OpenID assertion to the AP1317at1309. If the AP1317established an association with the OP server1318, the AP1317may autonomously verify the assertion signature and thus authenticate and authorize the UE1316. If no association has been established earlier, the AP1317may use the stateless mode to request signature verification by the OP server1318, such as at1310for example. If the authentication is successful at the OP server1318, the OP server1318may send an OpenID message at1311to AP/RP1317with the identity and an authentication assertion. The AP/RP1317may indicate successful authentication to UE1316at1312and the UE may be authorized for service via the AP/RP1317at1313. At1314, the UE1316may obtain (e.g., via DHCP request) an IP address from AP/RP1317and may be enabled internet access over the WLAN network at1315.

The stateless mode may be ‘forced’ by the local OP even if AP1317and OP server1318already established an association. The local OP can set the field ‘invalidate_handle’ in the assertion message, and create a new association handle. The AP1317then may go back to the OP server1318for signature verification. This behavior of OpenID may be used to trigger a feedback mechanism from AP1317to OP server1318even if a local OP is in place and issues the assertion. If associations are used and not invalidated, there may be no feedback to the OP server1318. The embodiments described herein may enable some payment scenarios and/or privacy for example.

According to an example embodiment, authentication of a user for services may be performed by establishing a connection between an AP and an AAA server of the MNO for AV fetching in the EAP protocol. By implementing OpenID an additional abstraction layer may be created between the AP and MNO network. The OP may act as a proxy to the network authentication infrastructure and authenticate UEs based on network credentials without giving a direct access to network AVs to connected APs. Since the OP acts as an authentication point, the logic in the AP may be reduced to verify an OpenID assertion. Using OpenID, there may be no need to deal with AVs at the AP. Additionally, the OP may serve multiple APs of different AP operators, since the APs do not have to have a direct connection to the MNO infrastructure. The OP may also act as a transaction authenticator (this may include the local OP for example). This may allow billing and/or benefit/bonus payment via the MNO back end for AP operators. Hence multiple MNOs may use the same OP. Multiple AP providers may also use the same OP. This may result in a ‘star’ architecture for example.

Embodiments herein may use a key derivation function, such as a generic bootstrapping procedure. For example, the Generic Bootstrapping Architecture (GBA) may be implemented. One example embodiment of GBA may be described in 3GPP Technical Specification (TS) 33.220. However, GBA may be limited to UICC-based credentials. The embodiments described herein may be implemented using UICC-based and/or non-UTCC-based credentials. GBA may also be limited to IP connectivity between the UE-BSF and UE-NAF to perform bootstrapping and authentication. This may cause GBA to break seamless mobility protocols, such as Mobile IP for example. Mobile IP may use authentication at/or below IP layer to perform switchover and bringing up the new interface such as WLAN interface and performing registration with the home agent (HA). The race condition between Mobile IP registration at the IP layer and GBA bootstrapping at the application layer may break mobility and may fail MIP registration and as a result switching to WLAN network may fail.

The EAP-GBA integration option may be used to solve the mobility problems between 3GPP and WLAN networks, such as for dual-mode devices based on GBA for example. GBA authentication may be performed over the existing 3GPP interface. The outcome of a GBA authentication (e.g., the Ks_NAF stored in the device) may be used to complete the EAP authentication in the hotspot. Mobility issues may be solved with GBA by providing the IP connectivity for the GBA authentication via 3GPP interface and using GBA-EAP integration for example.

FIG. 14is a flow diagram illustrating the UE1421authentication for services using OpenID Connect. As illustrated inFIG. 14, the UE1421may have an active wireless connection (e.g., 3GPP connection) and may reach AAA/RP server1425and/or OP server1426over this connection. At1401, the UE1421may perform an OpenID Connect login to the AAA/RP server1425, which may create an access token. The access token may be saved by the BA1422(or saved by the OS) at1402. A local component on the UE, e.g., CM1423, may discover the AP1424, and its identification information such as an “MNO-WiFi” SSID, via the access layer signaling such as a beacon channel. The CM1423may decide that the UE1421should connect to the AP1424. At1403, the CM may attach to the AP1424. The AP1424(e.g., authenticator) may set the UE1421state to unauthenticated or unauthorized at1404.

At1405, the AP1424may issue an EAP request asking for UE1421EAP/IP-layer identity. The UE1421may return an international mobile subscriber identity (IMSI) and/or other authentication information at1406. The other authentication information may include its realm, which may include a hint to use SSO authentication (e.g., IMSI@sso.MNO.com) for example. At1407, the AP1424may send the EAP ID received from the UE1421to AAA/RP server1425(e.g., using a RADIUS access request).

At1408, the AAA/RP server1425may detect that the UE1421is capable of using the OpenID Connect based flow based on the EAP ID received (or by looking up a database using the received EAP ID). The AAA/RP server1425may send an EAP-SIM/AKA challenge to the AP1424at1409indicating that OpenID Connect should be used in the EAP protocol. The AP1424may send the EAP message received from the AAA/RP server1425(EAP-Request/Challenge) to the UE1421(e.g., at CM1423).

After receiving the EAP-request/challenge message, the UE1421may check the authentication parameters in the message and may request the token from the BA1422(e.g., the BA may alternatively be an OS or API) at1411. The access token may be returned to the CM1423at1412. At1413, the CM1423may send the access token in the EAP message to the AP1424. The AP1424may forward the EAP-response/challenge message to the AAA/RP server at1414. The AAA/RP server1425may verify the token and then uses the token with the user info endpoint from the OP server1426to retrieve user info for authentication from the OP server1426at1415.

The OP server1426may validate the token before releasing the user info. The AAA/RP server1425may receive the user info at1417. The user info may include username, address, billing info, and/or a billing token for example. The AAA/RP server1425may perform authentication checks based on the user info received at1417. When all checks are successful, the AAA/RP server may send an indication of successful authentication to the UE1421. For example, the AAA/RP server1425may send an access accept message that includes an EAP success and the keying material to the AP1424at1418. The EAP success message may forwarded to the UE1421at1419. At1420, the UE1421status become authorized for access on the network on the AP1424. The UE1421may obtain an IP address (e.g., using DHCP) and may access the Internet via the AP1424.

FIG. 15is a flow diagram illustrating authentication of the UE1520for services using OpenID Connect and local OP. As illustrated inFIG. 15, a local component on the UE1520, e.g., a CM1522, may discover the AP1524, and/or its identification information. The AP1524and/or its identification information may include an “MNO-WiFi” SSID, which may be discovered via access layer signaling, such as a beacon channel for example. The CM1522may decide that the UE1520should connect to the AP1524.

At1501, the UE1520may attach to the AP1524. The AP1524(e.g., authenticator) may set the UE1520state to unauthenticated or unauthorized for communication at1502. The AP1524may issue an EAP request at1503asking for UE IP-layer/EAP identity. The UE1520may return its IP-layer/EAP identifier at1504. For example, the UE1520may return an international mobile subscriber identity (IMSI) and/or additional authentication information. The additional authentication information may include its realm, which may include a hint to use SSO authentication (e.g., IMSI@sso.MNO.com) for example.

The AP1524may send the EAP ID to AAA/RP server1525at1505. The communications between the AP1524and AAA/RP server1525may be performed using RADIUS messages, such as an access request message, and access challenge, and/or an access accept message for example. At1506, the AAA/RP server may detect that the UE1520is capable of using the OpenID Connect based flow based on the EAP identity received (or by looking up a database using the received EAP identity for example). The AAA/RP server may send an EAP-SIM/AKA challenge to the AP1524at1507. The challenge may indicate that OpenID Connect should be used in the EAP protocol. The indication may be transparent to the AP1524and/or the EAP protocol. Instead of an indication, the AAA/RP server1525may create an OpenID Connect request object (e.g., JSON) and may put an indicator (URL) to it into the request.

At1508, the AP1524may send the EAP message received from the AAA/RP server1525(EAP-request/challenge) to the UE1520(e.g., at the CM1522). After receiving the EAP-request/challenge message, the UE1520may check the authentication parameters and uses the OpenID Connect request object to initiate an OpenID Connect session with the local OP1521at1509. The local OP1521may create the access token at1510(e.g., after a successful local user authentication). The access token may be returned to the CM1522at1511. At1512, the CM1522may send the access token in the EAP message to the AP1524. The AP1524may forward the EAP-Response/Challenge message to the AAA/RP server1525. The AAA/RP server1525may verify the token and use the token, with the user info endpoint from the OP server1526, at1514to retrieve the user data for authentication.

At1515, the OP server1526may validate the token before being able to release the user info for authentication. The AAA/RP server1525may receive the user info at1516. The user info may include the username, address, billing info, and/or billing token for example. The AAA/RP server1525may use the user info received at1516to perform authentication of the user and, when the checks are successful, the AAA/RP server1525may send an indication of successful authentication to the UE1520at1517. For example, the AAA/RP server1525may send an access accept message, which may include an EAP success message and/or the keying material, to the AP1524. The EAP success message may be forwarded to the UE1520at1518(e.g., to the CM1522). The UE1520status may become authorized on the AP1524at1519. The UE1520may obtain an IP address (e.g., using DHCP) and may access the Internet via the AP1524.