US8332912B2 - Method and apparatus for determining an authentication procedure - Google Patents

Method and apparatus for determining an authentication procedure Download PDF

Info

Publication number
US8332912B2
US8332912B2 US12/521,717 US52171707A US8332912B2 US 8332912 B2 US8332912 B2 US 8332912B2 US 52171707 A US52171707 A US 52171707A US 8332912 B2 US8332912 B2 US 8332912B2
Authority
US
United States
Prior art keywords
domain
server
authentication
visited
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US12/521,717
Other versions
US20110093919A1 (en
Inventor
Mats Näslund
John Michael Walker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Assigned to TELEFONAKTIEBOLAGET LM ERICSSON (PUBL) reassignment TELEFONAKTIEBOLAGET LM ERICSSON (PUBL) ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WALKER, JOHN MICHAEL, NASLUND, MATS
Publication of US20110093919A1 publication Critical patent/US20110093919A1/en
Application granted granted Critical
Publication of US8332912B2 publication Critical patent/US8332912B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/20Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431Key distribution or pre-distribution; Key agreement
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies

Definitions

  • the present invention relates to a method and apparatus for determining an authentication procedure to be applied to a client accessing or attempting to access services via a visited domain whilst having a service agreement with a home domain.
  • a key component of this model is a mechanism for allowing a visited domain to authenticate a user as a subscriber of the home domain.
  • the visited domain needs assistance from the home domain to implement this mechanism.
  • the typical approach is to provide within the home domain an “authentication server” which maintains long-term authentication credentials for a user and is the “root of trust” for the user.
  • An “authenticator” is provided within the visited domain and performs the actual authentication by communication with the authentication server and the user (or “client”).
  • 3GPP TS 33.102 describes a security architecture for the Universal Mobile Telecommunications Service (UMTS) networks which is, as far as possible, compatible with the pre-existing GSM networks.
  • UMTS Universal Mobile Telecommunications Service
  • TS 33.102 considers in particular the Authentication and Key Agreement (AKA) security protocol which is a mechanism for performing authentication and session key distribution.
  • AKA is a challenge-response based mechanism that uses symmetric cryptography.
  • AKA is typically run in a UMTS Subscriber Identity Module (USIM) which resides on a smart card like device.
  • the smart card possesses a secret K which is also known to an Authentication Centre (AuC) located within the user's home domain.
  • AuC Authentication Centre
  • the AKA mechanism is run between the client terminal and the visited domain, involving the home domain as a “back-end”.
  • This process involves the visited domain being provided, by the home network, with an authentication vector comprising a challenge and an expected result.
  • the challenge is forwarded by the visited domain to the client terminal, which generates a challenge response (within the USIM) and returns this to the visited domain. If the challenge response matches the expected result, the visited domain authorises the client terminal to use its access services.
  • AKA also allows the client terminal to verify that its home domain has indeed been involved in the signalling process, which in turn allows the terminal to authenticate the visited domain.
  • the AKA authentication vector is good for only one access attempt by the client. If the client terminal subsequently deregisters from the visited domain (e.g. the terminal is powered down), a new authentication vector is required for any further registration.
  • TS 33.102 allows for the home domain to provide to the visited domain a set of authentication vectors at first registration, enabling the visited domain to perform multiple authentications for a given client terminal without having to contact the home domain for each individual registration.
  • Authentication in 2G networks is handled using a challenge and response approach similar to AKA.
  • the 2G and 3G approaches to security enable (local) mobility and hand-overs since the home domain does not need to be involved in sub-sequent re-authentications.
  • a user can be implicitly authenticated/authorised in the new access by reuse of the previously used session keys.
  • delegating responsibility for authentication to the visited network may not always be satisfactory for the home domain, as the home domain must “blindly” trust that the visited domain is not making a false claim about the client's presence in the visited domain, or that the client is receiving the paid for services, etc. Whilst this trust model has worked well for established network operators, it may not apply to future network configurations as will be discussed below.
  • AAA Authentication, Authorization, and Accounting
  • the currently implemented protocols include RADIUS and DIAMETER.
  • a typical Internet scenario might involve a user attempting to use a WLAN hotspot (located for example in an Internet café or airport terminal) as an access network, when the user is a subscriber of an Internet Service Provider (ISP) broadband network.
  • ISP Internet Service Provider
  • authentication is done in the home domain, i.e. the authenticator and authentication server are both in the home domain. While this may be satisfactory to the home domain, it leads to sub-optimal performance due to the signalling overhead and impairs smooth hand-over/mobility within the visited domain.
  • a wireless terminal may communicate with a AAA client/authenticator within the access domain, with the AAA client communicating with a AAA server in the home domain.
  • End-to-end authentication signalling may be conveyed using the Extensible Authentication Protocol (EAP) which is an authentication framework rather than an actual authentication method.
  • EAP Extensible Authentication Protocol
  • One of the roles of EAP is to implement an authentication method between endpoints.
  • the EAP-AKA method is one example of such an authentication method.
  • AKA data will be contained within EAP messages which are in turn contained within DIAMETER messages (for the AAA client to AAA server leg).
  • UMTS AKA as described above is a 3GPP-specific protocol which does not use AAA and EAP frameworks and should not be confused with EAP-AKA, although of course the actual AKA mechanism is common to both.
  • FIG. 1 This current protocol “architecture” is illustrated in FIG. 1 , where the wireless access network is a 802.11 (WLAN) network and the AKA endpoint is in the home domain.
  • the AAA client/authenticator within the wireless network understands the EAP signalling, and converts EAP in the AAA signalling to EAP over LAN.
  • the AAA client/authenticator is transparent to AKA. It is noted that one or more AAA proxies may be present between the visited and home networks.
  • 3GPP-based access domains e.g. GPRS, UMTS, LTE
  • non-3GPP based access domains e.g. Wimax, WLAN, Fixed-Line broadband, etc
  • a home domain will likely ustilise AAA (e.g. DIAMETER) and EAP, and multiple EAP-methods (such as EAP AKA, EAP SIM, EAP TLS, etc) to communicate with the different access domains and terminals.
  • EAP AKA, EAP SIM, EAP TLS, etc EAP AKA, EAP SIM, EAP TLS, etc
  • It is however inevitable that a given home domain will place different levels of trust on different access domains. For example, a high level of trust might be placed on a 3G access domain, whilst a very low level of trust may be placed on an Internet café WLAN.
  • a server for managing the authentication of clients that are subscribers of a home domain within which the server is located, the server comprising means for determining whether a client that is attached to a visited domain is to be authenticated by the home domain or by said visited domain, and for signalling the result to said visited domain.
  • Embodiments of the present invention introduce a dynamic flexibility into the authentication process. It is now possible for the home domain to determine where the authentication is to take place based upon static properties such as client subscription, and on changing properties such as visited network identity. This results in a service architecture which optimises signalling routes when appropriate whilst maintaining financial security.
  • the server may comprise a non-transitory memory for storing authentication data for the clients.
  • the server is arranged, in the event that it determines that the visited network is to be responsible for authentication, to generate session data and to send this session data to the visited network.
  • this data may comprise an authentication vector.
  • the server comprises an interface for communicating with visited domains, first processing means for receiving via said interface a registration request sent by a visited domain in respect of one of said clients, and second processing means for determining whether the request is to be authenticated by the home domain or by the visited domain.
  • the second processing means is arranged, in the former case, to authenticate the request and signal the result to the visited domain via said interface, and, in the latter case, to signal to the visited domain via said interface that the visited domain is to be responsible for authenticating the request.
  • Said first processing means may be further arranged to receive via said interface a request from a visited network to transfer the authentication decision from one domain to another, in the case of a previously authenticated client.
  • Said second processing means is arranged to make a further determination and to notify the visited network accordingly.
  • the server may comprise means for determining that a previous decision to delegate an authentication procedure to the visited domain is to be revoked, and for signalling that decision to the visited domain.
  • the authentication procedure which may be delegated to the visited domain may be a second level procedure.
  • a first level procedure may be carried out by the home domain based, for example, upon terminal and/or user identity, prior to conducting the second level procedure at the home domain or, if delegated, at the visited domain.
  • a method of authenticating a client attached to a visited domain, where the client is a subscriber of a home domain comprising:
  • said authentication request may be a DIAMETER Request.
  • this is signalled to the visited domain by sending a NACK.
  • the result of the authentication is subsequently signalled to the visited domain by sending an ACCEPT/REJECT message.
  • Authentication involves the exchange of a challenge and response between the home domain and the client.
  • this is signalled to the visited domain by sending an ACK message, together with authentication data.
  • a challenge and response exchange is conducted between the client and the visited domain.
  • FIG. 1 illustrates various protocol layers involved in an authentication procedure for a wireless terminal attached to a visited network
  • FIG. 2 illustrates schematically a communications system architecture comprising visited and home domains
  • FIGS. 3 a and 3 b are flow diagrams illustrating authentication decision processes carried out with an authentication server of a home domain
  • FIG. 4 shows authentication related signalling for the case where a home domain takes the decision not to delegate responsibility for authentication to a visited domain
  • FIG. 5 shows signalling associated with the case where a home domain decides to delegate responsibility for authentication to a visited domain for a limited period or number of tries
  • FIG. 6 shows signalling associated with the delegation of authentication responsibility to a visited domain, with a subsequent decision to revoke that permission
  • FIG. 7 is a signalling chart illustrating a case where a visited domain elects to request a transfer of authentication responsibility back to a home domain;
  • FIG. 8 is a signalling chart illustrating a case where a visited domain elects to request a transfer of authentication responsibility to it, from the home domain;
  • FIG. 9 illustrates a signalling flow in the case where a client is attached to a future 3GPP Long Term Evolution (LTE) based access domain.
  • LTE Long Term Evolution
  • FIG. 10 shows a signalling flow in the case where a client is attached to an I-WLAN access domain.
  • FIG. 2 There is illustrated in FIG. 2 a generic visited domain/home domain architecture, which allows for roaming of subscribers (referred to below as “clients”) of the home domain into the visited domain.
  • An authentication server 1 controlled by a processor and non-transitory memory, is located within the home domain 2 and maintains in a second non-transitory memory, long-term authentication credentials of the home domain's clients.
  • the authentication server may also act as authenticator for clients seeking to register with visited domains including the illustrated domain 3 .
  • a separate authenticator 4 is located within the visited domain 3 .
  • FIG. 2 illustrates a client 5 attached to the visited domain 3 .
  • the authentication server 1 receives access requests from a visited domain via an interface 6 , whereupon processing means 7 within the authentication server makes decisions as to whether authentications are to be performed within the home domain or can be delegated to the visited domain.
  • the server may also determine that authentications are shared between the home and visited domains. For example, it may determine that only the first authentication is to be performed by the home domain and subsequent authentications are delegated to the visited domain, or that only every tenth authentication is to be performed by the home domain, etc. The server makes these decisions based upon certain available information.
  • This information may include, for example, one or more of the following; visited operator identity, access network type, user-id, type of network security being used in the access network of the visited domain, type of user authentication being carried out, selected Access Point Name (APN), Quality of Service (QoS) requirement, charging rules, type of subscription, type of terminal, user location (e.g. certain geographical areas might be considered less secure from a telecommunication point of view).
  • visited operator identity e.g. certain geographical areas might be considered less secure from a telecommunication point of view.
  • FIG. 3 a is a flow diagram illustrating the delegation decision process taken by the authentication server within the home domain, namely evaluate input criteria (step 1 ), set authentication delegation conditions (step 2 ), and send authentication delegation response to visited domain (step 3 ).
  • FIG. 3 b is a flow diagram illustrating a delegation revocation decision process taken by the authentication server.
  • the authentication server evaluates the criteria to make the revocation decision (step 4 ), and sends an authentication revocation to the visited domain (step 5 ).
  • the access request is typically carried by a DIAMETER Request message sent between a AAA-client (possibly via AAA-proxy) in the visited domain and a HSS/AAA server within the home domain.
  • the home authentication server responds either by sending a DIAMETER Answer message containing a DIAMETER AVP (attribute-value-pair) with authentication data to be used by the visited domain, or by sending to the visited domain a special “NACK” message, informing the visited domain to allow the authentication procedure to proceed between the client and the home domain.
  • the visited domain either just relays authentication related authentication signalling (e.g.
  • the AKA authentication vector i.e. (RAND, XRES, AUTN, Ck, Ik) contains all of the information that the visited domain needs to assume the role of authenticator.
  • DIAMETER supports server-initiated requests that can be used for this purpose.
  • the home domain operator can also delegate authentication to the visited domain for a limited time or a limited number of re-authentications only, after which the visited domain must relay authentication signalling back to the home domain (at least until the home domain once again delegates responsibility for authentication to the visited domain).
  • the home domain operator can also decide that every N th authentication should be relayed by the visited domain back to the home domain. Any one of these approaches creates “check points” at which the home domain can choose to continue with or change the applied authentication policy.
  • DIAMETER generally requires the maintenance of session state information (e.g. for the purpose of accounting), this state information can be extended with information enabling the visited domain to decide when to perform authentication locally and when to defer it to the home domain.
  • the procedure described here does offer the visited domain the opportunity to refuse to “erase” authentication data it already has, and to continue to take the authenticator role even if the home domain revokes the delegated rights.
  • the visited network cannot be guaranteed that it will be paid for used services.
  • the client itself may elect not to continue.
  • FIG. 4 shows authentication related signalling for the case where the home domain takes the decision not to delegate responsibility for authentication to the visited domain.
  • This may be implemented using the DIAMETER AAA protocol.
  • the initial request Req(IDc) is supplemented with the IDv at the AAA-visited server, and forwarded to the HSS/AAA home server (possibly via a AAA proxy).
  • the latter determines (based upon available information and policies) that no delegation is permitted, and returns a NACK to the AAA-visited server.
  • the challenge response process is then conducted between the HSS/AAA home authenticator and the client.
  • FIG. 5 shows signalling associated with the case where the home domain decides to delegate responsibility for authentication for a limited period or number of tries.
  • the AAA-home server After receiving the request, the AAA-home server provides authentication data to the AAA-visited authenticator. The latter stores the received data and proceeds to authenticate the client using the received data and a challenge-response procedure. One or more re-authentications can be performed by the visited domain before it must revert to the home domain for a refresh (or denial) of the delegation.
  • FIG. 6 shows signalling associated with the case where the home domain delegates authentication responsibility to the visited domain, but subsequently decides to revoke that permission.
  • the home domain does this by sending a Revoke (IDc) message to the AAA-visited authenticator. This will typically force the client to re-authenticate at the home domain.
  • IDc Revoke
  • a visited domain to which authentication responsibility has previously been delegated (or which is configured to provide authentication by default), can request that the home domain change the authentication domain. This may arise, for example, in the following circumstances:
  • FIG. 7 A signalling chart illustrating this process is shown in FIG. 7 .
  • FIG. 8 shows a signalling chart illustrating the case where the home domain has determined that it must be responsible for client authentication, and the visited domain subsequently requests that responsibility for authorisation be transferred from the home domain to the visited domain. This situation may arise, for example, when a client requests an APN local to the visited domain or local breakout takes place, and in which cases the visited domain prefers to authenticate the client itself.
  • this illustrates a signalling flow in the case where the client (UE) is attached to a future 3GPP Long Term Evolution (LTE) based access domain (considering here OFDM, Rel8).
  • LTE Long Term Evolution
  • DIAMETER AAA will be deployed between the home and visited domains.
  • the initial user authentication is performed using AKA, with the authenticator being implemented at the MME within the visited domain (the “VPLMN”).
  • the HSS within the home domain (the “HPLMN”) provides the required authentication vector to the MME upon receipt of the request.
  • the session key included in the authentication vector is passed by the MME to the eNB via the UPE.
  • the flow illustrates the case where the HPLMN subsequently decides to revoke the authentication permission previously given the VPLMN, whereupon the MME sends an AUTH REQUEST to the client.
  • the challenge and response procedure is then conducted between the client and the HPLMN and, assuming this is successful, the session keys are sent from the home HPLMN to the VPLMN.
  • FIG. 10 shows a signalling flow in the case where the client is attached to an I-WLAN access domain.
  • authentication would be performed within the home domain.
  • the home domain elects to delegate authentication responsibility to the access domain.
  • the IASA in the VPLMN which acts as authenticator after delegation.
  • this role could be performed by the Access Node (AN) although this approach would be less secure.

Abstract

A server in a home domain for managing the authentication of clients that are subscribers of the home domain, but are attached to a visited domain. Based on knowledge of the type of security being used in an access network of the visited domain, the server determines whether a given client is to be authenticated by the visited domain or the home domain. The server then signals the result to the visited domain.

Description

TECHNICAL FIELD
The present invention relates to a method and apparatus for determining an authentication procedure to be applied to a client accessing or attempting to access services via a visited domain whilst having a service agreement with a home domain.
BACKGROUND
In the case of cellular telephone networks, a standard operating model has evolved over the years to enable users to roam outside of the home domain to which they subscribe, into so-called visited domains. This model allows users to roam in visited (e.g. foreign) domains whilst ensuring that the visited domain operators can recover incurred costs from the home domain. At the same time, the home domain operator can trust the visited domain operators to recharge only costs that are actually incurred. A key component of this model is a mechanism for allowing a visited domain to authenticate a user as a subscriber of the home domain. The visited domain needs assistance from the home domain to implement this mechanism. The typical approach is to provide within the home domain an “authentication server” which maintains long-term authentication credentials for a user and is the “root of trust” for the user. An “authenticator” is provided within the visited domain and performs the actual authentication by communication with the authentication server and the user (or “client”).
3GPP TS 33.102 describes a security architecture for the Universal Mobile Telecommunications Service (UMTS) networks which is, as far as possible, compatible with the pre-existing GSM networks. TS 33.102 considers in particular the Authentication and Key Agreement (AKA) security protocol which is a mechanism for performing authentication and session key distribution. AKA is a challenge-response based mechanism that uses symmetric cryptography. Within a client terminal, AKA is typically run in a UMTS Subscriber Identity Module (USIM) which resides on a smart card like device. The smart card possesses a secret K which is also known to an Authentication Centre (AuC) located within the user's home domain. When a user attempts to register with a visited domain, the AKA mechanism is run between the client terminal and the visited domain, involving the home domain as a “back-end”. This process involves the visited domain being provided, by the home network, with an authentication vector comprising a challenge and an expected result. The challenge is forwarded by the visited domain to the client terminal, which generates a challenge response (within the USIM) and returns this to the visited domain. If the challenge response matches the expected result, the visited domain authorises the client terminal to use its access services. AKA also allows the client terminal to verify that its home domain has indeed been involved in the signalling process, which in turn allows the terminal to authenticate the visited domain.
The AKA authentication vector is good for only one access attempt by the client. If the client terminal subsequently deregisters from the visited domain (e.g. the terminal is powered down), a new authentication vector is required for any further registration. TS 33.102 allows for the home domain to provide to the visited domain a set of authentication vectors at first registration, enabling the visited domain to perform multiple authentications for a given client terminal without having to contact the home domain for each individual registration.
Authentication in 2G networks is handled using a challenge and response approach similar to AKA.
The 2G and 3G approaches to security enable (local) mobility and hand-overs since the home domain does not need to be involved in sub-sequent re-authentications. For example, in the case of a terminal transferring to a 2G access from a 3G access (where both accesses belong to the same operator), a user can be implicitly authenticated/authorised in the new access by reuse of the previously used session keys. However, delegating responsibility for authentication to the visited network may not always be satisfactory for the home domain, as the home domain must “blindly” trust that the visited domain is not making a false claim about the client's presence in the visited domain, or that the client is receiving the paid for services, etc. Whilst this trust model has worked well for established network operators, it may not apply to future network configurations as will be discussed below.
In the case of the Internet, the IETF has created under the heading Authentication, Authorization, and Accounting (AAA), a set of protocols for achieving authentication of a user within a visited domain. The currently implemented protocols include RADIUS and DIAMETER. A typical Internet scenario might involve a user attempting to use a WLAN hotspot (located for example in an Internet café or airport terminal) as an access network, when the user is a subscriber of an Internet Service Provider (ISP) broadband network. In the IETF model, authentication is done in the home domain, i.e. the authenticator and authentication server are both in the home domain. While this may be satisfactory to the home domain, it leads to sub-optimal performance due to the signalling overhead and impairs smooth hand-over/mobility within the visited domain.
It is noted that where the access domain is a wireless network, a wireless terminal may communicate with a AAA client/authenticator within the access domain, with the AAA client communicating with a AAA server in the home domain. End-to-end authentication signalling may be conveyed using the Extensible Authentication Protocol (EAP) which is an authentication framework rather than an actual authentication method. One of the roles of EAP is to implement an authentication method between endpoints. The EAP-AKA method is one example of such an authentication method. In this approach therefore, AKA data will be contained within EAP messages which are in turn contained within DIAMETER messages (for the AAA client to AAA server leg). [UMTS AKA as described above is a 3GPP-specific protocol which does not use AAA and EAP frameworks and should not be confused with EAP-AKA, although of course the actual AKA mechanism is common to both.]
This current protocol “architecture” is illustrated in FIG. 1, where the wireless access network is a 802.11 (WLAN) network and the AKA endpoint is in the home domain. The AAA client/authenticator within the wireless network understands the EAP signalling, and converts EAP in the AAA signalling to EAP over LAN. The AAA client/authenticator is transparent to AKA. It is noted that one or more AAA proxies may be present between the visited and home networks.
Communication standards are evolving to provide for the integration of different heterogeneous access domains into one single logical network. This will result in 3GPP-based access domains (e.g. GPRS, UMTS, LTE) and non-3GPP based access domains (e.g. Wimax, WLAN, Fixed-Line broadband, etc) merging to form one logical network (see for example 3GPP 3GPP TR 23.882). A home domain will likely ustilise AAA (e.g. DIAMETER) and EAP, and multiple EAP-methods (such as EAP AKA, EAP SIM, EAP TLS, etc) to communicate with the different access domains and terminals. It is however inevitable that a given home domain will place different levels of trust on different access domains. For example, a high level of trust might be placed on a 3G access domain, whilst a very low level of trust may be placed on an Internet café WLAN.
SUMMARY
According to a first aspect of the present invention there is provided a server for managing the authentication of clients that are subscribers of a home domain within which the server is located, the server comprising means for determining whether a client that is attached to a visited domain is to be authenticated by the home domain or by said visited domain, and for signalling the result to said visited domain.
Embodiments of the present invention introduce a dynamic flexibility into the authentication process. It is now possible for the home domain to determine where the authentication is to take place based upon static properties such as client subscription, and on changing properties such as visited network identity. This results in a service architecture which optimises signalling routes when appropriate whilst maintaining financial security.
The server may comprise a non-transitory memory for storing authentication data for the clients. The server is arranged, in the event that it determines that the visited network is to be responsible for authentication, to generate session data and to send this session data to the visited network. Where the visited network is a 3G network, this data may comprise an authentication vector.
In certain embodiments of the invention, the server comprises an interface for communicating with visited domains, first processing means for receiving via said interface a registration request sent by a visited domain in respect of one of said clients, and second processing means for determining whether the request is to be authenticated by the home domain or by the visited domain. The second processing means is arranged, in the former case, to authenticate the request and signal the result to the visited domain via said interface, and, in the latter case, to signal to the visited domain via said interface that the visited domain is to be responsible for authenticating the request.
Said first processing means may be further arranged to receive via said interface a request from a visited network to transfer the authentication decision from one domain to another, in the case of a previously authenticated client. Said second processing means is arranged to make a further determination and to notify the visited network accordingly.
The server may comprise means for determining that a previous decision to delegate an authentication procedure to the visited domain is to be revoked, and for signalling that decision to the visited domain.
It is noted that the authentication procedure which may be delegated to the visited domain may be a second level procedure. A first level procedure may be carried out by the home domain based, for example, upon terminal and/or user identity, prior to conducting the second level procedure at the home domain or, if delegated, at the visited domain.
According to a second aspect of the present invention there is provided a server for authenticating clients attached to the domain within which the server is located, where the clients are subscribers of different, home domains, the server being arranged to communicate with a home domain to receive instructions therefrom as to whether a client is to be authenticate by its home domain or by the visited domain and, in the latter case, to carry out the authentication of the client based upon information received from the home domain.
According to a third aspect of the present invention there is provided a method of authenticating a client attached to a visited domain, where the client is a subscriber of a home domain, the method comprising:
    • sending an authentication request from the visited domain to the home domain in respect of said client;
    • in the home domain, determining whether the client is to be authenticated by the home domain or by said visited domain;
    • in the event that the client is to be authenticated by the home domain, carrying out said authentication in the home domain and signalling the result to the visited domain; and
    • in the event that the client is to be authenticated by the visited domain, sending authentication data from the home domain to the visited domain, and using said data in the visited domain to authenticate the client.
In the case of the AAA protocol, said authentication request may be a DIAMETER Request. In the case that the authentication is to be carried out by the home domain, this is signalled to the visited domain by sending a NACK. The result of the authentication is subsequently signalled to the visited domain by sending an ACCEPT/REJECT message. Authentication involves the exchange of a challenge and response between the home domain and the client. In the case where the authentication is to be carried out by the visited network, this is signalled to the visited domain by sending an ACK message, together with authentication data. A challenge and response exchange is conducted between the client and the visited domain.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates various protocol layers involved in an authentication procedure for a wireless terminal attached to a visited network;
FIG. 2 illustrates schematically a communications system architecture comprising visited and home domains;
FIGS. 3 a and 3 b are flow diagrams illustrating authentication decision processes carried out with an authentication server of a home domain;
FIG. 4 shows authentication related signalling for the case where a home domain takes the decision not to delegate responsibility for authentication to a visited domain;
FIG. 5 shows signalling associated with the case where a home domain decides to delegate responsibility for authentication to a visited domain for a limited period or number of tries;
FIG. 6 shows signalling associated with the delegation of authentication responsibility to a visited domain, with a subsequent decision to revoke that permission;
FIG. 7 is a signalling chart illustrating a case where a visited domain elects to request a transfer of authentication responsibility back to a home domain;
FIG. 8 is a signalling chart illustrating a case where a visited domain elects to request a transfer of authentication responsibility to it, from the home domain;
FIG. 9 illustrates a signalling flow in the case where a client is attached to a future 3GPP Long Term Evolution (LTE) based access domain; and
FIG. 10 shows a signalling flow in the case where a client is attached to an I-WLAN access domain.
DETAILED DESCRIPTION
There is illustrated in FIG. 2 a generic visited domain/home domain architecture, which allows for roaming of subscribers (referred to below as “clients”) of the home domain into the visited domain. An authentication server 1, controlled by a processor and non-transitory memory, is located within the home domain 2 and maintains in a second non-transitory memory, long-term authentication credentials of the home domain's clients. The authentication server may also act as authenticator for clients seeking to register with visited domains including the illustrated domain 3. A separate authenticator 4 is located within the visited domain 3. FIG. 2 illustrates a client 5 attached to the visited domain 3.
The authentication server 1 receives access requests from a visited domain via an interface 6, whereupon processing means 7 within the authentication server makes decisions as to whether authentications are to be performed within the home domain or can be delegated to the visited domain. The server may also determine that authentications are shared between the home and visited domains. For example, it may determine that only the first authentication is to be performed by the home domain and subsequent authentications are delegated to the visited domain, or that only every tenth authentication is to be performed by the home domain, etc. The server makes these decisions based upon certain available information. This information may include, for example, one or more of the following; visited operator identity, access network type, user-id, type of network security being used in the access network of the visited domain, type of user authentication being carried out, selected Access Point Name (APN), Quality of Service (QoS) requirement, charging rules, type of subscription, type of terminal, user location (e.g. certain geographical areas might be considered less secure from a telecommunication point of view).
FIG. 3 a is a flow diagram illustrating the delegation decision process taken by the authentication server within the home domain, namely evaluate input criteria (step 1), set authentication delegation conditions (step 2), and send authentication delegation response to visited domain (step 3). FIG. 3 b is a flow diagram illustrating a delegation revocation decision process taken by the authentication server. On the basis of newly received input criteria (e.g. received from the visited domain), the authentication server evaluates the criteria to make the revocation decision (step 4), and sends an authentication revocation to the visited domain (step 5).
In the case that the DIAMETER AAA protocol (IETF RFC 3588) is used between the visited and home domains, the access request is typically carried by a DIAMETER Request message sent between a AAA-client (possibly via AAA-proxy) in the visited domain and a HSS/AAA server within the home domain. The home authentication server responds either by sending a DIAMETER Answer message containing a DIAMETER AVP (attribute-value-pair) with authentication data to be used by the visited domain, or by sending to the visited domain a special “NACK” message, informing the visited domain to allow the authentication procedure to proceed between the client and the home domain. Depending upon the response that it receives, the visited domain either just relays authentication related authentication signalling (e.g. EAP AKA signalling), or uses the authentication data received from the home domain to initiate some or all subsequent authentication signalling with the client. It is noted that in the case of AKA authentication method, the AKA authentication vector, i.e. (RAND, XRES, AUTN, Ck, Ik) contains all of the information that the visited domain needs to assume the role of authenticator.
If the decision was to delegate authentication to the visited domain, the home domain still has the option to “revoke” the delegation, in which case any subsequent (re-) authentication takes place in the home domain. DIAMETER supports server-initiated requests that can be used for this purpose. The home domain operator can also delegate authentication to the visited domain for a limited time or a limited number of re-authentications only, after which the visited domain must relay authentication signalling back to the home domain (at least until the home domain once again delegates responsibility for authentication to the visited domain). The home domain operator can also decide that every Nth authentication should be relayed by the visited domain back to the home domain. Any one of these approaches creates “check points” at which the home domain can choose to continue with or change the applied authentication policy. As DIAMETER generally requires the maintenance of session state information (e.g. for the purpose of accounting), this state information can be extended with information enabling the visited domain to decide when to perform authentication locally and when to defer it to the home domain.
It will be appreciated that the procedure described here does offer the visited domain the opportunity to refuse to “erase” authentication data it already has, and to continue to take the authenticator role even if the home domain revokes the delegated rights. However, in such a circumstance the visited network cannot be guaranteed that it will be paid for used services. In any case, the client itself may elect not to continue.
FIG. 4 shows authentication related signalling for the case where the home domain takes the decision not to delegate responsibility for authentication to the visited domain. This may be implemented using the DIAMETER AAA protocol. The initial request Req(IDc) is supplemented with the IDv at the AAA-visited server, and forwarded to the HSS/AAA home server (possibly via a AAA proxy). The latter determines (based upon available information and policies) that no delegation is permitted, and returns a NACK to the AAA-visited server. The challenge response process is then conducted between the HSS/AAA home authenticator and the client.
FIG. 5 shows signalling associated with the case where the home domain decides to delegate responsibility for authentication for a limited period or number of tries. After receiving the request, the AAA-home server provides authentication data to the AAA-visited authenticator. The latter stores the received data and proceeds to authenticate the client using the received data and a challenge-response procedure. One or more re-authentications can be performed by the visited domain before it must revert to the home domain for a refresh (or denial) of the delegation.
FIG. 6 shows signalling associated with the case where the home domain delegates authentication responsibility to the visited domain, but subsequently decides to revoke that permission. The home domain does this by sending a Revoke (IDc) message to the AAA-visited authenticator. This will typically force the client to re-authenticate at the home domain.
It is possible that in some cases a visited domain to which authentication responsibility has previously been delegated (or which is configured to provide authentication by default), can request that the home domain change the authentication domain. This may arise, for example, in the following circumstances:
    • The visited domain wishes to reduce its authentication signalling load;
    • The visited domain wants to ensure that the home domain is continuously aware of the presence of its roaming user in the visited domain; or
    • The client requests an APN or QoS that the visited domain deems requires authentication in the home domain.
A signalling chart illustrating this process is shown in FIG. 7.
FIG. 8 shows a signalling chart illustrating the case where the home domain has determined that it must be responsible for client authentication, and the visited domain subsequently requests that responsibility for authorisation be transferred from the home domain to the visited domain. This situation may arise, for example, when a client requests an APN local to the visited domain or local breakout takes place, and in which cases the visited domain prefers to authenticate the client itself.
Referring now to FIG. 9, this illustrates a signalling flow in the case where the client (UE) is attached to a future 3GPP Long Term Evolution (LTE) based access domain (considering here OFDM, Rel8). Typically, DIAMETER AAA will be deployed between the home and visited domains. Here, the initial user authentication is performed using AKA, with the authenticator being implemented at the MME within the visited domain (the “VPLMN”). The HSS within the home domain (the “HPLMN”) provides the required authentication vector to the MME upon receipt of the request. The session key included in the authentication vector is passed by the MME to the eNB via the UPE. The flow illustrates the case where the HPLMN subsequently decides to revoke the authentication permission previously given the VPLMN, whereupon the MME sends an AUTH REQUEST to the client. The challenge and response procedure is then conducted between the client and the HPLMN and, assuming this is successful, the session keys are sent from the home HPLMN to the VPLMN.
FIG. 10 shows a signalling flow in the case where the client is attached to an I-WLAN access domain. Typically, in the case of a WLAN access domain, authentication would be performed within the home domain. However, in this example, upon receipt of the EAP_RESPONSE(IMSI), the home domain elects to delegate authentication responsibility to the access domain. In the illustrated case, it is the IASA in the VPLMN which acts as authenticator after delegation. In principle however, this role could be performed by the Access Node (AN) although this approach would be less secure.
It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention.

Claims (14)

1. A server for managing the authentication of clients that are subscribers of a home domain within which the server is located, the server comprising a processor and a non-transitory memory for storing computer program instructions, wherein when the processor executes the computer program instructions, the server is caused to:
determine whether a client that is attached to a visited domain is to be authenticated by the home domain or by said visited domain, wherein the server is configured to select the visited domain to authenticate the client when security procedures utilized in an access network of the visited domain provide the server with a level of trust in the visited domain's security capabilities, and the server is configured to select the home domain to authenticate the client when the security procedures utilized in the access network of the visited domain do not provide the server with the level of trust; and
send a message to the visited domain instructing the visited domain to either send authentication information of the client to the server for authentication in the home domain or perform an authentication in the visited domain, depending on a result of the determination;
wherein when the client is to be authenticated by the home domain, the server is caused to authenticate the client and to signal the result to the visited domain; and
wherein, in the case of a previously authenticated client, when the server receives a request from a visited network to transfer the authentication decision from one domain to another, the server is caused to make a further determination as to whether the previously authenticated client is to be authenticated by the home domain or by the visited domain, and to notify the visited network accordingly.
2. The server according to claim 1, further comprising a second non-transitory memory for storing authentication data for said clients.
3. The server according to claim 1, wherein the server is also caused to generate session data and to send the session data to the visited network when the server determines that the visited network is to be responsible for authentication.
4. The server according to claim 1, wherein the server is also caused to determine that a previous decision to delegate an authentication procedure to the visited domain is to be revoked, and to signal to the visited domain that the previous decision to delegate the authentication procedure to the visited domain is revoked.
5. The server according to claim 1, wherein the server is caused to send the message to the visited domain using an Authentication, Authorization, and Accounting (AAA) protocol.
6. The server according to claim 1, wherein the server is caused to communicate with said client using the Extensible Authentication Protocol (EAP).
7. The server according to claim 1, wherein the server is caused to communicate with said client using Universal Mobile Telecommunication Service Authentication and Key Agreement (UMTS AKA).
8. The server according to claim 3, wherein said session data is an authentication vector.
9. The server according to claim 5, wherein said AAA protocol is RADIUS or DIAMETER.
10. The server according to claim 6, wherein the authentication method is Extensible Authentication Protocol Authentication and Key Agreement (EAP AKA).
11. A method of authenticating a client attached to a visited domain, where the client is a subscriber of a home domain, the method comprising:
sending an authentication request from the visited domain to the home domain regarding the client;
in the home domain, determining whether the client must be authenticated by the home domain or whether authorization to authenticate the client can be delegated to the visited domain, wherein a server in the home domain is configured to select the visited domain to authenticate the client when security procedures utilized in an access network of the visited domain provide the server with a level of trust in the visited domain's security capabilities, and the server is configured to select the home domain to authenticate the client when the security procedures utilized in the access network of the visited domain do not provide the server with a the level of trust;
upon determining the client is to be authenticated by the home domain, sending a message from the server in the home domain to the visited domain instructing the visited domain to send authentication information of the client to the server, carrying out said authentication in the home domain, and signaling the result to the visited domain;
upon determining that authorization to authenticate the client can be delegated to the visited domain, sending authentication data from the server in the home domain to the visited domain, and using the authentication data in the visited domain to authenticate the client;
receiving by the server, a request from a visited network to transfer the authentication decision from one domain to another for a previously authenticated client; and
determining by the server, whether the previously authenticated client is to be authenticated by the home domain or by the visited domain, and notifying the visited network accordingly.
12. The method according to claim 11, wherein the home domain and the visited domain communicate using an Authentication, Authorization, and Accounting (AAA) protocol, and the home domain and the client communicate using the Extensible Authentication Protocol (EAP).
13. The method according to claim 11, wherein the Universal Mobile Telecommunication Service Authentication and Key Agreement (UMTS AKA) method is used to authenticate the client.
14. The method according to claim 12, wherein the Extensible Authentication Protocol Authentication and Key Agreement (EAP AKA) method is used to authenticate the client.
US12/521,717 2007-01-04 2007-01-04 Method and apparatus for determining an authentication procedure Active 2027-01-09 US8332912B2 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2007/050097 WO2008080637A1 (en) 2007-01-04 2007-01-04 Method and apparatus for determining an authentication procedure

Publications (2)

Publication Number Publication Date
US20110093919A1 US20110093919A1 (en) 2011-04-21
US8332912B2 true US8332912B2 (en) 2012-12-11

Family

ID=37845263

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/521,717 Active 2027-01-09 US8332912B2 (en) 2007-01-04 2007-01-04 Method and apparatus for determining an authentication procedure

Country Status (7)

Country Link
US (1) US8332912B2 (en)
EP (1) EP2103077B1 (en)
CN (1) CN101573998B (en)
AT (1) ATE501583T1 (en)
DE (1) DE602007013101D1 (en)
ES (1) ES2362444T3 (en)
WO (1) WO2008080637A1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110113484A1 (en) * 2009-11-06 2011-05-12 Red Hat, Inc. Unified system interface for authentication and authorization
US20120005731A1 (en) * 2008-12-29 2012-01-05 Samsung Electronics Co., Ltd. Handover method of mobile terminal between heterogeneous networks
US20130013923A1 (en) * 2011-07-08 2013-01-10 Motorola Solutions, Inc. Methods for obtaining authentication credentials for attaching a wireless device to a foreign 3gpp wireless domain
US8929862B2 (en) 2011-07-08 2015-01-06 Motorola Solutions, Inc. Method and apparatus for attaching a wireless device to a foreign 3GPP wireless domain using alternative authentication mechanisms
US20180184297A1 (en) * 2015-06-05 2018-06-28 Convida Wireless, Llc Unified authentication for integrated small cell and wi-fi networks
US10743368B2 (en) * 2016-09-14 2020-08-11 Huawei Technologies Co., Ltd. Network roaming protection method, related device, and system

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100488170C (en) * 2006-01-26 2009-05-13 中兴通讯股份有限公司 Update method of route trigger area in the packet wireless system
CN101399767B (en) * 2007-09-29 2011-04-20 华为技术有限公司 Method, system and apparatus for security capability negotiation during terminal moving
US8645695B2 (en) * 2009-10-07 2014-02-04 Blackberry Limited System and method for managing security key architecture in multiple security contexts of a network environment
CN101765082A (en) * 2009-12-28 2010-06-30 中兴通讯股份有限公司 Method for distinguishing authentication charging point according to regions and system
CN101873311A (en) * 2010-05-26 2010-10-27 上海动量软件技术有限公司 Method for implementing configuration clause processing of policy-based network in cloud component software system
US9143498B2 (en) * 2012-08-30 2015-09-22 Aerohive Networks, Inc. Internetwork authentication
US9092607B2 (en) * 2012-10-01 2015-07-28 Oracle International Corporation Dynamic flow control for access managers
WO2014054014A1 (en) * 2012-10-02 2014-04-10 Telefonaktiebolaget L M Ericsson (Publ) Method and device for support of multiple pdn connections
US9762679B2 (en) 2013-03-15 2017-09-12 Aerohive Networks, Inc. Providing stateless network services
US9769056B2 (en) 2013-03-15 2017-09-19 Aerohive Networks, Inc. Gateway using multicast to unicast conversion
EP2835995A1 (en) * 2013-08-09 2015-02-11 Giesecke & Devrient GmbH Methods and devices for performing a mobile network switch
KR101833654B1 (en) 2013-12-23 2018-02-28 코닌클리즈케 케이피엔 엔.브이. Method and system for providing security from a radio access network
US10659960B2 (en) 2013-12-23 2020-05-19 Koninklijke Kpn N.V. Method and system for providing security from a radio access network
US9992619B2 (en) 2014-08-12 2018-06-05 Aerohive Networks, Inc. Network device based proximity beacon locating
FR3039954A1 (en) * 2015-08-05 2017-02-10 Orange METHOD AND DEVICE FOR IDENTIFYING VISIT AND HOME AUTHENTICATION SERVERS
JP6917469B2 (en) * 2017-10-10 2021-08-11 株式会社Nttドコモ Security establishment method, terminal equipment and network equipment
AU2019293046B2 (en) * 2018-06-30 2022-03-31 Nokia Solutions And Networks Oy Handling failure of Non-3GPP access to 5GCN not being allowed
US11863348B2 (en) * 2021-07-06 2024-01-02 Cisco Technology, Inc. Message handling between domains
CN116760610A (en) * 2023-06-30 2023-09-15 中国科学院空天信息创新研究院 User cross-domain authentication system, method, equipment and medium under network limited condition

Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6035198A (en) * 1996-09-02 2000-03-07 Siemens Aktiengesellschaft Method and system for determining the location of a mobile radiocommunication subscriber registered in a cellular mobile radiotelephone network
WO2002069605A2 (en) 2001-02-21 2002-09-06 Nokia Corporation Method and system for delegation of security procedures to a visited domain
WO2003065640A1 (en) 2002-01-29 2003-08-07 Plumtree Software, Inc. Single sign-on over the internet using public-key cryptography
US20040131023A1 (en) * 2003-01-03 2004-07-08 Otso Auterinen Communications system and method
US20040166874A1 (en) * 2002-11-14 2004-08-26 Nadarajah Asokan Location related information in mobile communication system
US20050198036A1 (en) * 2003-11-28 2005-09-08 Nicolas Nedkov Systems and methods for controlling access to a public data network from a visited access provider
US20060104306A1 (en) * 2004-11-15 2006-05-18 Maria Adamczyk Application services infrastructure for next generation networks
US20070100981A1 (en) * 2005-04-08 2007-05-03 Maria Adamczyk Application services infrastructure for next generation networks including one or more IP multimedia subsystem elements and methods of providing the same
US20070127495A1 (en) * 2003-01-10 2007-06-07 De Gregorio Jesus-Angel Single sign-on for users of a packet radio network roaming in a multinational operator network
US20080072301A1 (en) * 2004-07-09 2008-03-20 Matsushita Electric Industrial Co., Ltd. System And Method For Managing User Authentication And Service Authorization To Achieve Single-Sign-On To Access Multiple Network Interfaces
US20080155659A1 (en) * 2006-12-26 2008-06-26 Ciena Corporation Methods and systems for distributed authentication and caching for internet protocol multimedia subsystem and other session initiation protocol systems
US20080270794A1 (en) * 2005-11-04 2008-10-30 Ralner Falk Method and Server for Providing Mobility Key
US7480801B2 (en) * 2002-01-24 2009-01-20 Siemens Aktiengesellschaft Method for securing data traffic in a mobile network environment
US7484012B2 (en) * 2001-12-19 2009-01-27 International Business Machines Corporation User enrollment in an e-community
US7506370B2 (en) * 2003-05-02 2009-03-17 Alcatel-Lucent Usa Inc. Mobile security architecture
US7626963B2 (en) * 2005-10-25 2009-12-01 Cisco Technology, Inc. EAP/SIM authentication for mobile IP to leverage GSM/SIM authentication infrastructure
US20090313466A1 (en) * 2006-12-19 2009-12-17 Telefonaktiebolaget L M Ericsson (Publ) Managing User Access in a Communications Network
US7639802B2 (en) * 2004-09-27 2009-12-29 Cisco Technology, Inc. Methods and apparatus for bootstrapping Mobile-Foreign and Foreign-Home authentication keys in Mobile IP
US20100097977A1 (en) * 2006-12-28 2010-04-22 Telefonaktiebolaget L M Ericsson (Publ) Mobile IP Proxy
US7707293B2 (en) * 2005-09-27 2010-04-27 Huawei Technologies Co., Ltd. Method, system and apparatuses for transferring session request
US7774828B2 (en) * 2003-03-31 2010-08-10 Alcatel-Lucent Usa Inc. Methods for common authentication and authorization across independent networks
US7870389B1 (en) * 2002-12-24 2011-01-11 Cisco Technology, Inc. Methods and apparatus for authenticating mobility entities using kerberos
US7881468B2 (en) * 2005-04-08 2011-02-01 Telefonaktiebolaget L M Ericsson (Publ) Secret authentication key setup in mobile IPv6
US7882346B2 (en) * 2002-10-15 2011-02-01 Qualcomm Incorporated Method and apparatus for providing authentication, authorization and accounting to roaming nodes
US7900242B2 (en) * 2001-07-12 2011-03-01 Nokia Corporation Modular authentication and authorization scheme for internet protocol
US7934094B2 (en) * 2003-06-18 2011-04-26 Telefonaktiebolaget Lm Ericsson (Publ) Method, system and apparatus to support mobile IP version 6 services
US7962122B2 (en) * 2003-05-23 2011-06-14 Telefonaktiebolaget Lm Ericsson (Publ) Secure traffic redirection in a mobile communication system
US8213900B2 (en) * 2006-02-23 2012-07-03 Togewa Holding Ag Switching system and corresponding method for unicast or multicast end-to-end data and/or multimedia stream transmissions between network nodes
US8230073B1 (en) * 2005-01-21 2012-07-24 Apple Inc. Service templates for an IP multimedia subsystem

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1835621B (en) * 2005-03-14 2010-05-12 上海贝尔阿尔卡特股份有限公司 Method and device for security user's layer mobile positioning in radio network

Patent Citations (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6035198A (en) * 1996-09-02 2000-03-07 Siemens Aktiengesellschaft Method and system for determining the location of a mobile radiocommunication subscriber registered in a cellular mobile radiotelephone network
WO2002069605A2 (en) 2001-02-21 2002-09-06 Nokia Corporation Method and system for delegation of security procedures to a visited domain
US6879690B2 (en) * 2001-02-21 2005-04-12 Nokia Corporation Method and system for delegation of security procedures to a visited domain
US7900242B2 (en) * 2001-07-12 2011-03-01 Nokia Corporation Modular authentication and authorization scheme for internet protocol
US7484012B2 (en) * 2001-12-19 2009-01-27 International Business Machines Corporation User enrollment in an e-community
US7480801B2 (en) * 2002-01-24 2009-01-20 Siemens Aktiengesellschaft Method for securing data traffic in a mobile network environment
WO2003065640A1 (en) 2002-01-29 2003-08-07 Plumtree Software, Inc. Single sign-on over the internet using public-key cryptography
US7882346B2 (en) * 2002-10-15 2011-02-01 Qualcomm Incorporated Method and apparatus for providing authentication, authorization and accounting to roaming nodes
US20040166874A1 (en) * 2002-11-14 2004-08-26 Nadarajah Asokan Location related information in mobile communication system
US7870389B1 (en) * 2002-12-24 2011-01-11 Cisco Technology, Inc. Methods and apparatus for authenticating mobility entities using kerberos
US20040131023A1 (en) * 2003-01-03 2004-07-08 Otso Auterinen Communications system and method
US20070127495A1 (en) * 2003-01-10 2007-06-07 De Gregorio Jesus-Angel Single sign-on for users of a packet radio network roaming in a multinational operator network
US7774828B2 (en) * 2003-03-31 2010-08-10 Alcatel-Lucent Usa Inc. Methods for common authentication and authorization across independent networks
US7506370B2 (en) * 2003-05-02 2009-03-17 Alcatel-Lucent Usa Inc. Mobile security architecture
US7962122B2 (en) * 2003-05-23 2011-06-14 Telefonaktiebolaget Lm Ericsson (Publ) Secure traffic redirection in a mobile communication system
US7934094B2 (en) * 2003-06-18 2011-04-26 Telefonaktiebolaget Lm Ericsson (Publ) Method, system and apparatus to support mobile IP version 6 services
US20050198036A1 (en) * 2003-11-28 2005-09-08 Nicolas Nedkov Systems and methods for controlling access to a public data network from a visited access provider
US20080072301A1 (en) * 2004-07-09 2008-03-20 Matsushita Electric Industrial Co., Ltd. System And Method For Managing User Authentication And Service Authorization To Achieve Single-Sign-On To Access Multiple Network Interfaces
US7639802B2 (en) * 2004-09-27 2009-12-29 Cisco Technology, Inc. Methods and apparatus for bootstrapping Mobile-Foreign and Foreign-Home authentication keys in Mobile IP
US20060104306A1 (en) * 2004-11-15 2006-05-18 Maria Adamczyk Application services infrastructure for next generation networks
US8230073B1 (en) * 2005-01-21 2012-07-24 Apple Inc. Service templates for an IP multimedia subsystem
US20070100981A1 (en) * 2005-04-08 2007-05-03 Maria Adamczyk Application services infrastructure for next generation networks including one or more IP multimedia subsystem elements and methods of providing the same
US7881468B2 (en) * 2005-04-08 2011-02-01 Telefonaktiebolaget L M Ericsson (Publ) Secret authentication key setup in mobile IPv6
US7707293B2 (en) * 2005-09-27 2010-04-27 Huawei Technologies Co., Ltd. Method, system and apparatuses for transferring session request
US7626963B2 (en) * 2005-10-25 2009-12-01 Cisco Technology, Inc. EAP/SIM authentication for mobile IP to leverage GSM/SIM authentication infrastructure
US20080270794A1 (en) * 2005-11-04 2008-10-30 Ralner Falk Method and Server for Providing Mobility Key
US8213900B2 (en) * 2006-02-23 2012-07-03 Togewa Holding Ag Switching system and corresponding method for unicast or multicast end-to-end data and/or multimedia stream transmissions between network nodes
US20090313466A1 (en) * 2006-12-19 2009-12-17 Telefonaktiebolaget L M Ericsson (Publ) Managing User Access in a Communications Network
US20080155659A1 (en) * 2006-12-26 2008-06-26 Ciena Corporation Methods and systems for distributed authentication and caching for internet protocol multimedia subsystem and other session initiation protocol systems
US20100097977A1 (en) * 2006-12-28 2010-04-22 Telefonaktiebolaget L M Ericsson (Publ) Mobile IP Proxy

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Symmetric security procedures for H.323 mobility in H.510" ITU-T Standard in Force (I), International Telecommunication Union, Geneva CH, No. H530 3/2.Mar. 29, 2002, XP017401532 * Sections 7 and 8*.
Miyoung Kim Youngsong Mun Soongsil University: "Localized Key Management for AAA in Mobile IPv6" IETF Standard-Working-Draft, Internet Engineering Task Force. IETF, CH, Oct. 2002, XP015032831.
Stefano M Faccin Franck Le Nokia Research Center: "AAA Local Security Association (LSA) : The Temporary Shared Key (TSK)" IETF Standard-Working-Draft, Internet Engineering Task Force, IETF, CH. Jul. 2001, XP015031409.
Wireless World Research Forum: "Research Issues for Fast Authentication in Inter-Domain Handover" WWRF. [Online] Feb. 2004, XP002425724 Retrieved from the Internet URL:http://www.docomoeurolabs.de/pdf/publications/STL-research-issues-fast-authentication.pdf> [retrieved on Mar. 20, 2007] * Section 3 and 4*. *
Wireless World Research Forum: "Research Issues for Fast Authentication in Inter-Domain Handover" WWRF. [Online] Feb. 2004, XP002425724 Retrieved from the Internet URL:http://www.docomoeurolabs.de/pdf/publications/STL—research—issues—fast—authentication.pdf> [retrieved on Mar. 20, 2007] * Section 3 and 4*.

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120005731A1 (en) * 2008-12-29 2012-01-05 Samsung Electronics Co., Ltd. Handover method of mobile terminal between heterogeneous networks
US8887251B2 (en) * 2008-12-29 2014-11-11 Samsung Electronics Co., Ltd. Handover method of mobile terminal between heterogeneous networks
US9479509B2 (en) * 2009-11-06 2016-10-25 Red Hat, Inc. Unified system for authentication and authorization
US11537752B2 (en) 2009-11-06 2022-12-27 Red Hat, Inc. Unified system for authentication and authorization
US20110113484A1 (en) * 2009-11-06 2011-05-12 Red Hat, Inc. Unified system interface for authentication and authorization
US10482286B2 (en) 2009-11-06 2019-11-19 Red Hat, Inc. Unified system for authentication and authorization
US8699709B2 (en) * 2011-07-08 2014-04-15 Motorola Solutions, Inc. Methods for obtaining authentication credentials for attaching a wireless device to a foreign 3GPP wireless domain
US8929862B2 (en) 2011-07-08 2015-01-06 Motorola Solutions, Inc. Method and apparatus for attaching a wireless device to a foreign 3GPP wireless domain using alternative authentication mechanisms
US20130013923A1 (en) * 2011-07-08 2013-01-10 Motorola Solutions, Inc. Methods for obtaining authentication credentials for attaching a wireless device to a foreign 3gpp wireless domain
US20180184297A1 (en) * 2015-06-05 2018-06-28 Convida Wireless, Llc Unified authentication for integrated small cell and wi-fi networks
US11032706B2 (en) * 2015-06-05 2021-06-08 Convida Wireless, Llc Unified authentication for integrated small cell and Wi-Fi networks
US11818566B2 (en) 2015-06-05 2023-11-14 Ipla Holdings Inc. Unified authentication for integrated small cell and Wi-Fi networks
US10743368B2 (en) * 2016-09-14 2020-08-11 Huawei Technologies Co., Ltd. Network roaming protection method, related device, and system
US11109230B2 (en) 2016-09-14 2021-08-31 Huawei Technologies Co., Ltd. Network roaming protection method, related device, and system

Also Published As

Publication number Publication date
ATE501583T1 (en) 2011-03-15
EP2103077A1 (en) 2009-09-23
EP2103077B1 (en) 2011-03-09
DE602007013101D1 (en) 2011-04-21
US20110093919A1 (en) 2011-04-21
CN101573998B (en) 2013-01-02
ES2362444T3 (en) 2011-07-05
WO2008080637A1 (en) 2008-07-10
CN101573998A (en) 2009-11-04

Similar Documents

Publication Publication Date Title
US8332912B2 (en) Method and apparatus for determining an authentication procedure
RU2745719C2 (en) Implementation of inter-network connection function using untrusted network
US10362617B2 (en) Method and system for a mobile communication device to access services
EP1693995B1 (en) A method for implementing access authentication of wlan user
AU2005236981B2 (en) Improved subscriber authentication for unlicensed mobile access signaling
US9503890B2 (en) Method and apparatus for delivering keying information
EP3120515B1 (en) Improved end-to-end data protection
US20070143613A1 (en) Prioritized network access for wireless access networks
US20080026724A1 (en) Method for wireless local area network user set-up session connection and authentication, authorization and accounting server
FI121560B (en) Authentication in a mobile communication system
KR102390380B1 (en) Support of emergency services over wlan access to 3gpp evolved packet core for unauthenticated users
EP2293611A1 (en) A method, apparatus, system and server for network authentication
JPWO2007097101A1 (en) Wireless access system and wireless access method
US20150058938A1 (en) Integrated IP Tunnel and Authentication Protocol based on Expanded Proxy Mobile IP
EP2215803A1 (en) Network access authentication
CN113676904B (en) Slice authentication method and device
US20070099597A1 (en) Authentication in a communication network
US20230111913A1 (en) Non-3gpp handover preparation
Kwon et al. Mobility Management for UMTS-WLAN Seamless Handover; Within the Framework of Subscriber Authentication
Said et al. A Comparative Study on Security implementation in EPS/LTE and WLAN/802.11

Legal Events

Date Code Title Description
AS Assignment

Owner name: TELEFONAKTIEBOLAGET LM ERICSSON (PUBL), SWEDEN

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WALKER, JOHN MICHAEL;NASLUND, MATS;SIGNING DATES FROM 20070119 TO 20070122;REEL/FRAME:023722/0984

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8