Scalable personal device sharing

Abstract

Embodiments of the application relate to scalable personal device sharing. An access point (AP) receives a network access request including a first multi-pre-shared key (MPSK) password and queries an authentication server to determine an owner of a first device based on the first MPSK password. The AP receives an advertisement packet from the first device indicating a service provided by the first device and forwards information about the service and the owner to a device sharing server to obtain a device sharing policy. The AP enforces the device sharing policy, which can include receiving a multicast domain name system (mDNS) query from a second device, determining that the second device belongs to the owner of the first device based on a second MPSK password of the second device, indicating the first device in an mDNS response corresponding to the mDNS query, and allowing the second device to access the service provided by the first device.

Description

Technical Field

[0001] This disclosure generally relates to device sharing in networks using the multicast Domain Name System (mDNS). More specifically, this disclosure relates to facilitating mDNS-based device sharing in large networks, while taking into account ownership of different devices. Attached Figure Description

[0002] Figure 1 The illustration shows an example of a network environment that facilitates device sharing according to one aspect of this application;

[0003] Figure 2 An example of an automatic device registration process according to one aspect of this application is illustrated;

[0004] Figure 3 The illustration shows an example of a process for advertising services according to one aspect of this application;

[0005] Figure 4 The illustration shows an example of a process for a query service according to one aspect of this application;

[0006] Figure 5 An example block diagram of a wireless access point according to one aspect of this application is shown;

[0007] Figure 6 A flowchart illustrating an example of a device sharing process according to one aspect of this application is presented; and

[0008] Figure 7 An example of a computer system that facilitates the management of device sharing according to one aspect of this application is illustrated.

[0009] In the accompanying drawings, similar reference numerals denote the same elements. Detailed Implementation

[0010] Multicast Domain Name System (mDNS) is a small-scale implementation of the DNS protocol and can be used to resolve hostnames to Internet Protocol (IP) addresses without the need for dedicated DNS servers. mDNS is a convenient and efficient method for enabling communication between devices on the same local network, such as connecting to a home printer, streaming media, or sharing files between computers. While mDNS makes device sharing easier, appropriate security measures are needed to protect devices shared via mDNS. For example, when different users access the same local network using different devices, it is important to ensure that each user's personal device is not shared with others. One way to implement access control is through device registration, where users are required to register their personal devices. However, for large-scale networks with many users (e.g., corporate or campus networks), a large device registration database will be required. Maintaining the database and ensuring timely updates of all entries through accurate synchronization can present scalability challenges, such as high memory consumption and increased bandwidth and processing power demands. Furthermore, requiring users to register their devices can be inconvenient for them.

[0011] This disclosure provides a solution to the aforementioned problem by enabling registration-free device sharing in a network. More specifically, the solution combines an authentication service that facilitates user authentication with a device sharing service that configures device visibility based on corresponding ownership. Each user may be required to access the network using a user-specific multiple PSK (MPSK) instead of a pre-shared key (PSK). Each user device accessing the network can then automatically register with its owner without manual registration. The device sharing service can transmit the device sharing policy associated with client devices to access points (APs) in the network, ensuring that client devices are only visible to devices belonging to the same owner, thereby effectively creating a virtual mDNS personal area network (PAN) for each user.

[0012] Figure 1 An example of a network environment that facilitates device sharing according to one aspect of this application is illustrated. Figure 1 The illustration shows multiple client devices coupled to network 100 via multiple access points (APs) (e.g., APs 102 and 104). The client devices may belong to different users. In this example, client devices 106, 108, and 110 belong to user 112, and client devices 114 and 116 belong to user 118. Note that, depending on the location of the client devices and other factors that may influence the selection of APs (e.g., AP load), each client device may access network 100 via any of the APs. Figure 1The diagram also illustrates an authentication server 120 and a device sharing server 122 coupled to network 100. Client devices and access points (APs) can be coupled to authentication server 120 and device sharing server 122 via network 100. Authentication server 120 can provide user authentication services, and device sharing server 122 can provide mDNS-based device sharing services to client devices. Note that although in Figure 1 The server is shown as a standalone server, but the authentication server 120 and the device sharing server 122 can also be implemented as cloud-based servers.

[0013] mDNS allows client devices coupled to network 100 to share resources. For example, client device 110 (which could be a smartphone) can stream video to client device 106 (which could be a smart TV) for display. However, even though connected to the same network, it may not be desirable to allow device sharing between devices belonging to different users. Figure 1 In the example shown, smart TV 106 belongs to user 112, and smartphone 116 belongs to user 118. For security purposes, user 112 is unlikely to allow smartphone 116 to stream video to smart TV 106.

[0014] In traditional methods, to prevent sharing of devices belonging to different users, each user needs to register their personal device with a device sharing service provided by a device sharing server 122, ensuring that each device can only receive mDNS query responses from other devices belonging to the same user. For example, user 112 can register client devices 106, 108, and 110 with the device sharing service to allow device sharing between these devices. Similarly, user 118 can register client devices 114 and 116 to allow device sharing between these two devices. The device registration process typically requires users to manually enter device information, which can be cumbersome. Furthermore, the device sharing service needs to maintain a database to store information about all devices accessing the network. Since devices dynamically access the network, the device database needs to be updated dynamically. Maintaining and updating such a database can be challenging for large-scale networks with many users and many client devices.

[0015] To eliminate the need for manual registration of client devices and simplify the process of maintaining and updating device information, according to certain aspects of this application, the device registration process can be combined with the user authentication process. More specifically, each time a client device accesses network 100 (e.g., via AP 102 or 104), authentication server 120 can authenticate the user and associate the client device with the device owner. When a client device advertises for a service, device sharing server 122 can determine a device sharing policy based on the device owner's network role.

[0016] Many mechanisms can be used to authenticate users. In some respects, user authentication can be achieved through the distribution of a user-specific MPSK. MPSK is an extension of the original network security protocol PSK, which uses a single key (e.g., the PSK) for authentication and encryption. Note that existing large-scale networks (e.g., corporate or campus networks) typically rely on PSK Service Set Identifiers (SSIDs) to establish secure connections between wireless routers and devices accessing the network. Because the PSK is shared by the network administrator and many users, mapping devices to their corresponding owners can be challenging. However, with MPSK, each device on the network can be assigned a unique key for authentication and encryption. Compared to the PSK scheme, the MPSK scheme offers significantly stronger security.

[0017] The unique key used in the MPSK scheme links a user's identity to a PSK used for network access. For this purpose, authentication server 120 can provide a unique PSK to each user, rather than a unique key to each device. For example, a unique PSK 120 can be provided to user 112, and a unique PSK 122 can be provided to user 118. Authentication server 120 can maintain a mapping between PSKs and user identities. Depending on some aspects, a user-specific PSK may include a password or passphrase. The length and / or format of the PSK can be predetermined or arbitrary. A user's identity can be represented using a username, with each user associated with a unique username. The username and / or password can be assigned to the user by authentication server 120, or chosen by the user when registering for services with authentication server 120.

[0018] exist Figure 1 In the example shown, each user's personal device can access network 100 using a corresponding user-specific PSK. For example, client devices 106, 108, and 110 can use PSK 120 to connect to AP 102 or 104, and client devices 114 and 116 can use PSK 122 to connect to AP 102 or 104. The AP receiving the connection request can verify the PSK by communicating with the authentication server 120. The authentication server 120 can verify the PSK, look up the corresponding username, and return the username to the AP. Therefore, the AP can maintain a record of the mapping between client devices and their owners' usernames. Note that this mapping is obtained automatically without manual user intervention.

[0019] Device sharing server 122 can track the device sharing policy associated with each username. The device sharing policy specifies whether a user's device should be private or public. Public devices are visible to all devices on the network, while private devices are only visible to other devices belonging to the same user. Whenever the AP receives an advertising packet from a client device, the AP can query the device sharing server 122 for the device sharing policy. When the AP receives an mDNS query requesting services from a client device, the AP can enforce the corresponding device sharing policy.

[0020] Figure 2 An example of an automated device registration process according to one aspect of this application is illustrated. During application, user 202 can interact with authentication server 204 to obtain a username and MPSK password (operation 206). In one implementation example, a network administrator can distribute a Uniform Resource Locator (URL) for a user authentication webpage to the user, and the user can access the webpage to obtain a username and MPSK password by providing certain credentials to verify his or her identity. Note that user 202 can use any computing device (whether personal or public) to obtain the username and MPSK password. Authentication server 204 can store a mapping between MPSK passwords and user 202's identity, which can be linked to usernames (operation 208). For example, authentication server 206 can maintain a user information database that stores user identity information (e.g., student or employee ID), username, and corresponding MPSK password.

[0021] Client device 210 can then send a network access request message 212 carrying the MPSK cipher (i.e., user-specific PSK) to AP 214 to request network access. Upon receiving network access request message 212, AP 214 can send an authentication request 216 to authentication server 204. Depending on some aspects, authentication server 204 may be a Remote Authentication Dial-In User Service (RADIUS) server, which can provide centralized authentication, authorization, and accounting management services. Authentication request 216 may include a RADIUS request carrying the MPSK cipher and Media Access Control (MAC) address of client device 210. Upon receiving authentication request 216, authentication server 204 can perform a lookup in the user information database to verify the received MPSK cipher and determine the mapping between the MPSK cipher and the username (operation 218).

[0022] Subsequently, authentication server 204 may send authentication response 220 to AP 214. According to some aspects, authentication response 220 may include the username corresponding to the MPSK password. According to another aspect, in addition to the username, authentication response 220 may also include information indicating the network role associated with the username. For example, authentication response 220 may specify whether the user has an administrative role. In one example, authentication response 220 may be a RADIUS response, and the username and network role may be included in the vendor-specific attribute (VSA) field of the RADIUS response. Upon receiving authentication response 220, AP 214 may update its client database to record the mapping between the MAC address of client device 210 and the username / role of the corresponding device owner (operation 222).

[0023] Once the MPSK cipher is successfully verified, client device 210 and AP 214 can perform a series of handshakes (operation 224) to establish a secure connection, thereby allowing client device 210 to access the network via AP 214. Depending on some aspects, the handshake may include a four-way handshake for establishing and exchanging appropriate cryptographic keys. Figure 2 As can be seen, the ownership of the client device is automatically determined based on the MPSK password each time the client device accesses the network, and the device owner does not need to manually register the device.

[0024] According to the mDNS protocol, some client devices can advertise to network services (e.g., printing services, screen sharing services, file storage services, etc.), while others can query services. Note that the same device (e.g., a smartphone) can advertise and query services simultaneously.

[0025] Figure 3 An example of a process for advertising services according to one aspect of this application is illustrated. A client device can only advertise to the network after gaining access to the network. In other words, ownership information associated with the client device is already recorded at the AP through which the client device accesses the network. When the client device roams to another AP in the network, the ownership information can also be copied from the previous AP to the current AP. The process for a client device to gain network access can be similar to... Figure 2 The process is shown.

[0026] During operation, client device 302 may send advertising packet 304 to AP 306. The advertising packet may be an mDNS packet, which contains information about the attributes and capabilities of the client device that issued the advertising packet. More specifically, the payload of the mDNS packet may include multiple record fields for identifying one or more services being advertised, including name, type, port, and other information associated with the service. For example, a client device ready for AirPlay may send an advertising packet indicating that it can provide the AirPlay service. Client device 302 may periodically send advertising packets to the network according to the mDNS protocol. Upon receiving advertising packet 304, AP 306 may look up its client database to identify the username associated with client device 302 (operation 308). As previously described, AP 306 maintains a client database that stores mappings between client devices and their owners. For example, entries in the client database may specify the MAC address of the client device and the username associated with the owner of the client device.

[0027] AP 306 can then generate a service report message (operation 310) based on the advertising packet 304 and the username. Note that the service report message is used by the AP to communicate with a device sharing server that provides device sharing services to client devices in the network. The format of the service report message has been previously negotiated and agreed upon between the AP and the device sharing server. In some respects, AP 306 can generate the service report message by encapsulating the payload and username of the advertising packet 304 into a language- and platform-independent protocol buffer (protobuf) message. In other respects, the protobuf message may include the record fields contained in the mDNS advertising packet 304 and the username. In one example, in addition to the username, the service report message may also include the user's network role.

[0028] AP 306 can send service report messages 312 to device sharing server 314, which can be a standalone server or a cloud-based service platform. Depending on some aspects, AP 306 can periodically send service report messages 312 to service sharing server 314. The interval between consecutive service report messages can be between 30 seconds and several minutes. In one example, AP can send a service report message to device sharing server 314 every two minutes. Device sharing server 314 can store the information included in service report messages 312 (e.g., username, user's network role, and device information) in a device database (operation 316). Device information may include, but is not limited to, the device's MAC address and the type of service provided by the device. Note that the device and username / role information in the device database is updated by ad groups, and frequent information exchange between device sharing server 314 and authentication server is no longer required, thus significantly reducing bandwidth and computing power consumption.

[0029] Device sharing server 314 can further determine the device sharing policy associated with a username (operation 318). In one example, device sharing server 314 can use a role-based access control (RBAC) policy to determine whether the network role associated with a username is an administrative role or whether the username has administrative privileges. Note that administrative accounts are typically associated with public devices. For example, a shared printer is typically logged into the network by a user with an administrative role. Therefore, the device sharing policy for the printer can indicate that the printer can be shared by any client device. On the other hand, the device sharing policy for non-administrative usernames can indicate that the device can only be shared by client devices belonging to the same owner (i.e., client devices associated with the same username). According to one aspect, a user can be allowed to define a device sharing policy that allows a user's personal device to be shared by devices owned by one or more friends. For example, a user interface can be presented to the user that allows the user to enter the usernames of one or more friends, allowing client devices associated with those friends to access the user's personal device.

[0030] Device sharing server 314 can also determine the number of neighboring APs of AP 306 (operation 320). Depending on some aspects, device sharing server 314 may interact with a network management service (e.g., AirMatch) to obtain a list of neighboring APs. Device sharing server 314 can then send message 322 containing a device sharing policy to AP 306. Furthermore, device sharing server 314 can send message 324 containing both device information (e.g., MAC address, username, and service content report message 312) and the device sharing policy to each neighboring AP, including neighboring AP 326. Similar to service report message 312, messages 322 and 324 can be protobuf messages. Other possibilities exist for the format of messages exchanged between device sharing server 314 and APs in the network. The scope of this disclosure is not limited to the format of these messages.

[0031] Upon receiving the device sharing policy included in message 322, AP 306 can update its client database to include the device sharing policy in the entry associated with client device 302 (operation 328). Similarly, upon receiving message 324, each neighboring AP (e.g., neighboring AP 326) can update its client database (operation 330). For example, neighboring AP 326 can generate an entry in its client database corresponding to client device 302, and this entry can include device information and the corresponding device sharing policy. The updated client database allows each AP to enforce the device sharing policy.

[0032] from Figure 3 As can be seen, by forwarding device information to neighboring APs, the device sharing server can facilitate the maintenance of service-providing device records for each neighboring AP, allowing service-requesting devices to query the services offered by any AP. Furthermore, ownership information associated with service-providing client devices can be stored on the device sharing server without requiring manual registration of such devices.

[0033] Figure 4 An example of a process for a query service according to one aspect of this application is illustrated. Figure 4In the example shown, the network may include multiple service requesting devices (e.g., devices 402 and 404), multiple service providing devices (e.g., device 406), and multiple access points (APs) (e.g., AP 408). Service requesting device 402 and service providing device 406 belong to the same user and can both access the network using an MPSK cipher associated with username X by establishing a secure connection with AP 408 (operations 410 and 412). On the other hand, service requesting device 404 belongs to a different user and can access the network using an MPSK cipher associated with username Y by establishing a secure connection with AP 408 (operation 414). Note that "service requesting device" and "service providing device" are relative terms because a single device can request and provide services simultaneously. When this disclosure describes the service requesting behavior of a client device, the client device may be referred to as a service requesting device. Similarly, when describing the service providing behavior of a client device, the client device may be referred to as a service providing device. Each device can use an MPSK cipher associated with username X by establishing a secure connection with AP 408 (operation 414). Figure 2 The process shown is similar to the process for accessing the network.

[0034] After gaining access to the network, service provider 406 can communicate with AP 408 to provide advertising services (operation 416). This operation can be similar to... Figure 3 The process shown may include AP 408 forwarding device information associated with service providing device 406 to a device sharing server, and the device sharing server populating neighboring APs with such information.

[0035] AP 408 may receive service query message 418 from service requesting device 402 and service query message 420 from service requesting device 404. Each service query message may query devices in the network that provide a predetermined type of service. Upon receiving a service query message (e.g., message 418 or 420), AP 408 may look up its client database to identify devices that can provide the requested service and their corresponding device sharing policies (operation 422). More specifically, for each identified service-providing device, AP 408 may determine its owner's username and the device sharing policy associated with that username. For example, AP 408 may determine that service-providing device 406 can provide the requested service, and that the device owner's username is X. AP 408 may further determine that the device sharing policy associated with username X is "private," meaning that devices owned by this user can only be shared by devices belonging to the same owner. If the user has granted access to one or more friends, the device sharing policy may indicate the friends' usernames.

[0036] Therefore, AP 408 can respond to service query message 418 with a query response 424 sent to service requesting device 402. Query response 424 indicates to service requesting device 402 that service providing device 406 (which also belongs to the device owner with username X) can provide the requested service. Furthermore, AP 408 can respond to service query message 420 with a query response 426 sent to service requesting device 404. Because service requesting device 404 belongs to a different owner (i.e., the user with username Y), service providing device 406 will not be visible to service requesting device 406, meaning that query response 426 will not indicate service providing device 406 as the device providing the requested service. Instead, query response 426 may include other service providing devices belonging to the device owner with username Y, or, if no such device exists in the network, indicate that no matching device was found. Query response 426 may also include service providing device 406 if the user with username X has already granted access to the user with username Y.

[0037] Figure 5 An example block diagram of a wireless access point according to one aspect of this application is illustrated. AP 500 may include a client device communication unit 502, an authentication server communication unit 504, a device sharing server communication unit 506, a client database 508, a client database update unit 510, a client database lookup unit 512, and a device sharing policy enforcement unit 514. In addition... Figure 5 In addition to the various functional blocks or units shown, the AP 500 may also include other types of functional blocks or units that facilitate the operation of the AP 500, such as providing wireless network access services to client devices.

[0038] The client device communication unit 502 can be responsible for communicating with the client device, such as receiving network access requests and performing handshakes to establish a connection. The client device communication unit 502 can also receive advertising packets and service query messages from the client device and send query responses to the client device.

[0039] The authentication server communication unit 504 can be responsible for communicating with a remote authentication server (e.g., a RADIUS server). For example, when a client device requests network access using an MPSK password, the authentication server communication unit 504 can send a RADIUS request to the authentication server carrying the MPSK password and the client device's MAC address. In response, the authentication server communication unit 504 can also receive an authentication response, wherein the VSA field in the authentication response includes the username and network role of the client device's owner.

[0040] The device sharing server communication unit 506 can be responsible for communicating with a remote device sharing server. More specifically, the device sharing server communication unit 506 can generate and send service report messages based on service advertisement packets from client devices. In one example, the device sharing server communication unit 506 can generate protobuf messages to encapsulate the payload (e.g., resource record) of mDNS advertisement packets from client devices and the username of the client device's owner. The device sharing server communication unit 506 can also receive protobuf messages from the device sharing server that include device sharing policies associated with the usernames. The device sharing server communication unit 506 can also receive device information and corresponding device sharing policies about devices coupled to adjacent APs.

[0041] The client database 508 can store information about client devices coupled to AP 500 and its neighboring APs. Entries in the client database 508 may include the client device's MAC address, the MPSK password used by the client device to access the network, the username associated with the client device, the type of service provided by the client device (e.g., the client device's attributes and functions), and the device sharing policy associated with the username. The client database update unit 510 can be responsible for updating the contents of the client database 508 based on information received from the authentication server and the device sharing server. For example, each time a new client device accesses the network, the client database update unit 510 can create an entry in the client database 508. Furthermore, when a client device is advertising, the client database update unit 510 can update the corresponding entry in the client database 508 based on the content of the advertising group.

[0042] The client database lookup unit 512 can be responsible for performing a lookup operation in the client database 508 in response to a service query message (e.g., an mDNS query). For example, the service query message can specify the type of service, and the client database lookup unit 512 can identify the client device providing the requested service. Furthermore, the client database lookup unit 512 can determine the device sharing policy associated with each identified client device (i.e., whether the client device is a private or public device). The device sharing policy enforcement unit 514 can be responsible for enforcing the device sharing policy. More specifically, if the service-providing device is a private device, the device sharing policy enforcement unit 514 can ensure that the service-providing device is only visible to client devices belonging to the same owner or one or more friends specified by the device sharing policy. For example, the device sharing policy enforcement unit 514 can generate an mDNS response message based on whether the requesting client device belongs to the same owner or a specified friend.

[0043] Figure 6 A flowchart illustrating an example of a device sharing process according to one aspect of this application is presented. During operation, the AP can receive a network access request including a first MPSK password from a first client device (operation 602). Note that the network is already configured with an MPSK Service Set Identifier (SSID), meaning that a single SSID can support multiple PSKs. Each user can obtain a user-specific MPSK password through a separate user authentication process. In addition to the user-specific MPSK password, each user can also be associated with a unique username that can be used to identify the user.

[0044] In response to a network access request, the AP can query a remote authentication server to verify the MPSK password and determine the owner of the first device (Operation 604). For example, the remote server could be a RADIUS server, and the AP can send a RADIUS request including the client device's MAC address and MPSK password. The RADIUS server can then search its user information database to verify the MPSK password and match the username with it. The username corresponds to the owner of the first device.

[0045] The AP can then receive advertising packets from the first device indicating services provided by the first device (operation 606). The advertising packet may be an mDNS advertisement with multiple resource records. The resource records may indicate one or more services provided by the first device. Upon receiving the advertising packet, the AP may forward information about the services and the owner to the device sharing server to obtain the device sharing policy associated with the owner (operation 608). Depending on some aspects, the AP may generate a protobuf message including the resource records of the mDNS advertisement and the username / role of the first device's owner. Based on the username, the device sharing server can determine the device sharing policy and return it to the AP, allowing the AP to enforce the device sharing policy.

[0046] The AP can receive mDNS queries from the second device (operation 610). Depending on some aspects, the mDNS query may specify one or more services requested by the second device. The AP can determine whether the second device belongs to the same owner as the first device (operation 612). The second device has previously used a second MPSK cipher to access the network, and the AP can match the username with the second MPSK cipher by looking up its client database. In one example, the mDNS query may also indicate the MAC address of the second device, and the AP can look up the entry corresponding to that MAC address in its client database. This entry may include the username of the owner of the second device. The entry may also include the network role of the username.

[0047] In response to determining that the second device belongs to the owner of the first device, the AP can send an mDNS query response to the second device, instructing the first device to provide the requested service (operation 614). A connection can then be established between the first and second devices to allow the second device to access the service provided by the first device (operation 616). Alternatively, if the AP determines that the second device belongs to a different owner, the AP can send an mDNS query response to the second device without instructing the first device in the query response (operation 618). Note that if the AP determines that the first device is a public device, or if the owner of the second device is a friend of the owner of the first device, the AP can include the first device in the mDNS query response to the second device even if the two devices belong to different owners.

[0048] Figure 7 An example of a computer system facilitating the management of device sharing according to one aspect of this application is illustrated. The computer system 700 may include a processor 702, a memory 704, and a storage device 706. Furthermore, the computer system 700 may be coupled to peripheral input / output (I / O) user equipment 710, such as a display device 712, a keyboard 714, and a pointing device 716. The storage device 706 may store an operating system 718, a device sharing management system 720, and data 740. According to some aspects, the computer system 700 may be implemented as a functional block included in the AP.

[0049] The device sharing management system 720 may include instructions that, when executed by the computer system 700, can cause the computer system 700 or processor 702 to perform the methods and / or processes described in this disclosure. Specifically, by executing these instructions, the computer system 700 can achieve the goal of managing the sharing of client devices without requiring manual registration. The device sharing management system 720 may include instructions for communicating with client devices (client device communication instructions 722), instructions for communicating with an authentication server to determine the username associated with the client device (authentication server communication instructions 724), instructions for communicating with a device sharing server to report device information and obtain device sharing policies (device sharing server communication instructions 726), instructions for updating the client database based on information received from the client devices, the authentication server, and the device sharing server (client database update instructions 728), instructions for performing a lookup operation in the client database (client database lookup instructions 730), and instructions for enforcing device sharing policies (device sharing policy enforcement instructions 732). Data 740 may include a client database 742.

[0050] Generally, this disclosure describes a system and method for enabling device sharing in large-scale networks without manual device registration and intensive record updates. More specifically, by configuring an MPSK SSID for the network, the system can link the password used by a client device to access the network with the identity of the corresponding device owner, enabling the system to automatically register the device each time it accesses the network and provides advertising services. Furthermore, by implementing a device sharing server that can populate information about client devices (e.g., the type of service provided by the client device) and corresponding device sharing policies among adjacent APs, the system allows each AP to enforce device sharing policies based on the ownership of the requesting and service-providing device. Frequent information exchange between the device sharing server and the authentication server for authenticated users is not required, thus significantly reducing bandwidth and computational power consumption.

[0051] One aspect may provide a system and method for device sharing. During operation, an access point (AP) may receive a network access request including a first multi-pre-shared key (MPSK) cipher and query an authentication server to determine the owner of a first device based on the first MPSK cipher. The AP may also receive advertising packets from the first device indicating services provided by the first device and forward information associated with the services and the owner to a device sharing server to obtain a device sharing policy associated with the owner. The AP enforces the device sharing policy, which may include receiving a multicast Domain Name System (mDNS) query from a second device, determining, in response to a second device belonging to the owner of the first device based on a second MPSK cipher of the second device, instructing the first device in an mDNS response corresponding to the mDNS query, and establishing a connection between the first device and the second device to allow the second device to access the services provided by the first device.

[0052] In a variant of this aspect, enforcing the device sharing policy may further include: in response to determining that the second device does not belong to the owner of the first device based on the second MPSK password of the second device, excluding the first device from the mDNS response corresponding to the mDNS query.

[0053] In a variant of this aspect, querying the authentication server may include forwarding the network access request to the authentication server that stores a mapping between the MPSK password and the username of the owner of the first device, and receiving a network access response from the authentication server that indicates the username and the network role associated with the username.

[0054] In another variant, the authentication server may include a Remote Authentication Dial-In User Service (RADIUS) server; the network access request may include a RADIUS request; and the network response may include a RADIUS response, wherein the username and the network role are included in a Vendor Specific Attribute (VSA) field of the RADIUS response.

[0055] In another variant, the device sharing policy may be determined by the device sharing server based on the username and the network role.

[0056] In another variant, in response to determining that the network role has administrative privileges, the AP can acquire a device sharing policy indicating that the first device is a public device, and allow any device to access the services provided by the first device.

[0057] In a variant of this aspect, the device sharing server may forward information associated with the services provided by the first device and the device sharing policy to one or more neighboring APs. The neighboring APs may respond to mDNS queries from a third device coupled to the neighboring AP based on the device sharing policy.

[0058] In a variant of this, the AP may maintain a client database that stores one or more of the following: the address of the first device, information about the owner of the first device, the services provided by the first device, and the device sharing policy.

[0059] In a variant of this aspect, the advertising group may include an mDNS advertising group with one or more resource records.

[0060] In another variant, forwarding the information associated with the service and the owner includes generating a protocol buffer (protobuf) message that encapsulates the resource record and the username associated with the owner.

[0061] The above description is provided to enable any person skilled in the art to make and use examples, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed examples will be apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations and applications without departing from the spirit and scope of this disclosure. Therefore, the scope of this disclosure is not limited to the examples shown, but should be given the widest scope consistent with the principles and features disclosed herein.

[0062] The methods and processes described in the detailed description section may be embodied in code and / or data, which may be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on the computer-readable storage medium, the computer system executes the methods and processes embodied in data structures and code and stored in the computer-readable storage medium.

[0063] Furthermore, the methods and processes described above may be included in hardware devices or apparatuses. Hardware devices or apparatuses may include, but are not limited to, application-specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software units or code at specific times, and other programmable logic devices now known or developed later. When hardware devices or apparatuses are activated, they execute the methods and processes included therein.

[0064] The examples described above are for illustrative and descriptive purposes only. They are not intended to be exhaustive or to limit the scope of this disclosure to the forms disclosed. Therefore, many modifications and variations will be apparent to those skilled in the art.

Claims

1. A method comprising: Receive a network access request at the access point (AP) including the first multiple pre-shared key (MPSK) cipher. The authentication server is queried to determine the owner of the first device based on the first MPSK password; The AP receives advertising packets from the first device indicating the services provided by the first device; The information associated with the service and the owner is forwarded to the device sharing server to obtain the device sharing policy associated with the owner; Enforcing the device sharing policy, including Receive multicast Domain Name System (mDNS) queries from the second device; In response to determining that the second device belongs to the owner of the first device based on the second MPSK password of the second device, the first device is indicated in the mDNS response corresponding to the mDNS query; as well as A connection is established between the first device and the second device to allow the second device to access the services provided by the first device.

2. The method according to claim 1, wherein enforcing the device sharing policy further comprises: In response to determining that the second device does not belong to the owner of the first device based on the second MPSK password of the second device, the first device is excluded from the mDNS response corresponding to the mDNS query.

3. The method according to claim 1, wherein querying the authentication server comprises: The network access request is forwarded to the authentication server that stores the mapping relationship between the MPSK password and the username of the owner of the first device; as well as Receive a network access response from the authentication server that indicates the username and the network role associated with the username.

4. The method according to claim 3, The authentication server mentioned above includes the Remote Authentication Dial-in User Service RADIUS server. The network access request mentioned above includes a RADIUS request; and The network response mentioned therein includes a RADIUS response, wherein the username and network role are included in the vendor-specific attribute VSA field of the RADIUS response.

5. The method according to claim 3, wherein the device sharing policy is determined by the device sharing server based on the username and the network role.

6. The method according to claim 5, further comprising: In response to determining that the network role has administrative privileges, a device sharing policy indicating that the first device is a public device is obtained; as well as Allow any device to access the service provided by the first device.

7. The method according to claim 1, further comprising: The device sharing server forwards information associated with the service provided by the first device and the device sharing policy to one or more neighboring APs; as well as The neighboring AP responds to mDNS queries from a third device coupled to the neighboring AP based on the device sharing policy.

8. The method of claim 1, further comprising maintaining a client database, the client database storing one or more of the following: The address of the first device; Information regarding the owner of the first device; The services provided by the first device; and The device sharing strategy.

9. The method of claim 1, wherein the advertising group comprises an mDNS advertising group having one or more resource records.

10. The method of claim 9, wherein forwarding the information associated with the service and the owner comprises generating a protocol buffer protobuf message encapsulating the resource record and the username associated with the owner.

11. A wireless access point (AP), comprising: processor; Memory, storing instructions that, when executed by the processor, cause the processor to execute a method, the method comprising: Receive a network access request including a first multiple pre-shared key (MPSK) cipher; The authentication server is queried to determine the owner of the first device based on the first MPSK password; Receive advertising packets from the first device that indicate services provided by the first device; The information associated with the service and the owner is forwarded to the device sharing server to obtain the device sharing policy associated with the owner; Enforcing the device sharing policy, including Receive multicast Domain Name System (mDNS) queries from the second device; In response to determining that the second device belongs to the owner of the first device based on the second device's second MPSK password, the first device is indicated in the mDNS response corresponding to the mDNS query; and A connection is established between the first device and the second device to allow the second device to access the services provided by the first device.

12. The AP of claim 11, wherein enforcing the device sharing policy further comprises: In response to determining that the second device does not belong to the owner of the first device based on the second MPSK password of the second device, the first device is excluded from the mDNS response corresponding to the mDNS query.

13. The AP of claim 10, wherein querying the authentication server comprises: The network access request is forwarded to the authentication server that stores the mapping relationship between the MPSK password and the username of the owner of the first device; as well as Receive a network access response from the authentication server that indicates the username and the network role associated with the username.

14. The AP according to claim 13, The authentication server mentioned above includes the Remote Authentication Dial-in User Service RADIUS server. The network access request mentioned above includes a RADIUS request; and The network response mentioned therein includes a RADIUS response, wherein the username and network role are included in the vendor-specific attribute VSA field of the RADIUS response.

15. The AP of claim 13, wherein the device sharing policy is determined by the device sharing server based on the username and the network role.

16. The AP of claim 15, wherein the method further comprises: In response to determining that the network role has administrative privileges, a device sharing policy indicating that the first device is a public device is obtained; as well as Allow any device to access the service provided by the first device.

17. The AP of claim 11, wherein the method further comprises: The device sharing server forwards information associated with the service provided by the first device and the device sharing policy to one or more neighboring APs; as well as The neighboring AP responds to mDNS queries from a third device coupled to the neighboring AP based on the device sharing policy.

18. The AP of claim 11, wherein the method further comprises maintaining a client database, the client database storing one or more of the following: The address of the first device; Information regarding the owner of the first device; The services provided by the first device; and The device sharing strategy.

19. The AP of claim 11, wherein the advertising packet includes an mDNS advertising packet having one or more resource records.

20. The AP of claim 19, wherein forwarding the information associated with the service and the owner includes generating a protocol buffer protobuf message encapsulating the resource record and the username associated with the owner.

Images