GB2450494A

GB2450494A - Obtaining access to a portal through data embedded in DNS query messages

Info

Publication number: GB2450494A
Application number: GB0712317A
Authority: GB
Inventors: Alan Dekok
Original assignee: QUICONNECT Sas
Current assignee: QUICONNECT Sas
Priority date: 2007-06-25
Filing date: 2007-06-25
Publication date: 2008-12-31
Anticipated expiration: 2027-06-25
Also published as: GB0712317D0; GB2450494B

Abstract

An access data retrieval system and method are disclosed for obtaining access to resources via an access portal (10). The system comprises a client system (100) and a remote server (120), the client system being arranged to transmit a request (150) via the portal to the server, the request being embedded within a Domain Name System (DNS) query directed to the server, the server being responsive to receipt of the request to determine data (e.g. subscription data etc.) on the portal and transmit access data embedded within a DNS response (160) to the client, the client being operative to access the portal using the recovered access data. Multiple requests and responses may be sent if the access data is too large to fit in a single message. The access data may be encrypted for greater security. Enables access of portals from competing providers who do not support each others accounts.

Description

ACCESS DATA RETRIEVAL SYSTEM

Field of the Invention

The present invention relates to a retrieval system for obtaining access data for use in data communication networks.

Background to the Invention

A term that is becoming more and more popular by network providers and those in the IT industry is "ubiquitous". The public is being sold the idea that if they have a mobile device then they can access the web or Internet from wherever they happen to be. However, whilst this may be the dream of many IT sales forces as a driver for their particular mobile device or mobile application, we are currently far from this position.

Whilst it is true to say that many public and private areas are covered by some form of network that could feasibly be used by a visitor to that place to access the Internet or world wide web, the underlying issue is that in most cases it is not as simple as plugging in a cable or just opening up a web browser to access the Internet or web from those locations.

As illustrated in Figure 1, in all but the most unrestricted of networks, some form of access portal 10 exists between the network 20 and the Internet 30.

The access portal 10, is normally put in place to restrict access to the Internet and typically requires some form of account (often based on a subscription based service) that must be authenticated before the access portal 10 will allow access to the general Internet 30.

This is a typical configuration in many public places, hotels and the like. The access portal 10 is typically linked to a global system 50 that holds user account information on subscriptions, payments and the like. If a user attempts to access any portal supported by the system 50, they can use the same account and payment information. It will be appreciated that this is particularly convenient to travellers that may stay at the same brand of hotel, visit lounges of the same airline or the like. However, there are an increasing number of competing systems that do not co-operate or support each others accounts, It is therefore possible for a traveller to have to maintain a number of different accounts in order to access different portals. The alternative is that the user accesses the portal on a pay-per-use basis which is typically more expensive and more inconvenient.

Businesses with lots of travelling employees have identified that this is a particular problem and are working to make blanket agreements with the providers of the systems 50 such that one of their employees can access any portal 10.

Unfortunately, given the requirement for different user accounts for each portal type, this still means multiple user names and passwords. An alternative is that the user is provided with an alternative mechanism for accessing the portal which then provides a customised log on page through which the user can log on using a single account authentication mechanism. Unfortunately, even the alternate access mechanisms may differ between portal types. One suggested solution to this is for data on the alternate access mechanism to be pre-generated and provided to the user prior to visiting the location at which they need to access the portal. The pre-generated data would then include the necessary information to access the portal. This still requires a-prior knowledge of the location to be visited and is therefore still relatively undesirable and presents complications to users that may not wish to add this step of preparation to the long list of things they already have to think about when preparing for travel.

Statement of the Invention

According to an aspect of the present invention there is provided an access data retrieval system for obtaining access to resources via an access portal, the system comprising a client system and a remote server, the client system being arranged to transmit a request via the access portal to the remote server, the request being embedded within a DNS query directed to the remote server, the server being responsive to receipt of the request to determine data on the respective access portal and transmit access data embedded within a DNS response to the client, the client being operative to access the access portal in dependence on the access data.

The present invention seeks to use DNS as a transport protocol. Whilst access portals typically block web browsing and Internet requests by intercepting URL look-ups and redirecting them to a. local/dummy site, they inherently allow underlying DNS query traffic to go out onto the Internet and the presently claimed invention leverages this by transmission of DNS queries to a specially configured DNS server. The server determines the data/script that needs to be returned to the device and is embedded within a DNS packet or packets in answer to the query. The DNS packet(s) are returned to the end device which is then able to recover the data or script and use it to authenticate itself with the access portal and gain full access to the Internet and world wide web.

Brief Descrirtion of the Drawings Embodiments of the present invention will now be described in detail with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of a conventional network having access limited to the Internet via access portal; Figure 2 is a schematic diagram of a network incorporating an access data retrieval system in accordance with an embodiment of the present invention.

Figure 3 is the schematic diagram Of Figure 2 illustrating operation; and Figure 4 is a schematic diagram of a DNS packet including embedded access data in accordance with an embodiment of the present invention.

Detailed Description

Figure 2 is a schematic diagram of a network incorporating access data retrieval system in accordance with an embodiment of the present invention. Figure 3 illustrates aspects of the system in use.

A mobile device 100 includes a client system 110. The mobile device connects to an access portal 10 via an internal network 20. The access portal 10 is also connected to the Internet 30. A remote DNS server 120 is also connected to the Internet and includes an access data database 125.

The access portal 10 may optionally include a local DNS server 11 connected to a DNS database 12. A user connects the mobile device 100 to the network 20 and accesses the client system 110. The client system 110 includes pre-stored data on the address of the DNS server 120 and transmits a DNS request 150 addressed to the DNS server 120. The DNS request 150 passes from the mobile device 100 via the network 20 to the access portal 10. As it is seen to be just a ONS request, the access portal 10 allows the DNS request 150 to pass to the Internet 30 and it is then routed to the DNS server 120.

Upon receipt of the request, the DNS server 120 identifies the origin of the request (which will be the access portal 10) and is able to identify the type of the access portal from predetermined data and/or past requests. Additionally or alternatively, the request itself may include data to enable the DNS server 120 to identify the access portal 10. In this manner, the client system 110 may perform pre-processing on the access portal 10 and/or network 20 to identify it or its attributes.

The DNS server 120 then obtains predetermined access data from the database associated with the type of access portal and embeds this in a DNS response message 160. This DNS response message 160 is then returned via the Internet to the access portal 10 and onward to the mobile device 100. The mobile device 100 extracts the access data payload from the response message 160 and is then able to use this data to provide the necessary account information and the like to authenticate with the access portal.

The access data payload may be split between a number of DNS response messages 160. If multiple DNS response messsges are needed (for example if the data is too large to fit in a single payload), the ONS server 120 may inform the client system 100 of this information in the first DNS response message 160. In this manner, the client system 110 can be triggered to send as many DNS request messages 150 as needed, one matching each response message 160. As such, nothing untoward will be noticed by the access portal 10 (which would otherwise see one outgoing DNS request and multiple incoming DNS responses which is inconsistent with normal DNS systems). Similarly, the request may be formed from a number of DNS requests 150 if multiple messages are needed to provide data on the access portal 10 etc. It will be appreciated that this scheme could be extended to enable interrogation of the access portal 10. The client system 110 could send data on the access portal to the DNS server 120. In response, the DNS server 120 instructs the client system 110 to obtain certain data from the access portal 10 which it can then return to the' DNS server 120 for a more comprehensive identification of the access portal 10.

If a local DNS 11 is operated then any DNS requests may be cached in database 12. In such a scenario, the access portal 10 will check for cached responses before transmission of DNS requests over the Internet and this would mean that the access data would also be cached.

The access data may be in the form of a script that the client system 110 executes or it may simply be data that is interpreted by the client system. The data may include instructions to access the access portal. Alternatively, it may simply reference one of a predetermined set of instructions or routines that is stored within the client system 110. If the access data is a script, it may also contain the necessary information that the client system can use to step through what would otherwise be a visual prompting interface from the access portal such as a series of web pages that is normally used to guide the user through the steps of accessing the access portal (such as accepting terms and conditions, stepping through information pages and the like).

The access data/script may be encrypted or otherwise encoded to ensure integrity and privacy. The access data may also provide the client system 110 with sufficient information to enable roaming via different networks. In this scenario, a user from a foreign network may well be able to access the access portal using his home user name and password if it is presented in a particular manner. The script/access data would instruct the client system on the particular username and password to be used and also th.e format in which it is to be provided.

It will be appreciated that the remote server 120 may incorporate the DNS server or may be a separate entity that connects to a particular DNS server and intercepts DNS requests. It will also be appreciated that although the client device is being referred to above as a mobile device, it could be any form of client device from a PC to laptop to mobile phone, PDA or the like.

Figure 4 is a schematic diagram of a DNS packet 200 including embedded access data in accordance with an embodiment of the present invention.

The DNS packet 200 includes: an Identification field 210 used to correlate queries and responses; a message type field 220 for identifying the message as a query or response; an opcode field 230 describing the type of message -0 Standard query (name to address); 1 Inverse query; 2 Server status request; an authoritative answer field 240 -when set to 1, this identifies the response as one made by an authoritative name server; a truncation field 250 -when set to 1, indicates the message has been truncated; a recursion field 250 -set to 1 by the resolve to request recursive service by the name server; a recursive service availability field 260 used to signals the availability of recursive service by the name server; a response code field 270 set by the name server to identify the status of the query; a question count field 280 used to define the number of entries in the question section; an answer count field 300 used to define the number of resource records in the answer section; an authority count field 290 used to define the number of name server resource records in the authority section; and, an additional count field 310 used to define the number of resource records in the additional records section.

Claims

Claims 1. An access data retrieval system for obtaining access to

resources via an access portal, the system comprising a client system and a remote server, the client system being arranged to transmit a request via the access portal to the remote server, the request being embedded within a Domain Name System, DNS, query directed to the remote server, the remote server being responsive to receipt of the request to determine data on the access portal and transmit access data embedded within a DNS response to the client, the client being operative to access the access portal in dependence on the access data.
2. An access data retrieval system according to claim 1, wherein the client system includes an identifier of a predetermined DNS server, the client system being arranged to transmit the request to the remote server using the identifier of the predetermined DNS server.
3. An access data retrieval system according to claim 2, wherein the remote server comprises the predetermined DNS server.
4. An access data retrieval system according to claim 2, wherein the remote *:::: server is arranged to connect to the DNS server and to intercept DNS requests : transmitted to the identifier of the predetermined DNS server. 0S**
5. An access data retrieval system according to any preceding claim, wherein the access data is encrypted or encoded.

*
6. An access data retrieval system according to any preceding claim, wherein the access data comprises instructions to the client system to authenticate with the access portal transparently to the user.
7. An access data retrieval system according to claim 6, wherein the instructions include a script to be executed by the client system.
8. An access data retrieval system according to claim 6 or 7, wherein the instructions include authentication data to be used to authenticate the client system with the access portal.
9. An access data retrieval system according to any preceding claim, wherein the remote server is operative to identify the type of access portal in dependence on routing data associated with the request.
10. An access data retrieval system according to any preceding claim, wherein the remote server is operative to trigger the client system, via the DNS response, to interrogate the access portal and transmit data on the interrogation via one or more subsequent DNS request messages to the remote server.
11. An access data retrieval system according to any preceding claim, wherein the access data is split between a plurality of DNS response messages, the remote server being arranged to transmit a first DNS response message to the client system indicating the number of DNS response messages that comprise the access data, wherein the first DNS response message is operative to trigger the *:*::* client system to transmit a plurality number of DNS request messages to match ** the number of DNS response messages that comprise the access data. * SI
12. A method for obtaining access to resources via an access portal, the method comprising: * ** transmitting, from a client system to a remote server, a data request, wherein the transmission is made via the access portal and the request is embedded within a * Domain Name System, DNS, query directed to the remote server; receiving the request at the remote server and determining data on the access portal; transmitting access data embedded within a DNS response to the client; and, accessing the access portal at the client system in dependence on the access data.
13. A method according to claim 12, wherein the client system includes an identifier of a predetermined DNS server, the method further comprises transmitting the request to the remote server using the identifier of the predetermined DNS server.
14. A method according to claim 13, further comprising integrating the remote server into the predetermined DNS server.
15. A method according to claim 13, further comprising connecting the remote server to the DNS server and intercepting DNS requests transmitted to the identifier of the predetermined DNS server.
16. A method according to any of claims 12 to 15, further comprising encrypting or encoding the access data in the DNS response.
17. A method according to any of claims 12 to 16, wherein the access data comprises instructions to the client system to authenticate with the access portal *:::* transparently to the user.

**
18. A method according to claim 17, wherein the instructions include a script to : be executed by the client system. 0*SS
19. A method according to claim 17 or 18, wherein the instructions include authentication data to be used to authenticate the client system with the access portal.
20. A method according to any of claims 12 to 19, further comprising identifying at the remote server the type of access portal in dependence on routing data associated with the request.
21. A method according to any of claims 12 to 20, further comprising triggering the client system, via the DNS response, to interrogate the access portal and transmit data on the interrogation via one or more subsequent DNS request messages to the remote server.
22. A method according to any of claims 12 to 21, further comprising: splitting the access data between a plurality of DNS response messages; wherein the remote server transmits a first DNS response message to the client system indicating the number of DNS response messages that comprise the access data and triggers the client system to transmit a plurality number of DNS request messages to match the number of DNS response messages that comprise the access data.
23. A computer program comprising computer program code means for performing all of the steps of any of claims 12 to 22 when said program is run on a computer.
24. A computer program as claimed in claim 23 embodied on a computer readable medium. * ** * S * * SS **
25. An access data retrieval system as herein described and as illustrated in : the accompanying drawings numbered 2 to 4. I...
26. A method as herein described and as illustrated in the accompanying drawings numbered 2 to 4.