blue / papers.hotwireless2015-sharing · Commits

Commit 68c3845ac94803908116fa63b50a02fe2190a85a

Authored by Jinghao Shi
1 parent 1a2c8d62

fix credential

Inline Side-by-side
Showing 1 changed file with 6 additions and 6 deletions
design.tex
  View file @68c3845
... ... @@ -53,7 +53,7 @@ hardware, and different network parameters, such as SSID, bandwidth cap, access
53 53 permission, can be enforced separately for each virtual network. This feature is
54 54 typically used to set up a guest \wifi{} network to provide network access to
55 55 temporal visitors yet isolate them from home clients. For home APs with such
56   -feature, \wifi{} sharing can be achieved by only distributing the credential of
  56 +feature, \wifi{} sharing can be achieved by only distributing the credentials of
57 57 guest network to other \wisefi{} users. Access and bandwidth policies can then
58 58 be enforced on the guest network to achieve control and protection.
59 59 Additionally, such isolation and enforcements are most likely already enabled
... ... @@ -63,17 +63,17 @@ by default for guest networks, so that even inexperienced user can configure the
63 63 For APs without guest network feature, however, cumbersome AP configurations may
64 64 be required by user, such as MAC black or white list, routing table
65 65 modification, etc. Such configurations are most likely too complicated for
66   -average users to perform. However, simply sharing the \wifi{} credential of user's
  66 +average users to perform. However, simply sharing the \wifi{} credentials of user's
67 67 home AP to other \wisefi{} users is not only dangerous, but also making it
68 68 difficult to revoke the access in the future. In the worst case scenario, a user may
69   -be forced to change the home AP password and reconfigure the \wifi{} credential
  69 +be forced to change the home AP password and reconfigure the \wifi{} credentials
70 70 on all his/her devices just to revoke the access of the other \wisefi{} user.
71 71 Although most commodity APs support client MAC black or white list feature,
72 72 configuring them properly is difficult for average users. Furthermore, the
73 73 sharing relationship should be built between users instead of devices: once the
74 74 sharing is established, one user should be able to connect any of his/her
75 75 devices, not only the smartphone, to the other user's home AP. Even if the system
76   -can directly share each other's \wifi{} credential, manually configuring it on
  76 +can directly share each other's \wifi{} credentials, manually configuring it on
77 77 all devices is still tedious.
78 78  
79 79 To overcome this challenge, we propose a dynamic \wifi{} AP configuration API
... ... @@ -110,8 +110,8 @@ perform another \texttt{setWhiteList} request to revoke Bob's access to Alice's
110 110 home AP by removing the MAC addresses of Bob's devices from the white list.
111 111  
112 112 There are several advantages of this sharing approach. First, note that
113   -throughout the grant and revoke process, the \wifi{} credential of Alice's home
114   -AP is not shared with Bob or the \wisefi{} server, thus remains confidential.
  113 +throughout the grant and revoke process, the \wifi{} credentials of Alice's home
  114 +AP are not shared with Bob or the \wisefi{} server, thus remain confidential.
115 115 Second, revoking access of other \wisefi{} users simply requires a
116 116 \texttt{setWhiteList} request, without needing to change the user's home AP
117 117 password. Furthermore, the \wisefi{} app can list other \wisefi{}
... ...