Commit 68c3845ac94803908116fa63b50a02fe2190a85a

Authored by Jinghao Shi
1 parent 1a2c8d62

fix credential

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