GB2420055A - Secure network service access - Google Patents

Secure network service access Download PDF

Info

Publication number
GB2420055A
GB2420055A GB0424714A GB0424714A GB2420055A GB 2420055 A GB2420055 A GB 2420055A GB 0424714 A GB0424714 A GB 0424714A GB 0424714 A GB0424714 A GB 0424714A GB 2420055 A GB2420055 A GB 2420055A
Authority
GB
United Kingdom
Prior art keywords
node
service access
identity
access node
authorisation
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.)
Withdrawn
Application number
GB0424714A
Other versions
GB0424714D0 (en
Inventor
Vesa Torvinen
Bengt Sahlin
Jani Hautakorpi
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
Priority to GB0424714A priority Critical patent/GB2420055A/en
Publication of GB0424714D0 publication Critical patent/GB0424714D0/en
Priority to GB0522337A priority patent/GB2420057B/en
Priority to US11/264,387 priority patent/US7424284B2/en
Publication of GB2420055A publication Critical patent/GB2420055A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/20—Selecting an access point
    • 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/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • 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/166—Implementing security features at a particular protocol layer at the transport layer
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/10—Upper layer protocols adapted for application session management, e.g. SIP [Session Initiation Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A method of authorising a user of a mobile communication unit to access a service via a visited communication network comprises: ```establishing a secure transport channel between the mobile node and a service access node of the visited network, the channel being identified by the service access node; ```sending an authorisation request from the mobile node to the service access node, incorporating the identity of the service access node into the request, and forwarding the request to an authorisation node of the user's home network. At the authorisation node of the home network, the service access node is authorized, and a user challenge including the identity of the service access node; ```forwarded via the service access node to the mobile unit, where it is ```verifyied whether or not the identity of the secure transport channel matches the identity contained in the received challenge.

Description

1 2420055 Secure Network/Service Access Various 3GPP sub-system
architectures are typically based on roaming models, i.e. where the user is accessing services via a visited network. The roaming model was first adopted at lower layer networks but was later been deployed also to upper layers and applications such as IP Multimedia Sub-system (IMS).
Roaming models can difficult to implement, especially at the application layer. For example, if the access security solution is based on a model in which the entity in the visited network is authenticated to a mobile node by a Transport Layer Security (TLS) certificate (TLS is an ETSI standard), but the mobile node is authenticated using credentials shared with the home network (e.g. Hypertext Transport Protocol (HTTP) Digest AKA), the mobile node cannot easily verify if the entity in the visited network should be trusted or not. Secure access would require such verification in order to prevent the threat of Man-in-the-middle attacks where an attacker seeks to place a node between the mobile node and the visited network entity. Because the mobile node authentication is not tied to the underlying security, the attacker can tunnel HTTP Digest messages between different tunnels and even different protocols.
One option for solving this problem is to apply global naming restrictions to all entities in the visited networks. In this way, the mobile node could verify that a given entity belongs to a common "trust domain". However, this might cause configuration problems, and may not be acceptable from a business point of view. Furthermore, the solution is not very flexible, and can not be changed once agreed.
An aspect of the present invention is set out in the accompanying claims.
The present invention proposes a solution which involves the home network explicitly verifying the used roaming model to the client in secure way. This verification can be done in HTTP Digest authentication framework if the roaming model is reflected in some authenticated parameter or protected in some other way.
This invention may be standardized in 3GPP/IMS as a solution for TLS based access security. The same solution could be used in TISPAN NGN access security.
A particular embodiment of the invention utilises HTTP digest between the mobile node and the home network. Security between the mobile node (UE) and an HTTP proxy in the visited network is based on TLS. The use of other protocols may also be possible.
For example, UE and HTTP server may use HTTP Digest AKA.
With reference to the schematic architecture illustrated in Figure 1, the procedure has the following steps: 0) UE authenticates the HTTP proxy using the TLS server certificate base procedure.
HTTP proxy does not authenticate the UE with TLS.
1) UE sends a HTTP request (typically HTTP GET) to HTTP proxy.
Note: Other protocols which use HTTP authentication framework could alternatively be used.
2) The HTTP proxy recognizes that the request is intended for the HTTP server. The HTTP proxy adds its own TLS domain name to the request, and forwards it to HTTP server. Which header is used is out of the scope of this innovation.
3) The HTTP server checks if the HTTP proxy is authorized to use HTTP Digest based roaming. If yes, then the HTTP server returns an HTTP Digest challenge to the HTTP proxy. The challenge includes an explicit statement about the roaming agreement between HTTP proxy and HTTP server. The roaming statement is protected end-to-end between the HTTP server and UE. End-to-end protection can be achieved, for example, by constructing a new protection domain/realm for this roaming agreement, and adding that domain/realm name to HTTP Digest authentication challenge. If the HTTP proxy TLS domain name is "vn.proxy.com", and the HTTP server domain name is hn.server.com", the new roaming domain name could be "hn.server.comvn. proxy.com". The HTTP proxy domain name is taken from message 2). The HTTP server may verify the correctness of the HTTP proxy domain name, e.g. from HTTP proxy TLS client certificate - if TLS is used also between HTTP proxy and HTTP server.
4) The HTTP proxy forwards the 401 response message towards the UE.
5) From the HTTP Digest challenge, the UE can see that the HTTP proxy and HTTP server have a roaming agreement. The UE compares the HTTP proxy domain name in the HTTP Digest challenge and that of the TLS server certificate, and if they match, it continues the process according to standard HTTP Digest procedures The UE should require mutual authentication from the HTTP server in order to be certain that the roaming agreement really exists.
6) HTTP proxy tunnels the HTTP Digest response to HTTP server.
7) HTTP server authenticates the UE. HTTP server must check that the roaming statement is protected end-to-end, e.g. that the protection domain/realm has not been modified, and that the authentication response has been calculated using the correct protection domain/realm name. If everything is OK, the HTTP server delivers the service. If authentication fails, the HTTP server rejects the request.
8) HTTP proxy forwards the response from HTTP server to UE.
9) If the authentication was successful in HTTP server, the UE will receive the service.
The UE may use this as a hint that the roaming agreement might exist. If mutual authentication between UE and HTTP server was used, the UE can be sure that the roaming agreement was really verified by the HTTP server.
With reference now to Figure 2, this illustrates a second example demonstrating how the innovation could be used in 3GPP IP Multimedia Subsystem (IMS). The example assumes that HTTP Digest AKA is used between UE and S-CSCF in the home network. Security between UE and P-CSCF in the visited network is based on TLS.
The use of other HTTP based authentication protocols may also be possible. For example, UE and S-CSCF may use HTTP Digest or some updated version of HTTP Digest AKA.
The procedure has the following steps: 10) UE authenticates the P-CSCF using the TLS server certificate. The P- CSCF does not authenticate the UE with TLS.
11) UE sends a SIP REGISTER request to P-CSCF.
12) P-CSCF recognize that the request is for S-CSCF. HTTP proxy P-CSCF adds its own TLS domain name to the request, and forwards it to S-CSCF. Which header is used is out of the scope of this innovation.
13) S-CSCF checks if the P-CSCF is authorized to use HTTP Digest based roaming. If yes, then the S-CSCF returns HTTP Digest challenge to P-CSCF. The challenge includes an explicit statement about the roaming agreement between the P-CSCF and the S-CSCF. The roaming statement is protected endto-end between S-CSCF and UE. End-to-end protection can be achieved, for example, by constructing a new protection domain/realm for this roaming agreement, and adding that domain/realm name to HTTP Digest AKA authentication challenge. If the P-CSCF TLS domain name is "vn.pcscf. coni", and the home domain name is "HTTP server.sip.com", the new roaming domain name could be "HTTP server.sip.com@vn.pcscf corn" The P-CSCF domain name is taken from message 12). S-CSCF may verify the correctness of the P-CSCF domain name, e.g. from HTTP proxyP-CSCF TLS client certificate if TLS is used also between P-CSCF and S-CSCF.
14) P-CSCF forwards the 401 response message towards the UE.
15) From HTTP Digest AKA challenge, the UE can see that the P-CSCF and the 8- CSCF have a roaming agreement. The UE compares the P-CSCF domain name in the HTTP Digest AKA challenge, and the TLS server certificate, and if they match, it continues the process as standard HTTP Digest AKA procedure. UE should require HTTP Digest based mutual authentication from the HTTP server in order to be really sure that the roaming agreement really exists.
16) P-CSCF tunnels the HTTP Digest response to S-CSCF.
17) S-CSCF authenticates the UE. S-CSCF must check that the roaming statement is protected end-to-end, e.g. that the protection domain/realm has not been modified, and that the authentication response has been calculated using the correct protection domain/realm name. If everything is OK, the S-CSCF updates the registration state. If authentication fails, the S-CSCF rejects the request.
18) P-CSCF forwards the response from S-CSCF to UE.
If the authentication was successful in S-CSCF, the UE will receive the service. The UE may use this as a hint that the roaming agreement might exist. If mutual authentication between UE and S-CSCF was used, the UE can be sure that the roaming agreement was really verified by the S-CSCF.
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 (7)

  1. Claims 1. A method of authorising a user of a mobile node to access a
    service via a visited communication network, the method comprising: establishing a secure transport channel between the mobile node and a service access node of the visited network, said channel being bound to an identity of the service access node; sending an authorisation request from the mobile node to the service access node, incorporating an identity of the service access node into the request at the service access node, and forwarding the request to an authorisation node of the user's home network; at said authorisation node of the home network, authorising the service access node, and sending to the service access node a user challenge including the identity of the service access node, said identity being included in such a way that a change to the identity can be detected by a recipient; at the serving access node, forwarding the received user challenge to the mobile node; and at the mobile node verifying whether or not the identity bound to the secure transport channel matches the identity contained in the received challenge.
  2. 2. A method according to claim 1 and, assuming that the mobile node verifies that the identity bound to the secure transport channel matches the identity contained in the received challenge, carrying out a subsequent step of sending a challenge response to the authorisation node via the service access node, and at the authorisation node verifying that the identity contained in the response has not been changed.
  3. 3. A method according to claim 1 or 2, wherein said mobile node comprises a SIP UA, and said service access node is a SIP P-CSCF and said authorisation node is a S- CSCF.
  4. 4. A method according to claim 1, wherein said authorisation request is a SIP REGISTER message, and said challenge is a SIP 401 message.
  5. 5. A method according to claim I or 2, wherein said service access node is an HTTP proxy, and said authorisation node is an HTTP server, and said authorisatjon request is an HTTP request.
  6. 6. A method according to any one of the preceding claims, wherein said secure transport channel is established according to TLS, said identity being included in a TLS certificate.
  7. 7. A method according to any one of the preceding claims, the authorisation node generating a new roaming domain/realm name for the roaming agreement by combining a visited network domain name with a home network domain name, the new domain/realm name being included in said user challenge.
GB0424714A 2004-11-09 2004-11-09 Secure network service access Withdrawn GB2420055A (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
GB0424714A GB2420055A (en) 2004-11-09 2004-11-09 Secure network service access
GB0522337A GB2420057B (en) 2004-11-09 2005-11-02 Secure Network/Service Access
US11/264,387 US7424284B2 (en) 2004-11-09 2005-11-02 Secure network/service access

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0424714A GB2420055A (en) 2004-11-09 2004-11-09 Secure network service access

Publications (2)

Publication Number Publication Date
GB0424714D0 GB0424714D0 (en) 2004-12-08
GB2420055A true GB2420055A (en) 2006-05-10

Family

ID=33523407

Family Applications (2)

Application Number Title Priority Date Filing Date
GB0424714A Withdrawn GB2420055A (en) 2004-11-09 2004-11-09 Secure network service access
GB0522337A Active GB2420057B (en) 2004-11-09 2005-11-02 Secure Network/Service Access

Family Applications After (1)

Application Number Title Priority Date Filing Date
GB0522337A Active GB2420057B (en) 2004-11-09 2005-11-02 Secure Network/Service Access

Country Status (1)

Country Link
GB (2) GB2420055A (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1379053A1 (en) * 2002-06-20 2004-01-07 TeliaSonera Finland Oyj Method for transferring a user-ID password pair, and a wireless network

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7529933B2 (en) * 2002-05-30 2009-05-05 Microsoft Corporation TLS tunneling

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1379053A1 (en) * 2002-06-20 2004-01-07 TeliaSonera Finland Oyj Method for transferring a user-ID password pair, and a wireless network

Also Published As

Publication number Publication date
GB2420057A (en) 2006-05-10
GB0522337D0 (en) 2005-12-07
GB2420057B (en) 2009-04-01
GB0424714D0 (en) 2004-12-08

Similar Documents

Publication Publication Date Title
US7424284B2 (en) Secure network/service access
KR101158956B1 (en) Method for distributing certificates in a communication system
ES2389250T3 (en) A method to authenticate a user terminal in an IP multimedia subsystem
US8045540B2 (en) Handling of identities in a trust domain of an IP network
CN101569217B (en) Method and arrangement for integration of different authentication infrastructures
US11290466B2 (en) Systems and methods for network access granting
US9654966B2 (en) Methods and nodes for mapping subscription to service user identity
US20050246548A1 (en) Method for verifying a first identity and a second identity of an entity
US20040225878A1 (en) System, apparatus, and method for providing generic internet protocol authentication
US8875236B2 (en) Security in communication networks
Pritikin et al. Bootstrapping remote secure key infrastructures (BRSKI)
US20070143614A1 (en) Method, system and devices for protection of a communication or session
EP2873213A1 (en) Methods and systems for authenticating a user of a wireless unit
US8365244B2 (en) Systems, methods and computer program products supporting provision of web services using IMS
Rasol et al. An improved secure SIP registration mechanism to avoid VoIP threats
US20040043756A1 (en) Method and system for authentication in IP multimedia core network system (IMS)
CN102065069B (en) Method and system for authenticating identity and device
US20230007481A1 (en) Enhancement of authentication
GB2420055A (en) Secure network service access
WO2011017851A1 (en) Method for accessing message storage server securely by client and related devices
Bava Miglioramento della sicurezza nelle applicazioni conformi al 3GPP: un banco di prova modulare e scenari di minaccia per i sistemi di comunicazione Mission Critical
Sher et al. IMS—A Secure Architecture for All IP Networks
Pritikin et al. RFC 8995: Bootstrapping Remote Secure Key Infrastructure (BRSKI)
Heikkinen Security and accounting enhancements for roaming in IMS
Hartman et al. Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)