WO2005015875A1 - Transparent access authentication in gprs core networks - Google Patents

Transparent access authentication in gprs core networks Download PDF

Info

Publication number
WO2005015875A1
WO2005015875A1 PCT/EP2004/008574 EP2004008574W WO2005015875A1 WO 2005015875 A1 WO2005015875 A1 WO 2005015875A1 EP 2004008574 W EP2004008574 W EP 2004008574W WO 2005015875 A1 WO2005015875 A1 WO 2005015875A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
address
server
msisdn
imsi
Prior art date
Application number
PCT/EP2004/008574
Other languages
French (fr)
Inventor
Stephan Blicker
Matthias Britsch
Original Assignee
T-Mobile Deutschland Gmbh
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 T-Mobile Deutschland Gmbh filed Critical T-Mobile Deutschland Gmbh
Priority to EP04763655A priority Critical patent/EP1649661B1/en
Priority to US10/566,584 priority patent/US7770216B2/en
Priority to CA2532083A priority patent/CA2532083C/en
Priority to PL04763655T priority patent/PL1649661T3/en
Priority to DE602004008293T priority patent/DE602004008293T2/en
Publication of WO2005015875A1 publication Critical patent/WO2005015875A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity

Definitions

  • the present invention relates to a method and system for transparent access authentication in 2G and 2.5G Mobile Access Networks.
  • This includes communication networks of the GSM-, GPRS- and UMTS-standard well known to skilled persons.
  • IMS Multimedia Subsystem
  • IMS SIM IMS SIM
  • AKA authentication and key agreement
  • the present invention describes a. method for application layer authentication of subscribers, connected to the authenticating network domain by a 2G or 2.5G General Packet Radio Service (GPRS) core network or a 3G UMTS network.
  • the authentication will be based on data which is assembled by the network layer during establishment of a PDP context in GPRS networks. This information is secured by standard SIM card application.
  • the further described mechanism is also applicable there. No standard would be touched in any way while using a 2G or 2.5G access network because no authentication on application layer is foreseen in the standard.
  • Figure 1 depicts the general architecture of the system for carrying out the invention
  • Figure 2 depicts an embodiment of the invention with migration to IMS compliant architecture.
  • the Serving GPRS Support Node is authenticating the subscriber using the A3/A8 algorithm based on the end devices SIM card in case of GSM and 2.5G GPRS and EDGE access network.
  • the Gateway GPRS Support Node 1 receives a context creation request and queries a Radius (Registration) server 2 (Remote Authentification Dial-In User Service) to get an IP address assigned for the particular PDP context.
  • a Radius (Registration) server 2 Remote Authentification Dial-In User Service
  • the Radius server 2 receives the MSISDN and/or the IMSI of the subscriber. 1 So. in. the session database 3 of the Radius server 2 there is stored for each PDP context a pair of -IP address and IMSI/MSISDN.
  • the GGSN 1 filters all . packets running through the PDP context • once established, for the correct IP. source address.
  • the GGSN 1 checks matching TEID/IP address pairs, thus preventing falsification of source addresses and so called "IP spoofing" for the complete lifecycle of the PDP context.
  • the TEID unambiguously identifies a tunnel endpoint in .
  • the receiving GTP-U GPRS Tunnelling Protocol - User
  • GTP-C GPRS Tunnelling Protocol - Control
  • the receiving side of a GTP tunnel locally assigns the TEID value for the transmitting side to use.
  • the TEID values are exchanged between tunnel endpoints using GTP-C messages (or RANAP (Radio Access Network Application Part) in the UTRAN (UMTS terrestrial* .
  • a subscriber database.4 exists that stores all PublDs the subscriber is using in the domain, referring it ' to his PrivID, which is unique in the respective application domain.
  • the PrivID is correlated with an MSISDN and/or IMSI .
  • the registration proxy 5 Upon receiving the registration request, the registration proxy 5 queries the subscriber database 4 containing the subscribers IDs (both public and private) together with the subscriber database 4 containing the subscribers IDs (both public and private) together with the subscriber database 4 containing the subscribers IDs (both public and private) together with the subscriber database 4 containing the subscribers IDs (both public and private) together with the subscriber database 4 containing the subscribers IDs (both public and private) together with the
  • MSISDN/IMSI This data is stored in a table on the proxy server. platform.
  • the proxy server 5 queries the session database 3 of the Radius* server 2 in order to get the assigned IP address of that session and the IMSI/MSISDN already authenticated by the network' s Home Location ' . Register (HLR) .
  • HLR Home Location ' . Register
  • the • authentication of the HLR guarantees further that the IP address can be considered to be authenticated as well*. Also this information is stored in the table o the proxy server .platform.
  • the proxy server 5 starts the authentication procedure according to the invention.
  • the proxy server 5 checks IMSI/MSISDN from Radius server 2 database 3 and application domain database 4 for match. If the pairs are not ' matching, the subscriber has tried to register with an incorrect PrivID, which is not correlated with his IMSI/MSISDN, if the pairs are matching the next step is performed.
  • Second step is checking the subscribers IP address in the IP network layer, meaning in the IP packet overhead field for source address for match with the IP address assigned by the Radius server 3. As the IP address was assigned to an IMSI/MSISDN-authenticated session, also the IP address can be considered as authenticated. If the pairs are not matching, the subscriber used an incorrect IP address, if the pairs are ' matching the subsequent step is performed.
  • the proxy server 5 parses the application layer for IP addresses given in the headers of e.g. SIP registration message, SDP message bodies, etc and checks for match with the IP address in, which was already checked for match with the IP address assigned by the Radius server 2. If the pairs are not matching the subscriber used incorrect signalling information, e. g. response addresses, etc. If the pairs are matching, the session setup can be considered as authenticated. In all subsequent messages arriving at the proxy server 5, it checks for match of IP ' address in the IP packet overhead field for source address with that in * the application layer protocol header fields and verifies the matching * pairs * against the IP address assigned by the Radius server 2.
  • PublDs are used in the following session, the PublDs are checked against the PrivID which was stored in a table on the proxy server platform after querying the application domains database 4.
  • the described functionality gives the network operator the opportunity to run authentication transparently to the end ' device, without requiring proprietary extensions and functions on network or client side.
  • SIP based signalling the migration to fully standard compliant UMTS Rel .5 mechanisms and a strategy for parallel operation is necessary, this will be described now.
  • the IMS domain as standardised for UMTS Rel.5. will include its own authentication mechanism, it is necessary to support a scenario where the subscribers are migrating to ISIM enabled end devices. To exploit the benefits of the standardised authentication mechanism, both mechanisms have to be supported in parallel. This is done by an additional function that checks each incoming signalling message, first for the protocol, if ' itis any other protocol than SIP, the session is routed to the0 proxy server 5.
  • the. same routing decision is taken if the message is based, on SIP, but the client does not support standardised UMTS Rel .5 authentication. If the client.5 does support ' standardised authentication method, e.g. is ISIM enabled, the message is routed to- the standard compliant Proxy Call State Control Function (P-CSCF) .
  • P-CSCF Proxy Call State Control Function
  • First trigger for routing decisions' is the protocol type, as described above. Further triggers could be the key exchange mechanism used for0 s.etting up the secured connection between UE and P-CSCF ( if the end device is starting key agreement, it can be considered as standard compliant and the request is routed to the P-CSCF), or other elements included in the UMTS Rel .5 . header as well as any private extension, which is, however, 5 . possible* but not * necessary. If trigger points ' vailable in signalling should be insufficient, also database lookups can be used to base routing decisions on.
  • the authentication procedure is as follows 30. First, a decision is required by which node P-CSCF 6 or proxy ' server 5 the register shall be routed For this, a routing module 7 is provided which will be the standard entry point for all messages. The routing module 7 decides by evaluation of PrivID which node will handle the message. The. routing module 7 refers to subdomains (e.g. user@gprs.tmo.de and user@tmo.umts.de) within the domain part of the Network Access Identifier (NAI) , see 3GPP specification 23.228. This requires that NAIs for 3G subscribers have to provide subdomains.
  • NAI Network Access Identifier
  • the routing module 7 shall set a routing entry, by using only the PrivID, subsequent messages shall be identified by the IP source address listed in the routing table.
  • the routing module 7 identifies the responsible proxy function, i.e. proxy server 5 or P-CSCF 6, by evaluating the PrivID (URIs subdomains) This rises the request towards IMSI/MSISDN :and URIs to be chosen according to this functionality.
  • PrivID URIs subdomains
  • the proxy server 5 must be extended, and authenticate the subscribers by use of the IP address, subsequently resolving the IMSI/MSISDN and matching of the * particular identifier of the protocol, which is stored in the subscriber profile of the subscriber database 4. This requires the population of the subscriber profile with the required data elements and extension of the routing module to enable protocol dependent routing.
  • the application platform ' has to know which type of access network is used to adapt service delivery accordingly. This requires that a change request has to be stated against the SGSN to enable it to send the access type to the GGSN which includes it in the radius request, so the access network type will be available in the session database 3. This enables all applications to request the access network type and use it, e.g. for Quality of Service (QoS) means.
  • QoS Quality of Service
  • 2.5G. second and half generation e. g. GPRS, EDGE
  • 2G second generation e. g. GSM
  • 3G third generation (e. g. UMTS)

Abstract

The present invention relates to a method for application layer authentication of subscribers connected to the authenticating network domain by a 2G or 2.5G GPRS core network or a 3G UMTS network, characterised by using data which are assembled by the network layer during establishment of a PDP context in GPRS networks. The invention comprises System of units in a mobile telecommunication network, including at least a first authentication unit which is connected via a data line to a second unit which assembles data according to the described method.

Description

TRANSPARENT ACCESS AUTHENTICATION IN GPRS CORE NETWORKS
The present invention relates to a method and system for transparent access authentication in 2G and 2.5G Mobile Access Networks. This includes communication networks of the GSM-, GPRS- and UMTS-standard well known to skilled persons.
In standardisation of Universal Mobile Telecommunication System (UMTS Rel.5) comprehensive means are foreseen to perform authentication on the application layer with no need to interwork with the underlying radio and transport • networks. The mechanisms are1 based on* the assumption that a specific environment is prepared .for deployment of IP
Multimedia Subsystem (IMS) services. It includes ' the use of IMS SIM (ISIM) application, which in turn requires Rel .99UICC '._.s in the connected end devices to handle the authentication and key agreement (AKA) . In case of deployment of IMS and IMS based services in a network environment which is characterised by the use of SIM cards, the standardised authentication mechanism will not be applicable . It is the object of the invention to provide method and system for transparent access authentication which allow it to run authentication transparently to the end device, without • requiring proprietary extensions and functions on network or client side.
This object is achieved by providing a method and .system as described in the independent claims. Other features which are considered to be characteristic for the invention are set forth in the dependent claims .
The present invention describes a. method for application layer authentication of subscribers, connected to the authenticating network domain by a 2G or 2.5G General Packet Radio Service (GPRS) core network or a 3G UMTS network. The authentication will be based on data which is assembled by the network layer during establishment of a PDP context in GPRS networks. This information is secured by standard SIM card application. As the same mechanisms are used for authentication in 3G networks, the further described mechanism is also applicable there. No standard would be touched in any way while using a 2G or 2.5G access network because no authentication on application layer is foreseen in the standard. For UMTS Rel .5 standards and following, the standard foresees specific methods. The use of the further described method would be possible,__, although the standardised authentication mechanism needs to be switched off. Switching off the standardised authentication mechanism could be interpreted as standard sensitive, but subsequent use of the further described mechanism would be standard compliant again . Further, a migration path to UMTS Rel .5 standardised. authentication and the concept for parallel us.e of both mechanisms is described.
The invention will now be described in further detail with reference to the drawings .
Figure 1 depicts the general architecture of the system for carrying out the invention; Figure 2 depicts an embodiment of the invention with migration to IMS compliant architecture.
With reference to Figure 1, during PDP context establishment the Serving GPRS Support Node (SGSN) is authenticating the subscriber using the A3/A8 algorithm based on the end devices SIM card in case of GSM and 2.5G GPRS and EDGE access network.
The Gateway GPRS Support Node 1 (GGSN) . receives a context creation request and queries a Radius (Registration) server 2 (Remote Authentification Dial-In User Service) to get an IP address assigned for the particular PDP context. Within the context the Radius server 2 receives the MSISDN and/or the IMSI of the subscriber.1 So. in. the session database 3 of the Radius server 2 there is stored for each PDP context a pair of -IP address and IMSI/MSISDN. Based on the tunnel endpoint ID (TEID) the GGSN 1 filters all. packets running through the PDP context • once established, for the correct IP. source address. This means the GGSN 1 checks matching TEID/IP address pairs, thus preventing falsification of source addresses and so called "IP spoofing" for the complete lifecycle of the PDP context. The TEID unambiguously identifies a tunnel endpoint in. the receiving GTP-U (GPRS Tunnelling Protocol - User) or GTP-C (GPRS Tunnelling Protocol - Control) protocol entity. The receiving side of a GTP tunnel locally assigns the TEID value for the transmitting side to use. The TEID values are exchanged between tunnel endpoints using GTP-C messages (or RANAP (Radio Access Network Application Part) in the UTRAN (UMTS terrestrial*. Radio Access Network In the application domain a subscriber database.4 exists that stores all PublDs the subscriber is using in the domain, referring it' to his PrivID, which is unique in the respective application domain. The PrivID is correlated with an MSISDN and/or IMSI .
In the request the user gives his PrivID for registration.
Upon receiving the registration request, the registration proxy 5 queries the subscriber database 4 containing the subscribers IDs (both public and private) together with the
MSISDN/IMSI. This data is stored in a table on the proxy server. platform.
Subsequently the proxy server 5 queries the session database 3 of the Radius* server 2 in order to get the assigned IP address of that session and the IMSI/MSISDN already authenticated by the network' s Home Location'. Register (HLR) . The • authentication of the HLR guarantees further that the IP address can be considered to be authenticated as well*. Also this information is stored in the table o the proxy server .platform.
Now the proxy server 5 starts the authentication procedure according to the invention.
First, the proxy server 5 checks IMSI/MSISDN from Radius server 2 database 3 and application domain database 4 for match. If the pairs are not' matching, the subscriber has tried to register with an incorrect PrivID, which is not correlated with his IMSI/MSISDN, if the pairs are matching the next step is performed.
Second step is checking the subscribers IP address in the IP network layer, meaning in the IP packet overhead field for source address for match with the IP address assigned by the Radius server 3. As the IP address was assigned to an IMSI/MSISDN-authenticated session, also the IP address can be considered as authenticated. If the pairs are not matching, the subscriber used an incorrect IP address, if the pairs are' matching the subsequent step is performed.
The proxy server 5 parses the application layer for IP addresses given in the headers of e.g. SIP registration message, SDP message bodies, etc and checks for match with the IP address in, which was already checked for match with the IP address assigned by the Radius server 2. If the pairs are not matching the subscriber used incorrect signalling information, e. g. response addresses, etc. If the pairs are matching, the session setup can be considered as authenticated. In all subsequent messages arriving at the proxy server 5, it checks for match of IP' address in the IP packet overhead field for source address with that in* the application layer protocol header fields and verifies the matching* pairs * against the IP address assigned by the Radius server 2. If PublDs are used in the following session, the PublDs are checked against the PrivID which was stored in a table on the proxy server platform after querying the application domains database 4. The described functionality gives the network operator the opportunity to run authentication transparently to the end' device, without requiring proprietary extensions and functions on network or client side. In case of SIP based signalling, the migration to fully standard compliant UMTS Rel .5 mechanisms and a strategy for parallel operation is necessary, this will be described now. As the IMS domain as standardised for UMTS Rel.5. will include its own authentication mechanism, it is necessary to support a scenario where the subscribers are migrating to ISIM enabled end devices. To exploit the benefits of the standardised authentication mechanism, both mechanisms have to be supported in parallel. This is done by an additional function that checks each incoming signalling message, first for the protocol, if 'itis any other protocol than SIP, the session is routed to the0 proxy server 5.
With reference to Figure 2, the. same routing decision is taken if the message is based, on SIP, but the client does not support standardised UMTS Rel .5 authentication. If the client.5 does support 'standardised authentication method, e.g. is ISIM enabled, the message is routed to- the standard compliant Proxy Call State Control Function (P-CSCF) . First trigger for routing decisions' is the protocol type, as described above. Further triggers could be the key exchange mechanism used for0 s.etting up the secured connection between UE and P-CSCF ( if the end device is starting key agreement, it can be considered as standard compliant and the request is routed to the P-CSCF), or other elements included in the UMTS Rel .5 . header as well as any private extension, which is, however, 5 . possible* but not* necessary. If trigger points ' vailable in signalling should be insufficient, also database lookups can be used to base routing decisions on.
The authentication procedure is as follows 30. First, a decision is required by which node P-CSCF 6 or proxy ' server 5 the register shall be routed For this, a routing module 7 is provided which will be the standard entry point for all messages. The routing module 7 decides by evaluation of PrivID which node will handle the message. The. routing module 7 refers to subdomains (e.g. user@gprs.tmo.de and user@tmo.umts.de) within the domain part of the Network Access Identifier (NAI) , see 3GPP specification 23.228. This requires that NAIs for 3G subscribers have to provide subdomains.
The routing module 7 shall set a routing entry, by using only the PrivID, subsequent messages shall be identified by the IP source address listed in the routing table.
The routing module 7 identifies the responsible proxy function, i.e. proxy server 5 or P-CSCF 6, by evaluating the PrivID (URIs subdomains) This rises the request towards IMSI/MSISDN :and URIs to be chosen according to this functionality. In case other protocols shall be used beside SIP, such as e.g. SMTP, HTTP, SOAP (.NET), etc, the proxy server 5 must be extended, and authenticate the subscribers by use of the IP address, subsequently resolving the IMSI/MSISDN and matching of the* particular identifier of the protocol, which is stored in the subscriber profile of the subscriber database 4. This requires the population of the subscriber profile with the required data elements and extension of the routing module to enable protocol dependent routing.
In case separate access networks are used-, the application platform' has to know which type of access network is used to adapt service delivery accordingly. This requires that a change request has to be stated against the SGSN to enable it to send the access type to the GGSN which includes it in the radius request, so the access network type will be available in the session database 3. This enables all applications to request the access network type and use it, e.g. for Quality of Service (QoS) means.
Abbreviations
2.5G. second and half generation (e. g. GPRS, EDGE) 2G second generation (e. g. GSM)
3G third generation (e. g. UMTS)
AKA authentication and key agreement
CC Circuit Switched
IMS IP multimedia subsystem IMS ' International Mobile Subscriber Identity ISIM IMS' SIM
MSISDN Mobile Station ISDN Number* NAI Network Access Identifier P-CSCF Proxy-Call-State-Control-Func ion SIM (card) (GSM) Subscriber Identity Module (card) SIP Session Initiation Protocol TEID Tunnel Endpoint ID UE User Equipment UICC UMTS 'TC Card UMTS Universal mobile telecommunication system URI Uniform Ressource Locator

Claims

Claims
1. Method for application layer authentication of subscribers connected to the authenticating network domain by a 2G or 2.5G GPRS core network or a 3G UMTS network, characterised by using data which are assembled by the network layer during establishment of a PDP context in GPRS networks.
2. Method according to claim*!, comprising the step that during PDP context establishment the . Serving GPRS Support Node (SGSN)* is authenticating the subscriber using the A3/A8* algorithm based on the end devices SIM card.
3. Method according to any preceding claim, comprising the* step that a Gateway GPRS Support Node (1)' receives, a context creation request and queries a registration server (2) to get an IP address assigned for the particular PDP context, and within the context the registration server 2 receives the MSISDN and/or the IMSI of the subscriber and stores for each PDP context a pair of IP address and .IMSI/MSISDN in a session, database (3) .
4. Method according to any preceding claim, comprising .the step that* a proxy server (5) is provided which checks IMSI/MSISDN from a radius server (2) database (3) and IMSI/MSISDN from application domain database (4) for match .
5. Method according to any preceding claim, comprising the step that if the IMSI/MSISDN pairs are ■ matching, the radius server (5) checks the subscribers IP address in the ■ IP • network .layer for match, with the IP address assigned by the Radius server (3) .
6. Method according to any preceding claim, comprising the step that the proxy server (5)* parses the application layer for IP addresses given in the headers' of registration messages and checks for match with the IP. address which was already checked for match with the IP address assigned by the radius server (2) .
7. Method according to any preceding claim,' comprising the* step that in all subsequent messages arriving at the proxy server (5) , it checks for match .of IP address in the IP packet overhead field for source address with that in the application' layer protocol header fields and verifies the matching pairs against the IP address assigned by the Radius server (2) .
8. Method according to any preceding claim, that a routing module (7) is provided which is the standard entry point for all messages and decides by evaluation of PrivID which network node will handle the .message .•
9. System of units in a mobile telecommunication network, . - characterised that at least a .first authentication unit •(2) is connected via a data line to a second unit (5.; β) which assembles data according to the method of claim 1.
10. System according to claim 9, wherein the first unit comprises a registration server (2) .
11. System according to claim 9 or 10, wherein the first unit , (2) is connected to a session database (3) .
2. System according to any of claims 9 to 11, wherein the second unit comprises a proxy server (5) .
13. System according to any of claims 9 to 12, wherein the second unit comprises a Proxy Call State Control Function (6) .
14. System according to any of claims 9 to 13, wherein the second unit (5; 6) is connected to a subscriber database (4) .
15. System according to any of claims 9 to 14, wherein a routing module (7) is provided decides by evaluation of PrivID which network node will handle the message.
PCT/EP2004/008574 2003-07-31 2004-07-30 Transparent access authentication in gprs core networks WO2005015875A1 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP04763655A EP1649661B1 (en) 2003-07-31 2004-07-30 Transparent access authentification in GPRS core networks
US10/566,584 US7770216B2 (en) 2003-07-31 2004-07-30 Transparent access authentication in GPRS core networks
CA2532083A CA2532083C (en) 2003-07-31 2004-07-30 Transparent access authentication in 2g and 2.5g mobile access networks
PL04763655T PL1649661T3 (en) 2003-07-31 2004-07-30 Transparent access authentification in GPRS core networks
DE602004008293T DE602004008293T2 (en) 2003-07-31 2004-07-30 Transparent access authentication in GPRS core networks

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP03017348.8 2003-07-31
EP03017348 2003-07-31

Publications (1)

Publication Number Publication Date
WO2005015875A1 true WO2005015875A1 (en) 2005-02-17

Family

ID=34130043

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/008574 WO2005015875A1 (en) 2003-07-31 2004-07-30 Transparent access authentication in gprs core networks

Country Status (10)

Country Link
US (1) US7770216B2 (en)
EP (1) EP1649661B1 (en)
CN (1) CN100589480C (en)
AT (1) ATE370602T1 (en)
CA (1) CA2532083C (en)
DE (1) DE602004008293T2 (en)
ES (1) ES2293316T3 (en)
PL (1) PL1649661T3 (en)
PT (1) PT1649661E (en)
WO (1) WO2005015875A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1959629A1 (en) * 2007-02-13 2008-08-20 Vodafone Holding GmbH Method for authenticating a user for access to server based applications from mobile device, gateway and identity management unit
WO2023094373A1 (en) * 2021-11-26 2023-06-01 Abb Schweiz Ag Method for device commissioning in a network system and network system

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2458295T3 (en) * 2004-11-10 2014-04-30 Telefonaktiebolaget Lm Ericsson (Publ) Provision, nodes and method in relation to access to services on a communication system
US20060174004A1 (en) * 2005-01-31 2006-08-03 Nokia Corporation System and method for optimizing access network authentication for high rate packet data session
US7685633B2 (en) * 2005-02-25 2010-03-23 Microsoft Corporation Providing consistent application aware firewall traversal
US20070055874A1 (en) * 2005-09-05 2007-03-08 Nokia Corporation Bundled subscriber authentication in next generation communication networks
EP1982543B1 (en) * 2006-02-10 2017-06-07 Telefonaktiebolaget LM Ericsson (publ) Performance monitoring of location-based service in a mobile telecommunications network
CN101018128A (en) * 2006-02-10 2007-08-15 朗迅科技公司 Removable user identity module authenticating to the Internet protocol multi-media sub-system (IMS)
US8036230B2 (en) * 2007-11-05 2011-10-11 Cisco Technology, Inc. System and method for providing single IP tunnel
CN101453399B (en) * 2007-11-30 2012-07-04 华为技术有限公司 Virtual network configuration method and apparatus
GB2509278B (en) * 2011-09-22 2020-02-26 Stuart Goodwin Russell Network user identification and authentication
CN103166953B (en) * 2012-12-03 2016-08-03 上海斐讯数据通信技术有限公司 A kind of network safety system and method
CN108024248B (en) * 2016-10-31 2022-11-08 中兴通讯股份有限公司 Authentication method and device for Internet of things platform
US11438168B2 (en) * 2018-04-05 2022-09-06 T-Mobile Usa, Inc. Authentication token request with referred application instance public key

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002032165A1 (en) * 2000-10-09 2002-04-18 Nokia Corporation Method and system for establishing a connection between network elements
WO2004019641A1 (en) * 2002-08-16 2004-03-04 Siemens Aktiengesellschaft Method for authenticating a user of a communication terminal during registration in a service network and during use of the same

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09271066A (en) * 1996-03-29 1997-10-14 Sony Corp Communication method, communication system, communication terminal equipment and communication management equipment
US6977917B2 (en) * 2000-03-10 2005-12-20 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for mapping an IP address to an MSISDN number within a service network
US6678517B2 (en) * 2001-06-21 2004-01-13 Spatial Wireless, Inc. Method and system for providing continuous voice and packet data services to a mobile station
US7574735B2 (en) * 2002-02-13 2009-08-11 Nokia Corporation Method and network element for providing secure access to a packet data network
DE10223248A1 (en) * 2002-05-22 2003-12-04 Siemens Ag Method for registering a communication terminal
US7155526B2 (en) * 2002-06-19 2006-12-26 Azaire Networks, Inc. Method and system for transparently and securely interconnecting a WLAN radio access network into a GPRS/GSM core network
US6788676B2 (en) * 2002-10-30 2004-09-07 Nokia Corporation User equipment device enabled for SIP signalling to provide multimedia services with QoS
US7417979B2 (en) * 2003-01-11 2008-08-26 At&T Mobility Ii Llc Systems and methods for providing a home network conversion interface
US20040148416A1 (en) * 2003-01-29 2004-07-29 Jryki Aarnos Method and apparatus for messaging between a client of an sip-based network and a client of a wireless village network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002032165A1 (en) * 2000-10-09 2002-04-18 Nokia Corporation Method and system for establishing a connection between network elements
WO2004019641A1 (en) * 2002-08-16 2004-03-04 Siemens Aktiengesellschaft Method for authenticating a user of a communication terminal during registration in a service network and during use of the same

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Access security for IP-based services (Release 5)", 3GPP TS 33.203 V5.6.0, XX, XX, June 2003 (2003-06-01), pages 1 - 27,34, XP002264085 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1959629A1 (en) * 2007-02-13 2008-08-20 Vodafone Holding GmbH Method for authenticating a user for access to server based applications from mobile device, gateway and identity management unit
WO2023094373A1 (en) * 2021-11-26 2023-06-01 Abb Schweiz Ag Method for device commissioning in a network system and network system

Also Published As

Publication number Publication date
US7770216B2 (en) 2010-08-03
CA2532083A1 (en) 2005-02-17
CN1830191A (en) 2006-09-06
DE602004008293D1 (en) 2007-09-27
EP1649661B1 (en) 2007-08-15
EP1649661A1 (en) 2006-04-26
CN100589480C (en) 2010-02-10
DE602004008293T2 (en) 2008-05-08
ES2293316T3 (en) 2008-03-16
PL1649661T3 (en) 2008-01-31
CA2532083C (en) 2012-02-07
US20060195898A1 (en) 2006-08-31
ATE370602T1 (en) 2007-09-15
PT1649661E (en) 2007-11-22

Similar Documents

Publication Publication Date Title
JP5016359B2 (en) Method for providing access to an IP multimedia subsystem
EP1488609B1 (en) Communication system and method
US7272397B2 (en) Service access control interface for an unlicensed wireless communication system
US8422990B2 (en) Switching system and corresponding method for unicast or multicast end-to-end data and/or multimedia stream transmissions between network nodes
US7761913B2 (en) Method for selecting an access point name (APN) for a mobile terminal in a packet switched telecommunications network
CN101606372B (en) Support of UICC-less calls
US20030214958A1 (en) Linking of bearer and control for a multimedia session
US7526642B2 (en) Controlling delivery of certificates in a mobile communication system
EP1829300A1 (en) Method for the routing of communications to a voice over internet protocol terminal in a mobile communication system
EP1649661B1 (en) Transparent access authentification in GPRS core networks
EP2938043A1 (en) Method of access provision
EP1798910A1 (en) Method of requesting and sending authentification vectors
US7962122B2 (en) Secure traffic redirection in a mobile communication system
US8407764B2 (en) User authentication apparatus and method for supporting PMIPv6 in next generation networks
CN101341779A (en) Prioritized network access for wireless access networks
EP1847136A2 (en) Service access control interface for an unlicensed wireless communication system
EP2081333A1 (en) Assignment of IP adresses to extension devices in 3GPP mobile networks
NZ553728A (en) Method of providing access to an IP multimedia subsystem

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480021472.X

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2004763655

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2532083

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2006195898

Country of ref document: US

Ref document number: 10566584

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2004763655

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10566584

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2004763655

Country of ref document: EP