WO2013041882A2

WO2013041882A2 - User authentication in a network access system

Info

Publication number: WO2013041882A2
Application number: PCT/GB2012/052348
Authority: WO
Inventors: Werner Otto; Kevin EPSWORTH; Andrew LOUKE; Andreas Bartels; Steve Nicholson
Original assignee: The Cloud Networks Limited
Priority date: 2011-09-21
Filing date: 2012-09-21
Publication date: 2013-03-28
Also published as: GB2494891A; WO2013041882A3; GB201116323D0; GB2494891B; WO2013041882A8

Abstract

A system and method for controlling access to a network service or resource by a wireless client device is described. One embodiment of a system comprises a network access point, a client device coupled to the network access point, a network access controller operable to perform MAC authentication of the client device, and a DHCP server coupled to the network access controller via a communication channel, the DHCP server operable to allocate a lease for a network address to the client device after receiving a notification from the network access controller to indicate that MAC authentication of the client device has been completed. Other systems and methods are also described for controlling access and for registering a computing device for automatic MAC authentication by a network access controller in a network access system.

Description

User Authentication in a Network Access System Field of the Invention

[0001] This invention relates to a computer network access system, and more particularly to user authentication in the system.

Background of the Invention

[0002] MAC Authentication (MAC Auth) is a feature that allows a user of a computing device to be automatically and transparently logged in and allowed access through a core network based solely on the Media Access Control (MAC) address of the device. As those skilled in the art will appreciate, the MAC address is a unique identifier assigned to a network interface of a computing device. The core network maintains an association between a MAC address and the credentials of the user owning the device. When the client device connects to the core network, the MAC address of the device is checked to see whether it is eligible for MAC Auth and, if so, the associated user credentials are used to perform a login 'behind the scenes' . The result is that the user can immediately start using network services and does not have to first navigate a Universal Access Method (UAM) page to explicitly enter his user ID and password, for example as set out in the draft protocol WISPr (Wireless Internet Service Provider roaming) for authenticating users via IEEE 802. IX or the UAM.

[0003] Prior implementations can suffer from a race condition in which, under some circumstances, MAC Auth will not have completed before the user attempts to make use of network services. This manifests itself by the user of a browser being presented with a UAM page and being forced to manually authenticate, exactly as if his device were not registered for MAC Auth. This problem can be mitigated to some extent by over-provisioning and tuning the core network to increase the probability that the race condition always has the desired outcome. However, this is not guaranteed and a spike in network load or a partial outage that reduces capacity could cause MAC Auth to consistently fail.

[0004] For example, in a current implementation, the log file generated by a Dynamic Host Configuration Protocol (DHCP) Server may be scanned to detect events that indicate the arrival or departure of users. A DHCP Acknowledgement event indicates a user has arrived and was allocated a lease on an IP address; a DHCP Release event indicates the user has departed and the lease was rescinded. These events include the device's MAC address and are sent to a Network Access Controller (NAC) to perform MAC Auth, or a logout, as appropriate. At the time these events are written to the log file, the DHCP server has already initiated the associated operation. In particular, for a DHCP Acknowledgement event, the server has already given the client device an IP address permitting access to the network. If the user makes an immediate attempt to access a service, MAC Auth will not have completed, and the request will fail because the user is not logged in. If the request was from the user's browser, it will be intercepted and the user will be presented with a UAM page to perform a manual login.

[0005] Thus whether MAC Auth works when a particular user connects to the network will depend on the relative speeds of two operations:

1. The time taken to read the DHCP Acknowledgement event from the log file and send the MAC Auth request to the NAC, and for the NAC to action it.

2. The time taken for the DHCP Acknowledgement message to reach the client device and for the user to attempt to access a network service.

[0006] If the second operation completes before the first operation, the user will believe that MAC Auth has failed. Although the network and computing activity involved in the first operation is probably greater than the second operation, the latter involves human interaction so will typically take longest, in which case no problem will be perceived. However, if the NAC is particularly tardy, or if the user is poised to access some service, the second operation may complete before the first operation.

[0007] The inventors have realized that if the core network components are well tuned, the above race condition invariable completes in favour of MAC Auth. However, a transient load on the network, or a temporary failure that reduces responsiveness, could cause MAC Auth to frequently fail. Similarly, if there emerged a browser-based application that instantly made a network request as soon as the client device received an IP address, thus eliminating the human delay from the second operation above, MAC Auth could be expected to consistently fail, regardless of how well tuned the core network components may be. This is typically experienced by WISPr clients, where application software such as a browser is launched as soon as the device is assigned an IP address or is given Internet access.

[0008] A further and related problem with known implementations is that for non-MAC Auth clients, the NAC has no means of learning their MAC address. Consequently, accounting of the non-MAC Auth clients is not possible as Customer Data Records (CDRs) generated for such clients have an unspecified MAC address.

[0009] What is desired is a new design for implementing the MAC Authentication feature in a core network to address the above problems, and to provide for additional novel functionality and efficiencies in the network access system.

Statements of the Invention

[0010] Aspects of the present invention are set out in the accompanying claims.

[0011] According to one aspect of the present invention, a system is provided for eliminating the race condition by providing an interlock to ensure that MAC Auth completes before the user is able to make use of network services.

[0012] The system may include an upper bound on the time permitted for MAC Auth to complete, after which it may revert to a manual login as a form of safety net. The timer duration may be set by the operator to reflect network capacity and conditions, so the timeout need not occur in practice.

[0013] The system comprises a network access point, a client device coupled to the network access point, a network access controller operable to perform MAC authentication of the client device, and a DHCP server coupled to the network access controller via a communication channel, the DHCP server operable to allocate a lease for a network address to the client device after receiving a notification from the network access controller to indicate that MAC authentication of the client device has been completed.

[0014] In another aspect, the present invention provides a method for authenticating a client device based on the MAC address of the device before lease of a network address for the device is granted.

[0015] In yet another aspect, there is provided a system and method of processing MAC authentication of a computing device connected to a network, the method comprising, in a captive portal system of the network receiving a join request from the computing device to join the network, the request identifying a MAC address of the computing device, transmitting a MAC authentication request to a remote captive portal system, wherein the MAC authentication request includes the MAC address of the computing device as a login attribute, and receiving an indication that the computing device is MAC authenticated and in response, providing the computing device with access to the network. [0016] In another aspect, there is provided a system and method of processing MAC authentication of a roaming computing device connected to a remote network, the method comprising, in a captive portal system of a local network, receiving a MAC authentication request from a remote captive portal system coupled to the remote network, wherein the MAC authentication request includes the MAC address of a computing device as a login attribute, determining that the MAC address included in the MAC authentication request is associated with a registered MAC authenticated device associated with the local network, and transmitting a response to the remote captive portal indicating that the computing device is MAC authenticated.

[0017] In another aspect, there is provided a system and method of registering a computing device for automatic MAC authentication by a network access controller in a network access system, the method comprising transmitting, by the computing device, a registration request to the network access controller, the registration request including the MAC address of the computing device, whereby the network access controller is operable to register the computing device for automatic MAC authentication.

[0018] In another aspect, there is provided a system and method of controlling access by a computing device to network resources, comprising determining, by a network access controller, if the computing device is registered for MAC authentication by the system and performing MAC authentication of the computing device, and receiving, by a network router, a request for a network resource from the MAC authenticated computing device and in response, transmitting a predetermined network resource to the computing device.

[0019] In another aspect, there is provided a computer program arranged to carry out the above methods when executed by suitable programmable devices. Brief Description of the Drawings

[0020] There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.

[0021] Figure 1 is a block diagram showing the main components of a network access system according to an embodiment of the invention.

[0022] Figure 2 is a flow diagram illustrating the main processing steps performed by the system of Figure 1 according to an embodiment. [0023] Figure 3 is a schematic block diagram illustrating an exemplary message data structure according to an embodiment.

[0024] Figure 4 is a flow diagram illustrating exemplary steps typically carried out by the Network Access Controller to process a client device for MAC authentication according to an embodiment.

[0025] Figure 5 is a flow diagram illustrating the steps carried out by the Network Access Controller for processing a DHCP release message to remove an existing lease and the associated session according to an embodiment.

[0026] Figure 6 is a flow diagram illustrating the process of registering a client device for MAC authentication by the NAC in the network access system 1 according to an embodiment.

[0027] Figure 7 is a block diagram illustrating a network access system for controlling network access by MAC Auth registered client devices according to another embodiment.

[0028] Figure 8, which comprises Figures 8a and 8b, is a flow diagram illustrating an exemplary process of the operation of policy routing and display of a MAC Auth splash page using the components of the network access system illustrated in Figure 7.

[0029] Figure 9 is a block diagram illustrating a network access system for enabling a client device to roam to a different core network according to another embodiment.

[0030] Figure 10 is a flow diagram illustrating an exemplary process of the operation of MAC authentication of a roaming client device connected to a partner core network, using the components of the network access system illustrated in Figure 9.

Detailed Description of Embodiments of the Invention Overview

[0031] A specific embodiment of the invention will now be described for a process of user authentication in a network access system. Referring to Figure 1, a network access system 1 according to an embodiment comprises a client device 3 connected to a node of a core communication network 5, illustrated in this embodiment as a wireless access point 7. The client device 3 may be any form of electronic device such as a computer terminal, laptop, mobile telephone or other computing device, including a wireless network interface for network communications using the IEEE 802.11 family of standards commonly referred to as Wi-Fi (RTM), for example with a remote network service or resource node 9 through the Internet. Typically, the wireless network interface of the client device 3 includes a software component that is configured to identify and communicate with the wireless access point 7, and may be provided as part of the operating system of the client device 3 and/or as a software application module provisioned on the client device 3. Those skilled in the art will appreciate that the core communication network 5 may be a public access Wi-Fi network or a private wireless network, and may include both wireless and wired data links through a plurality of communication networks, such as one or more IEEE 802 networks.

[0032] A captive portal 11 intercepts network data packets from the client device 3 connected to the core network 5, to provide for authentication, authorization and accounting of the network connections. The captive portal 11 includes a network router 13 for intercepting and tracking network connections to requested network services 9, and a network access controller (NAC) 15 in communication with the router 13 for provisioning and maintaining sessions in the core network 5. The NAC 15 also maintains a database of registered users 16, identifying client devices that are registered for MAC authentication by the NAC 15 as will be described in more detail below. The database of registered users 16 may include a provisioned MAC address cache storing MAC addresses of the registered client devices.

[0033] The NAC 15 is also in communication with an Authentication, Authorization and Accounting (AAA) module 17 for handling the authentication of the client device 3 before granting access to the core network, the authorization of the client device 3 for particular protected services and resources including external application services, and the accounting of usage by the client device 3 of those services and resources. The AAA module 17 may be a hosted AAA server farm (not shown) based on the well known RADIUS (Remote Authentication Dial In User Service) protocol, and may include a Roampoint Radius proxy (not shown) for secure communication with an external RADIUS server and for logging all RADIUS accounting records. In this embodiment, the AAA module 17 is configured to receive requests from the NAC 15 to create and maintain Radius sessions in the system 1, for example requests to start new Radius sessions, start accounting for created Radius sessions and stop existing Radius sessions. Those skilled in the art will appreciate that an alternative protocol to RADIUS may instead be implemented for the AAA module 17. A billing system 18 coupled to the AAA module 17 may be provided for performing administrative and billing functions for the services and resources, based on the information of accounting usage by the client devices logged by the AAA module 17. [0034] The captive portal 11 also includes a DHCP server 19 for automatically configuring the client device 3 with an assigned network addressing parameter in response to a DHCP request packet received from the client device 3 via the router 13, as is well known in the art. In this embodiment, the DHCP server 19 assigns the client device 3 with an IP address and a lease time for the allocated IP address. The DHCP server 19 may also assign the client device 3 with other IP configuration parameters. The DHCP server 19 may be configured to automatically allocate IP addresses from a predefined range of IP addresses assigned to the captive portal 11 or to perform allocation based on a table defining IP address and client device Media Access Control (MAC) address pairs.

[0035] As will be described in more detail below, in this embodiment, the DHCP server 19 delays the allocation of a lease until after the NAC 15 has confirmed that MAC authentication for the client device 3 has completed successfully. The DHCP server 19 sends a message to the NAC 15 when there is a DHCP acknowledgement indicating that a client device 3 wishes to attach to the network. This message includes the MAC address of the client device 3. The NAC 15 extracts and uses the MAC address from the message to determine whether the client device 3 has been registered for MAC authentication, and if so, determines the associated user authentication credentials and performs authentication automatically. The DHCP server 19 waits for a response from the NAC 15 before proceeding with IP address allocation. The NAC 15 maintains a DHCP log 21 of all IP address leases allocated or assigned by the DHCP server 19. The exchange of notification messages according to this protocol is over a direct communication channel between the DHCP server 19 and the NAC 15. In this embodiment, the notification protocol operates over UDP and the DHCP server 19 maintains a UDP socket to a port on the NAC 15. The communications channel is registered by a call to the operating system of the DHCP server 19, specifying the same socket for both read and write and appropriate action routines for servicing I/O activity in each direction. The I/O infrastructure of the DHCP server 19 manages all communications with the NAC 15 to be equitably interleaved with other I/O activities of the DHCP server 19.

[0036] It will be appreciated that the UDP port number on which the NAC is configured to receive messages from the DHCP server may be predefined as an environment variable of the DHCP server 19. The port on which the DHCP server 19 itself listens is not configurable but may be an ephemeral port chosen by the system. Therefore, when the NAC 15 replies to any message from the DHCP server 19, the NAC 15 will send the response message back to the IP address and port that were the source of the message to which it is responding.

[0037] Messages sent from the DHCP server 19 to the NAC 15 may be load-balanced by a virtual server (not shown), which will permit multiple concurrent notification requests to be served by different instances of the NAC 15. As those skilled in the art will appreciate, it is possible to use a persistent TCP session instead of UDP, however this is less preferable as the requests must be serialised through a single NAC instance resulting in greater overhead of establishing a new TCP session for every exchange.

[0038] The network router 13, NAC 15, AAA module 17 and DHCP server 19 of the captive portal 11 may be arranged as components in a wired network. A central web server (not shown) may also be included in the captive portal 11 for facilitating communication of network data and messages between the components. The web server may include a plurality of servers forming a web server farm and all HTTP/HTTPS traffic between the components of the captive portal 11 would be transmitted via the web server farm to be load balanced.

Authentication Process

[0039] A brief description has been given above of the components forming part of the network access system 1 of this embodiment. A more detailed description of the operation of these components in this embodiment will now be given with reference to the flow diagram of Figure 2, for an example computer-implemented authentication process using a notification protocol between the NAC 15 and the DHCP server 19.

[0040] As shown in Figure 2, the process begins at step S2-1 where the client device 3 identifies a wireless access point 7 of the core network 5 of the system 1. At step S2-3, the client device 3 then transmits a DHCP Request message to network 5 via the wireless access point 7, which is intercepted by the network router 13 of the captive portal 11 and passed to the DHCP server 19. At step S2-5, the DHCP server 19 receives the DHCP Request message from the client device 3 and performs the typical validation steps up until the point at which the DHCP server 19 is ready to grant a lease on a specific IP address to the client device 3. However, in this embodiment, before the DHCP server 19 allocates an IP address and lease, the DHCP server 19 transmits a lease assignment notification to the NAC 15 at step S2-7 and waits for a reply from the NAC 15. The DHCP server 19 therefore effectively places the lease assignment process in a pending state until a response is received from the NAC 15 to confirm that MAC auth processing for the client device 3 has been completed.

[0041] In this way, the DHCP server 19 delays the allocation to the client device 3 of a lease on an IP address until MAC Auth is known to have completed. Until the client device 3 has obtained an IP address assigned by the DHCP server 19, the client device 3 is not able to issue any valid network requests. Thus, a user device 3 registered for MAC Auth will not be incorrectly presented with a UAM page since it will be impossible for the client device 3 to initiate any browser activity until MAC Auth has been completed. Additionally, the DHCP server 19 informs the NAC 15 of every impending lease assignment so that the NAC 15 has the MAC addresses for all client devices that are to be connected to the core network 5, for example for use in CDRs.

[0042] Accordingly, at step S2-9, the NAC receives the lease assignment notification from the DHCP server 19 over the UDP communication channel. In this embodiment, the protocol messages exchanged between the NAC 15 and the DHCP server 19 are encoded in binary and as illustrated in the exemplary message data structure in Figure 3, comprise a message code 31-1, a version number 31-2, followed by three parameter fields 31-3 to 31-5:

OP Code 31-1 - is a one-byte field whose value indicates the type of message. For example, a value 1 means a lease assignment is to be performed, and 2 means a lease is being released.

Version 31-2 indicates the version number of the packet format used between the

DHCP server 19 and the NAC 15. For example, the version may be set to 1 in implementations adhering to the specification of the present embodiment, but may be changed in the future to permit adoption of a new packet format, e.g., to support new packet addressing protocols. The NAC 15 should confirm the version number is set to an agreed version before processing the packet.

MAC Address 31-3 - is the 6-byte MAC address of the client device 3 as received by the

DHCP server 19 in the DHCP Request message. It is appreciated that the DHCP protocol allows MAC addresses to be up to 16-bytes and the message data format may be adapted to handle longer MAC addresses,

Duration 31-4 is the length of time for which the lease is being assigned, expressed as an unsigned 32-bit value in seconds, and stored in network byte order. IP Address 31-5 - is the IP address which is to be assigned to the client device 3, held in a

32-bit field and stored in network byte order.

[0043] At step S2-11, the NAC 15 extracts the data from the received data packet and processes the extracted data for MAC authentication. The NAC 15 may perform MAC Auth for the given MAC address, or simply record the client's MAC address for use in CDRs. Authenticating the client device 3 based on the MAC address extracted from the lease assignment notification typically involves the steps of:

Determining if there is a match between the MAC address from the request and the MAC address cache provisioned in the database of registered users 16.

- If a match exists, then processing the client device 3 with full MAC authentication.

The extracted MAC address is logged for the lease.

- However, if a match does not exist, then log the extracted MAC address for the Non- MAC Auth client device 3 in a Lease cache and send a response to the client device 3, for example to initiate user registration of the client device 3 for MAC Auth.

- Lookup a username and password associated with the client device 3, for example by looking up a voucher used to register the MAC address.

Get the active session (e.g. Radius session) if any for the client device 3.

If there is an active session, return a response to the lease assignment notification. If there is no active session, send request to AAA module 17 to authenticate the user. If successful response received from the AAA module 17, mark the user as validated user on network router 13 and send an accounting request to the AAA module 17.

[0044] Accordingly, after the NAC has completed processing of the client device 3 for MAC authentication or logging the MAC address for non-MAC Auth devices, the NAC 15 transmits a response back to the DHCP server 19 that corresponds to the received lease assignment notification, at step S2-13. In this embodiment, the same protocol message is used for both the request and the acknowledgement. Therefore, when the NAC 15 completes the processing for this client device 3 and the lease, the NAC 15 simply returns the lease assignment notification message it received to the DHCP server 19 unchanged.

[0045] At step S2-15, the DHCP server 19 receives the response to lease assignment notification data message from the NAC 15. Once the DHCP server 19 receives confirmation that the MAC Auth processing has been completed by the NAC 15, the DHCP server 19 proceeds to grant a lease for an allocated IP address to the client device 3 at step S2-15. At step S2-17, the DHCP server 19 then sends a DHCP Acknowledgement message to the client device 3 to complete automatic configuration of the assigned network address for the device. At step S2-21, the client device 3 is then able to initiate network services.

[0046] Those skilled in the art will appreciate that the DHCP server 19 may have multiple requests outstanding at any given time and that the corresponding responses from the NAC 15 need not necessarily arrive in the same order that the requests were transmitted. It is also appreciated that the DHCP server 19 may allocate IP addresses to other network infrastructure components as well as client devices 3, so the NAC 15 will be notified of lease assignment operations for devices of which it has no knowledge and may be configured to ignore these as appropriate.

[0047] In this embodiment, the DHCP server 19 is configured with a predefined upper bound on the time the NAC 15 may take to process the lease assignment notification message. The duration of the timer may be set as a configuration parameter of the DHCP server 19 and may depend on the granularity defined by the DHCP server 19, for example an integral number of seconds. Accordingly, at step S2-19, the DHCP server 19 runs a timer associated with the transmitted lease assignment notification and, if the timer expires before a corresponding response is received, the DHCP server 19 will proceed to grant the lease as discussed above at step S2-15. This ensures that users are still able to access the network even if processing at the NAC 15 fails, for example, from a lost message or a malfunction at the NAC 15. The DHCP server 19 may be configured to ignore responses received from the NAC 15 that arrive after the timer has expired.

[0048] In this embodiment, the DHCP server 19 is configured to operate a single timer for this predefined response time window, which may be primed by a call to add_timeout(). The DHCP server 19 then manages the timeouts of individual messages that have been transmitted to the NAC 15 and are awaiting response. When the timer has expired, an action routine is called to walk the hash table of waiting messages and action all that have expired. If there are still messages in the hash table that have not expired, add_timeout() is called again to re- prime the timer. In the event that a response is received from the NAC 15 before the timer expires, once the associated message has been processed as described above, the timer is checked to determine if it should be cancelled or reset. If the message hash table is now empty, the timer can be cancelled by a cancel_timer() call. However, if there are still messages awaiting acknowledgement, and the one which was acknowledged had the earliest timeout, the timer can be reset by a call to add_timeout() which will supersede the pervious call. If the message that was acknowledged did not have the earliest timeout, no action is required because an appropriate timer is set and running.

[0049] If a lease is granted by the DHCP server 19 upon such a timer expiry, there are two possible outcomes that may be observed by a MAC Auth user. If the login has still not completed by the time he uses a browser, he will be presented with a UAM page and will have to go though the manual login process. If, however, the login completed shortly after the timer expired and before he attempted to use a browser, he will be unaware there was a problem. Those skilled in the art will therefore appreciate that the timer is set to a predefined value that permits a correctly functioning NAC 15 to complete the login before the timer expires. Whenever the DHCP server 19 intends to release an IP address, for example, because the lease has expired, it notifies the NAC 15 of the IP address and the associated MAC address. Since the DHCP server 19 allocates IP addresses to network infrastructure components as well as client devices, the NAC 15 will be notified of release operations for devices of which it has no knowledge and must ignore these as appropriate.

Network Access Controller

[0050] Figure 4 is a flow diagram illustrating exemplary steps typically carried out by the NAC 15 to process the client device 3 for MAC authentication as discussed above at step S2- 11. As shown in Figure 4, at step S4-1, the NAC 15 determines if there is an active lease for the client device 3 in the DHCP log 21. If it is determined at step S4-1 that an active lease does not already exist for the client device 3, then at step S4-3, the NAC 15 creates a new lease record in the DHCP log 21 and logs the extracted MAC address in the lease record. On the other hand, if it is determined at step S4-1 that an active lease does exist for the client device 3, then at step S4-5, the NAC 15 determines if the MAC address of the existing lease matches the MAC address extracted from the new request. If it is determined at step S4-5 that the MAC addresses do not match, then at step S4-7, the NAC 15 instructs the DHCP server 19 to release the existing lease and updates the lease log to remove the existing lease. The NAC 15 then proceeds to create a new lease record in the DHCP log 21 as discussed above at step S4-3. However, if it is determined at step S4-5 that the existing MAC address matches the extracted MAC address, then at step S4-9, the NAC 15 instructs the DHCP server 19 to extend the lease by the time specified in the DHCP request and updates the lease log accordingly.

[0051] At step S4-11, the NAC 15 determines if the client device 3 is registered with the network access system 1 for MAC authentication by checking if the MAC address of the client device 3 is stored in the database of registered users 16. If it is determined at step S4- 11 that the device is not registered for MAC Auth, then the NAC 15 proceeds to return the response to lease assignment notification message to the DHCP server 19 at step S4-13, because the MAC address for the non-MAC Auth client device 3 has been logged in a new or existing lease record. As will be described in more detail below, the network access system 1 may be configured to provide for registration of the MAC address of an unregistered client device directly from the client device 3, thereby enabling efficient authentication for network access through the NAC 15.

[0052] On the other hand, if it is determined at step S4-11 that the client device 3 is registered for MAC Auth, then at step S4-15, the NAC 15 updates the last network activity for the client device 3. At step S4-17, the NAC 15 then determines if the client device 3 is already logged in an active session (eg. an active Radius session). If the client device 3 is already logged in an active session, then the NAC 15 proceeds to return the response to lease assignment notification message to the DHCP server 19 at step S4-13 for the MAC Auth client device 3 that is already connected and was sending another DHCP request. On the other hand, if it is determined at step S4-17 that the client device 3 is not already logged in an active session, then the NAC 15 sends a start request to the AAA module 17 at step 4-19, for example to start a new Radius session. At step S4-21, the NAC 15 then sends a mark request to network router 13 to inform the router of the new session.

[0053] At step S4-23, the NAC 15 sends an accounting start request to the AAA module 17, for example to start accounting of the Radius session. The NAC 15 then awaits confirmation that the accounting start request was successful, and if it is determined at step S4-25 that the accounting start request was successful, then at step S4-27, the NAC 15 creates a new session for the client device 3. The NAC 15 saves an accounting record at step S4-31 if the accounting start request was not successful, before creating the new session. The processing then proceeds to step S4-13 where the response to lease assignment notification message is returned to the DHCP server 19 for the new MAC Auth client device 3 connecting to the core network for the first time. [0054] Figure 5 is a flow chart illustrating the steps carried out by the NAC 15 for processing a DHCP release message to remove an existing lease and the associated session. In this embodiment, the DHCP lease release message has the same message data structure as illustrated in Figure 3, and includes an OPCode value of 2. The duration field will be zero if the message is a lease release, and will be ignored by the NAC 15 upon receipt. The DHCP server 19 transmits this unacknowledged message to the NAC 16 whenever a lease expires or is explicitly released by a client device 3.

[0055] As shown in Figure 5, on receiving a DHCP release message, the NAC 15 extracts the MAC address for an identified client device 3 from the message and proceeds to find the active session for the identified client device 3 at step S5-1. If the NAC 15 does not find a session for the client device at step S5-3, then the DHCP release message can be ignored and processing ends. However, if the NAC 15 finds a session for the client device at step S5-3, then at step S5-5, the NAC 15 sends an unmark request to the network router 13 to notify the router that the session is to be stopped. At step S5-7, the NAC 15 then sends an accounting stop request to the AAA module 17 to terminate accounting for that session, and awaits confirmation of the stop operation at step S5-9. If the accounting stop request was successful, then at step S5-11, the NAC 15 removes the session for the client device 3 before removing the lease from the DHCP log 21 at step S5-13. The NAC 15 saves an accounting record at step S5-15 if the accounting stop request was not successful, before removing the session and the lease. The NAC 15 does not need to send a reply to the lease release notification message back to the DHCP server 19 after appropriate action has been taken.

MAC Auth Registration

[0056] In the embodiment described above, the NAC 15 is configured to determined if a client device 3 is registered for MAC Auth. Figure 6 is a flow diagram illustrating the process of registering a client device 3 for MAC authentication by the NAC 15 in the network access system 1 according to an embodiment. In particular, the network access system 1 provides for registration of the MAC address of an unregistered client device directly from the client device 3, thereby enabling efficient authentication for network access.

[0057] As shown in Figure 6, the registration process begins at step S6-1 where the client device 3 receives a notification message from the NAC 15 that the client device 3 is not registered for MAC auth by the network access system 1. Those skilled in the art will appreciate that a user may initiate registration of the client device 3 for MAC authentication prior to establishing a network connection with a wireless access point 7 of the core network 5. Alternatively, the user may register the client device 3 for MAC authentication after initiating a network connection with the wireless access point 7, in response to the NAC 15 determining that the client device 3 is not registered in the database of registered users 16 as described above.

[0058] At step S6-3, the client device 3 displays an alert message to the user to register the client device 3 for access to the core network 5. In this embodiment, the alert message provides options for the user to proceed with the registration process or to postpone registration until a later time. Optionally, the alert message may include additional options, for example to request and display more information about the registration process. Accordingly, if at step S6-3, the user chooses to proceed with registration of the device for MAC authentication, then at step S6-5, the client device 3 displays a registration screen including a prompt for the user to input a Mobile Subscriber Number (MSN) associated with the client device 3. The client device 3 may optionally perform validation processing of the user input MSN to verify that the user input is in a predetermined form, for example checking that the input number begins with known digits associated with a mobile device and/or country code, and that the input number has a correct number of digits. At step S6-7, the client device 3 then determines the MAC address of the client device 3, for example by retrieving the information from device parameters stored by the operating system of the client device 3. At step S6-9, the client device 3 generates a registration request message including data identifying the MAC address, the MSN and the mobile operator associated with the client device 3 that is to be registered.

[0059] On the other hand, if the user chooses to postpone the registration process at step S6-3, then at step S6-10 the client device 3 displays an option for the user to register the device at a later time. For example, in an embodiment, a software application is provisioned on the client device for viewing a list of wireless access points of the core network 5. The software application may be configured to display the registration alert message the first time that the client device 3 processes MAC auth registration for the client device 3. The user can click a button "Later" in the registration alert message, or can exit out of the registration page by clicking a "Back" button, in order to postpone the registration process. The software application may be configured to then display a user- selectable element, such as a button or banner, which when clicked will take the user to the same registration screen as described at step S6-5 above. Subsequent launches of the software application can include an initial check of whether the device is registered but will not show the registration alert. Instead, the registration button or banner may be displayed with or over the list of wireless access points if the client device 3 is not registered for MAC auth with the network access system 1.

[0060] At step S6-11, the NAC 15 receives the registration request from the client device 3 and determines if the client device 3 meets predetermined criteria for MAC auth registration. For example, the MSN can be compared with a database associated with the mobile operator to determine if the number matches one with an appropriate contract type for that mobile operator. Additionally or alternatively, the MSN can be checked to confirm that it has not been registered with a different MAC address. If it is determined that the device is valid for MAC authentication in the network access system 1, then at step S6-13, the NAC 15 registers the MAC address of the client device 3 by updating the database of registered users 16. A registration success message is then transmitted back to the client device 3 at step S6-15 and displayed by the client device 3 at step S6-17. On the other hand, if at step S6-11, the NAC 15 determines that the client device 3 is not a valid device for MAC authentication in the network access system 1, then at step S6-19 an error message is transmitted back to the client device 3 and displayed by the client device 3 at step S6-17.

MAC Auth Splash Page

[0061] Figure 7 is a block diagram illustrating a network access system 71 for controlling network access by MAC Auth registered client devices according to another embodiment which will be described using corresponding reference numerals to those of Figure 1 where appropriate for corresponding elements. In the embodiment described above with reference to Figure 1, after the DHCP server 19 grants a lease for an allocated IP address to the client device 3, a DHCP Acknowledgement message is transmitted to the client device 3 to complete automatic configuration of the assigned network address for the device, and the client device 3 is then able to initiate network services. In this embodiment, the network access system 71 is configured to provide additional control of access by the client devices to network services depending on stored policy rules. For example, a policy rule can be provided to redirect all network traffic from a MAC authenticated client device to a particular network resource. The network resource can be a MAC Auth splash page for display in a web browser of the client device, and network access can be restricted until the MAC authenticated user has viewed and dismissed the MAC Auth splash page. As another example, a different policy rule can be provided to block access to and from specific network resources depending on the type of application.

[0062] As shown in Figure 7, the network router 13 of the captive portal 72 in this embodiment stores a database of policy rules 73 defining filters and routing instructions for network service requests from client device 3. Those skilled in the art will appreciate that typically the network router 13 will initially redirect network requests from client device 3 that has been granted access via the core network 5, to a squid proxy server 75 as is known in the art. A first squid proxy server 75 is provided in the captive portal 11 to call a redirect module 77 to request, from the NAC 15, a URL (Uniform Resource Locator) of a landing web page 79 that is to be displayed to the client device 3. The first squid proxy server 75 can store the landing page as a cached copy and transmits the landing web page back to client device 3 via the network router 13 for display by the client device 3, before enabling subsequent unrestricted access to requested network resources.

[0063] In this embodiment, a second squid proxy server 81 is provided in the captive portal and the network router 13 initially redirects network requests from a MAC authenticated client device 3 that has been granted access via the core network 5, to the second squid proxy server 81, based on the policy rules 73. The second squid proxy server 81 calls the redirect module 83 to request from the NAC 15 a URL of a MAC Auth splash page 85 that is to be displayed to the client device 3. The second squid proxy server 81 can store the MAC Auth splash page as a cached copy and transmits the MAC Auth splash page back to client device 3 via the network router 13 for display by the MAC Authenticated client device 3, before enabling unrestricted access to requested network resources.

[0064] Figure 8, which comprises Figures 8a and 8b, is a flow diagram illustrating an exemplary process of the operation of policy routing and display of a MAC Auth splash page using the components of the network access system 71 in this embodiment. As shown in Figure 8, at step S8-1, the client device 3 associates with the wireless access point 7, which initiates a DHCP request. At step S8-3, the network router 13 receives the DHCP request, performs policy routing and allows the DHCP request to pass through to the DHCP server 19. At step S8-5, the DHCP server 19 finds an IP address for the client device 3 and sends a MAC Authentication request to the NAC 15 at step S8-7. [0065] At step S8-9, the NAC 15 receives the MAC Authentication request and determines if the client device 3 is registered for MAC authentication by determining if a matching MAC address for the client device 3 is present in the database of MAC Auth registered devices 16. Once a match is found, the client device 3 is then MAC authenticated and the network access system 71 attempts to log the MAC authenticated client device 3 on to the core network 5 at step S8-l l.

[0066] After the MAC authenticated client device 3 has been assigned a lease for an allocated network address by the DHCP server 19 at step S8-13, the NAC 15 communicates with the network router 13 at step S8-15 by sending a mark request identifying the assigned IP address for the client device and an indication of the type of the mark request. In this embodiment, there are two types of mark request: a first type referred to as a 0x1 mark request for full Internet access and a second type referred to as a 0x2 mark request for restricted Internet access. For example, one restriction that can be enforced by the network access system 71 is that HTTP (Hypertext Transfer Protocol) and HTTPS (Hypertext Transfer Protocol Secure) user traffic destined for ports 80 and 443 will result in the traffic being redirected, based on the policy rules 73, until the MAC Auth splash page 85 has been viewed by the user and the policy rules 73 updated accordingly. In this way, when a user opens a browser on the client device 3 and requests a web page after connection to the core network 5, the request destined for port 80 of a particular network address is redirected by the network router 13 based on the policy rules 73 so that the MAC Auth splash page 85 is displayed to the user initially instead of the requested web page. Alternatively, all network traffic received from the client device 3 may be directed by the network router 13 until the MAC Auth splash page 85 has been viewed by the user. Accordingly, at step S8-17, the network router 15 receives the mark request and stores a new policy rule or updates the database of policy rules 73 based on the type of the received mark request for the associated IP address. The network router 15 is now configured to perform policy routing for the client device based on the policy rules 73.

[0067] As discussed above, after the client device 3 is granted network access through the core network 5, the policy rule for that client device 3 has a 0x2 mark which indicates that the network router 13 will redirect network traffic from the client device 3 to the second squid proxy server 81, at step S8-19. Therefore, at step S8-21, the second squid proxy server 81 calls the redirect module 83, which sends a redirection request to the NAC 15 at step S8-23 to determine where to redirect the user. The redirection request includes the IP address of the client device 3 and a unique parameter indicating that the client device 3 is a MAC authenticated device. At step S8-25, the NAC 15 identifies the IP address and the MAC auth parameter from the request. In response to determining that the request is associated with a MAC authenticated device, the NAC 15 calls a location service to construct a Locationlnfo object including the MAC splash page URL at step S8-27. The NAC 15 also transmits an unmark request to the network router 13 at step S8-29 to remove the 0x2 mark from the policy rule for the client device 3 at step S8-31, before sending the Locationlnfo object to the redirect module 77 at step S8-33.

[0068] Finally, at step S8-35, the redirect module 77 receives the Locationlnfo object from the NAC 15 and obtains the MAC splash page at the URL indicated in the Locationlnfo object. At step S8-37, the redirect module 77 transmits the MAC splash page to the client device 3 via the second squid proxy server 81 and the network router 13. In this way, a redirect application will be hit on a different path to indicate that it needs to look at the Mac Authentication splash page URL and not the normal Landing Page URL as defined when being redirected when the user has no mark on the network router 13.

Roaming MAC Authentication

[0069] Figure 9 is a block diagram illustrating an embodiment of a network access system 91 for enabling a client device 3 that is registered for MAC Auth with a home core network 5 to roam to a different partner core network 93 associated with a partner service provider, and providing for seamless and transparent MAC authentication of the client device 3 via the partner core network 93, without requiring any additional registration of details, for example with the partner service provider. This alternative embodiment will be described using corresponding reference numerals to those of the preceding figures where appropriate for corresponding elements.

[0070] As shown in Figure 9, the network access system 91 includes a home captive portal 11-1 that intercepts network data packets from computing devices connected to the home core network 5. The home captive portal 11-1 includes a network router 13-1, NAC 15-1, database 16-1 of MAC Auth devices registered with the home core network 5, AAA module 17-1, billing system 18-1 and DHCP server 19-1 to provide for authentication, authorization and accounting of the network connections through the home core network 5 as described in the embodiments above. In this embodiment, a partner captive portal 11-2 intercepts network data packets from the client device 3 connected to a wireless access point 7 of the partner core network 93. The partner captive portal 11-2 includes a network router 13-2, NAC 15-2, database 16-2 of MAC Auth devices registered with the partner core network 93, AAA module 17-2, billing system 18-2 and DHCP server 19-2 to provide for authentication, authorization and accounting of the network connections through the partner core network 93.

[0071] As will be described in more detail below, when the client device 3 roams to the partner core network 93, all request messages from the client device 3 will be intercepted and blocked by the partner captive portal 11-2 until the client device 3 has been MAC authenticated. Typically, the client device 3 would receive a web page from the partner captive portal 11-2 prompting the user to register the client device 3 with the partner service provider. In this embodiment, the partner captive portal 11-2 instead identifies the home service provider associated with the roaming client device 3 and requests MAC authentication of the client device 3 by the home captive portal 11-1. As those skilled in the art will appreciate, secure communication between the home captive portal 11-1 and the partner captive portal 11-2 can be provided over a dedicated IPsec (Internet Protocol security) VPN (virtual private network) tunnel 95 established between the AAA module 17-2 of the partner captive portal 11-2 and the AAA module 17-1 of the home captive portal 11-1.

[0072] Figure 10 is a flow diagram illustrating an exemplary process of the operation of MAC authentication of a roaming client device 3 connected to a partner core network 93, using the components of the network access system 91 in this embodiment. As shown in Figure 10, at step S I 0-1, the client device 3 identifies a wireless access point 7 of the partner core network 93 of the system 91. At step S 10-3, the client device 3 then transmits a proxy request message to the partner core network 93 via the wireless access point 7, which is intercepted by the network router 13-2 of the partner captive portal 11-2 at step S 10-5. At step S 10-7, the NAC 15-2 of the partner captive portal 11-2 captures the proxy request and determines the home provider based the proxy request at step S I 0-7. For example, the proxy request can be an HTTP request to a predetermined URL such as "http://198.63.210.250:80/hotspotcheck.txt". The NAC 15-2 can be configured to capture any HTTP requests containing '7hotspotcheck.txt" and to identify the home provider based on provider ID in the request. The NAC 15-2 then instructs the AAA module 17-2 to perform MAC authentication for the roaming client device 3 through the identified home provider. [0073] Accordingly, at step S 10-9, the AAA module 17-2 identifies the MAC address of the client device 3 from the proxy request and generates a MAC Auth request message at S I 0-11, including the identified MAC address as the login attribute, such as a username and password, in the MAC Auth request. At step S 10- 13, the AAA module 17-2 transmits the generated MAC Auth request message to the AAA module 17-1 of the home captive portal 11-1 over the secure communication channel 95. At step S10-15, the AAA module 17-1 of the home captive portal 11-1 receives and identifies the MAC Auth request and checks whether the calling- station-id matches the MAC address in the username attribute of the received request message, at step S 10-17. When a match is confirmed, the AAA module 17-1 can perform AAA processing for the roaming client device 3, for example as described in the embodiments above. Once authenticated and authorised, the AAA module 17-1 transmits an access accept response message back to the partner captive portal 11-2 at step S10-19. The AAA module 17-2 receives the access accept response at step S 10-21 and proceeds to allow internet access to the roaming client device 3 at step S 10-23.

Advantages

[0074] A number of advantages will be understood from the above description of the embodiments of the present invention.

[0075] In particular, the race condition discussed in the background section above is avoided because the DHCP server delays the allocation to a computing device of a lease on an IP address until MAC Auth is known to have completed. The core network of the above embodiments allows users and computing devices to use MAC authentication across the network as an access method with real-time permissioning rather than waiting for a period of time for validation.

[0076] Additionally, in the Network Access Controller described in an embodiment above, the lease management logic is integrated with the current session logic to ensure that whenever a lease is created for MAC Auth users, a session is also created, and that a session does not exist if there is no corresponding assigned lease. There is an up to date lease for every session, for both MAC Auth users and Accounting Non-Authenticated Session users.

[0077] In the event that a computing device is not registered in the database of MAC authenticated devices, an embodiment described above enables efficient registration from the computing device itself. [0078] In the alternative embodiment of the network access system described above with reference to Figure 7, access by MAC authenticated devices to network resources through the core network can be blocked and controlled until a predetermined network resource such as a MAC splash web page has been viewed and dismissed by a user of the device. Alternative Embodiments

[0079] It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.

[0080] For example, in the embodiments described above, the DHCP server is configured to respond to DHCP requests received from client devices attempting to connect to the core network. As those skilled in the art will appreciate, the DHCP server may be configured to intercept assignment of a lease from any other network component, and delay sending of the DHCP acknowledgement to the intended client device until after the NAC has been notified as described in the embodiments above.

[0081] In the embodiments described above, the network access system is illustrated with a single captive portal having a single network router and DHCP server. As those skilled in the art will appreciate, the network access system may include a plurality of DHCP servers and the NAC will be configured to return a received lease assignment notification to the correct one of the plurality of DHCP servers. As yet a further alternative, the system may include a plurality of captive portals, each configured as described in the above embodiments.

[0082] In the embodiment described above, the captive portal comprises a plurality of separate components, including servers, routers and modules. As those skilled in the art will appreciate, the components of the captive portal may be implemented as any combination of hardware and/or software, and the system may store a plurality of computer programs or software in memory, which when executed enable the system components to implement embodiments of the present invention as discussed herein. Additionally, those skilled in the art will appreciate that the software may be stored on a non-transitory computer program medium or product, and loaded into the system using any known instrument, such as removable storage disk or drive, hard disk drive, or communication interface, to provide some examples.

[0083] Alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims.

Claims

1. A DHCP server coupled to a network access controller in a computer networking environment, the DHCP server operable to allocate a lease for a network address to a computing device responsive to a DHCP request from the computing device, wherein the DHCP server allocates the lease in response to receiving a notification from the network access controller after MAC authentication of the computing device.

2. The DHCP server of claim 1, wherein said notification is transmitted over a communication channel between the network access controller and the DHCP server.

3. The DHCP server of claim 2, wherein the communication channel is a UDP socket to a port of the network access controller.

4. The DHCP server of claim 3, wherein a network address and port of the network access controller are stored as predefined environment variables for the communication channel.

5. The DHCP server of any preceding claim, wherein the DHCP server is configured to transmit a lease assignment notification message to the network access controller before allocating the lease, and wherein said received notification is the same lease assignment notification message that is sent back by the network access controller.

6. The DHCP server of any preceding claim, wherein the DHCP server further comprises a timer for determining that a notification is received from the network access controller within a predefined time window.

7. The DHCP server of claim 6, wherein the DHCP server is configured to proceed to allocate the lease after the timer has expired.

8. In a computer networking environment, a system comprising:

a network access point; a computing device coupled to the network access point;

a network access controller operable to perform MAC authentication of the computing device; and

at least one DHCP server according to any one of claims 1 to 7 coupled to the network access controller.

9. In a computer networking environment, a captive portal system coupled to a network, the captive portal system comprising:

means for receiving a join request from a computing device to join a network, the request identifying a MAC address of the computing device;

means for transmitting a MAC authentication request to a remote captive portal system, wherein the MAC authentication request includes the MAC address of the computing device as a login attribute; and

means for receiving an indication that the computing device is MAC authenticated and in response, providing the computing device with access to the network.

10. The system of claim 9, further comprising means for identifying the remote captive portal associated with the computing device based on the received join request.

11. The system of claim 9, further comprising a DHCP server operable to allocate a lease for a network address to the computing device after the indication that the computing device is MAC authenticated is received.

12. A captive portal system operable to intercept network data packets from computing devices connected to a local network, to provide for authentication, authorization and accounting of the network connections coupled to a local network, the captive portal system comprising:

means for receiving a MAC authentication request from a remote captive portal system coupled to a remote network, wherein the MAC authentication request includes the MAC address of a computing device as a login attribute;

means for determining that the MAC address included in the MAC authentication request is associated with a registered MAC authenticated device; and means for transmitting a response to the remote captive portal indicating that the computing device is MAC authenticated.

13. The system of claim 12, further comprising a network access controller operable to perform MAC authentication of the computing device.

14. The system of any one of claims 9 to 13, wherein the login attribute comprises a username and a password.

15. The system of any one of claims 9 to 14, further comprising means for establishing a secure communication path with the remote captive portal system.

16. A computing device coupled to a network access controller in a computer networking environment, the computing device operable to transmit a registration request to the network access controller, the registration request including the MAC address of the computing device, whereby the network access controller is operable to perform MAC authentication of the computing device.

17. The computing device of claim 16 further operable to receive user input of a mobile subscriber number associated with the computing device and wherein the registration request further includes the received mobile subscriber number.

18. The computing device of claim 16 or 17, operable to transmit said registration request in response to a received indication that the computing device is not registered for MAC authentication by the network access controller.

19. In a computer networking environment, a system comprising:

a network access point;

a computing device as set out in any one of claims 16 to 18, coupled to the network access point; and a network access controller operable to determine if the computing device is registered for MAC authentication by the system and to perform MAC authentication of the computing device.

20. The system of claim 19, wherein the network access controller is further operable to register said computing device for MAC authentication in response to receiving said registration request.

21. The system of claim 19 or 20, further comprising a database of computing devices registered for MAC authentication by the system, and wherein the network access controller determines if the computing device is registered in said database.

22. In a computer networking environment, a system for controlling access by a computing device to network resources, the system comprising:

a network access controller operable to determine if the computing device is registered for MAC authentication by the system and to perform MAC authentication of the computing device; and

a network router operable to receive a request for a network resource from the MAC authenticated computing device and to transmit a predetermined network resource to the computing device in response.

23. The system of claim 22, wherein the predetermined network resource is a MAC splash web page.

24. The system of claim 22, wherein the network router stores a database of policy rules including a routing rule associated with the computing device, the routing rule indicating that the predetermined network resource is to be transmitted to the computing device.

25. The system of claim 24, wherein the network router is further operable to update the routing rule after the predetermined network resource is transmitted to the computing device to remove the indication that the predetermined network resource is to be transmitted to the computing device.

26. A method of allocating a lease for a network address to a computing device, the method comprising, in a DHCP server:

transmitting a data message to a network access controller coupled to DHCP server indicating that a lease is to be allocated;

receiving a data message from the network access controller after MAC authentication of the computing device by the network access controller; and

allocating the lease in response to receiving said data message from the network access controller.

27. The method of claim 26, further comprising providing a communication channel between the network access controller and the DHCP server for transmission of said data messages.

28. The method of claim 27, wherein the communication channel is a UDP socket to a port of the network access controller.

29. The method of claim 28, further comprising storing a network address and port of the network access controller as predefined environment variables for the communication channel.

30. The method of any one of claims 26 to 29, wherein the data message received from the network access controller is the same data message that is transmitted to the network access controller.

31. The method of any one of claims 26 to 30, further comprising determining whether the data message is received from the network access controller within a predefined time window.

32. The method of claim 31, wherein the lease is allocated after it is determined that the data message was not received from the network access controller within the predefined time window.

33. A method of processing MAC authentication of a computing device connected to a network, the method comprising, in a captive portal system of the network:

receiving a join request from the computing device to join the network, the request identifying a MAC address of the computing device;

transmitting a MAC authentication request to a remote captive portal system, wherein the MAC authentication request includes the MAC address of the computing device as a login attribute; and

receiving an indication that the computing device is MAC authenticated and in response, providing the computing device with access to the network.

34. The method of claim 33, further comprising identifying the remote captive portal associated with the computing device based on the received join request.

35. The method of claim 33, further comprising allocating a lease for a network address to the computing device after receiving the indication that the computing device is MAC authenticated.

36. A method of processing MAC authentication of a roaming computing device connected to a remote network, the method comprising, in a captive portal system of a local network:

receiving a MAC authentication request from a remote captive portal system coupled to the remote network, wherein the MAC authentication request includes the MAC address of a computing device as a login attribute;

determining that the MAC address included in the MAC authentication request is associated with a registered MAC authenticated device associated with the local network; and transmitting a response to the remote captive portal indicating that the computing device is MAC authenticated.

37. The method of claim 36, further comprising performing MAC authentication of the computing device when it is determined that the computing device is a registered MAC authenticated device associated with the local network.

38. The method of any one of claims 33 to 37, wherein the login attribute comprises a username and a password.

39. The method of any one of claims 33 to 38, further comprising establishing a secure communication path with the remote captive portal system.

40. A method of registering a computing device for automatic MAC authentication by a network access controller in a network access system, the method comprising transmitting, by the computing device, a registration request to the network access controller, the registration request including the MAC address of the computing device, whereby the network access controller is operable to register the computing device for automatic MAC authentication.

41. The method of claim 40 further comprising receiving user input of a mobile subscriber number associated with the computing device, wherein the registration request further includes the received mobile subscriber number.

42. The method of claim 40 or 41, wherein said registration request is transmitted in response to a received indication that the computing device is not registered for MAC authentication by the network access controller.

43. The method of any one of claims 40 to 42, further comprising registering, by a network access controller, said computing device for MAC authentication in response to receiving said registration request.

44. The method of claim 43, further comprising determining, by the network access controller, if the computing device is registered in a database of computing devices registered for MAC authentication by the network access system.

45. A method of controlling access by a computing device to network resources, comprising: determining, by a network access controller, if the computing device is registered for MAC authentication by the system and performing MAC authentication of the computing device; and

receiving, by a network router, a request for a network resource from the MAC authenticated computing device and in response, transmitting a predetermined network resource to the computing device.

46. The method of claim 45, wherein the predetermined network resource is a MAC splash web page.

47. The method of claim 45, further comprising determining, by the network router, if a stored routing rule associated with the computing device includes an indication that the predetermined network resource is to be transmitted to the computing device.

48. The method of claim 47, further comprising updating the routing rule after the predetermined network resource is transmitted to the computing device to remove the indication that the predetermined network resource is to be transmitted to the computing device.

49. A storage medium comprising machine readable instructions stored thereon for causing a programmable device to become configured as the DHCP server in accordance with any one of claims 1 to 7, the captive portal system in accordance with any one of claims 9 to 15, the computing device in accordance with any one of claims 16 to 18, or the system in accordance with any one of claims 22 to 25.

50. A storage medium comprising machine readable instructions stored thereon for causing a computer system to perform a method in accordance with any one of claims 26 to 48.