Re: Certificate Expiration and IoT (Door Locks)

2016-11-02 Thread Curtis K. Larsen
We crossed this bridge already but the quantity of door locks was a lot lower.  
We issued 5 yr certs to the locks and told the dept. that they (or their 
vendor) need to update/patch firmware on devices at least that often so they 
can update the cert at the same time.  Our server cert will expire before then 
(not part of the chain) but the CA cert (part of the chain) will be valid for 
at least 10 years beyond that.  So, as long as the FQDN and CN remain the same 
for the server cert then there is no problem.  We used our existing 1x SSID, 
but a different VLAN and associated security policy.  We used Cloudpath and 
deployed EAP-TLS certs for these - it's not hard.

--
Curtis K. Larsen
Senior Network Engineer
University of Utah IT/CIS


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Johnson, Neil M 

Sent: Wednesday, November 2, 2016 9:17 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Certificate Expiration and IoT (Door Locks)

Our housing department is pushing pretty hard to replace keyed locks on dorm 
room doors with Wi-Fi connected proximity card locks (a pilot this summer and 
then eventually rolling out to ~3,000 rooms).

The locks would be “offline” locks that cache valid cards locally and only 
connect to the Wi-Fi network periodically for updates and when presented with a 
non-cached card.

While the locks support multiple methods for authenticating to the wireless 
network (everything from a PSK to PEAP/MSCHAPv2 to EAP-TLS), I think EAP-TLS is 
probably the most secure method for these devices.

My thinking is to setup a private PKI and generate a client cert for every 
lock. However, I have two issues concerning EAP-TLS.


1.   What should I use for a client certificate expiration date?
Our key and access folks don’t want to update the locks client certs very 
often. (They will have to touch each lock on a regular basis to replace 
batteries, but don’t want to have to connect a computer to the locks every 
year).
The same question applies for the server certificate expiration.


2.   Should I advertise a separate SSID?
We currently use eduroam as our primary campus SSID.  I would prefer not to 
have to add an additional SSID just for these devices, but their use case seems 
different enough to warrant one.

If your institution has implemented or thinking about implementing Wi-Fi 
connected locks, I’d appreciate your feedback.

Thanks.
-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319-384-0938
e-mail: neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu>


** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.


Re: [WIRELESS-LAN] Certificate Expiration and IoT (Door Locks)

2016-11-02 Thread Johnson, Neil M
Chris,

Thanks for the feedback. What is your expiration time on our RADIUS Server 
certificate?

-Neil

-- 
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
E-Mail: neil-john...@uiowa.edu



> On Nov 2, 2016, at 10:53 AM, Chris Hart  wrote:
> 
> Neil  - we rolled out these locks to 3 Res Halls this past summer.   We have 
> them on the eduroam SSID connecting via PEAP/MSCHAPv2  with a local account 
> on our ClearPass server.   We have an enforcement policy that assigns this 
> user account a VLAN ID that is private IP space that is restricted to only be 
> able to communicate with the Lock system database server.   We only had 1 
> complaint that we had to troubleshoot but it was found that a bunch of the 
> lock were not configured to do their nightly check in for updates.  The locks 
> can also be set to check for an update upon a failure of proximity card.  So 
> if a student is issued a new card and tries to enter their room it will fail, 
> the lock will check for an update and then on the next attempt the student 
> should then have access.   We used Assaa Abloyas our vendor.
>  
>  
> Chris
>  
>  
>  
> 
> Chris Hart
> Senior Network Engineer
>  
>  
> 
>  
>  
>  
> From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Johnson, Neil M
> Sent: Wednesday, November 2, 2016 10:18 AM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: [WIRELESS-LAN] Certificate Expiration and IoT (Door Locks)
>  
>  
> Our housing department is pushing pretty hard to replace keyed locks on dorm 
> room doors with Wi-Fi connected proximity card locks (a pilot this summer and 
> then eventually rolling out to ~3,000 rooms).
>  
> The locks would be “offline” locks that cache valid cards locally and only 
> connect to the Wi-Fi network periodically for updates and when presented with 
> a non-cached card.
>  
> While the locks support multiple methods for authenticating to the wireless 
> network (everything from a PSK to PEAP/MSCHAPv2 to EAP-TLS), I think EAP-TLS 
> is probably the most secure method for these devices.
>  
> My thinking is to setup a private PKI and generate a client cert for every 
> lock. However, I have two issues concerning EAP-TLS.
>  
> 1.   What should I use for a client certificate expiration date?
> Our key and access folks don’t want to update the locks client certs very 
> often. (They will have to touch each lock on a regular basis to replace 
> batteries, but don’t want to have to connect a computer to the locks every 
> year).
> The same question applies for the server certificate expiration. 
> 
> 2.   Should I advertise a separate SSID?
> We currently use eduroam as our primary campus SSID.  I would prefer not to 
> have to add an additional SSID just for these devices, but their use case 
> seems different enough to warrant one.
>  
> If your institution has implemented or thinking about implementing Wi-Fi 
> connected locks, I’d appreciate your feedback.
>  
> Thanks.
> -Neil
>  
> -- 
> Neil Johnson
> Network Engineer
> The University of Iowa
> Phone: 319-384-0938
> e-mail: neil-john...@uiowa.edu
>  
>  
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found at 
> http://www.educause.edu/groups/. 
> ** Participation and subscription information for this EDUCAUSE 
> Constituent Group discussion list can be found at 
> http://www.educause.edu/groups/.
> 


**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.



RE: Certificate Expiration and IoT (Door Locks)

2016-11-02 Thread Chris Hart
Neil  - we rolled out these locks to 3 Res Halls this past summer.   We have 
them on the eduroam SSID connecting via PEAP/MSCHAPv2  with a local account on 
our ClearPass server.   We have an enforcement policy that assigns this user 
account a VLAN ID that is private IP space that is restricted to only be able 
to communicate with the Lock system database server.   We only had 1 complaint 
that we had to troubleshoot but it was found that a bunch of the lock were not 
configured to do their nightly check in for updates.  The locks can also be set 
to check for an update upon a failure of proximity card.  So if a student is 
issued a new card and tries to enter their room it will fail, the lock will 
check for an update and then on the next attempt the student should then have 
access.   We used Assaa Abloy as our vendor.


Chris



[cid:image005.png@01D14944.D438EFC0]

Chris Hart
Senior Network Engineer







From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Johnson, Neil M
Sent: Wednesday, November 2, 2016 10:18 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [WIRELESS-LAN] Certificate Expiration and IoT (Door Locks)


Our housing department is pushing pretty hard to replace keyed locks on dorm 
room doors with Wi-Fi connected proximity card locks (a pilot this summer and 
then eventually rolling out to ~3,000 rooms).

The locks would be “offline” locks that cache valid cards locally and only 
connect to the Wi-Fi network periodically for updates and when presented with a 
non-cached card.

While the locks support multiple methods for authenticating to the wireless 
network (everything from a PSK to PEAP/MSCHAPv2 to EAP-TLS), I think EAP-TLS is 
probably the most secure method for these devices.

My thinking is to setup a private PKI and generate a client cert for every 
lock. However, I have two issues concerning EAP-TLS.


1.   What should I use for a client certificate expiration date?
Our key and access folks don’t want to update the locks client certs very 
often. (They will have to touch each lock on a regular basis to replace 
batteries, but don’t want to have to connect a computer to the locks every 
year).
The same question applies for the server certificate expiration.

2.   Should I advertise a separate SSID?
We currently use eduroam as our primary campus SSID.  I would prefer not to 
have to add an additional SSID just for these devices, but their use case seems 
different enough to warrant one.

If your institution has implemented or thinking about implementing Wi-Fi 
connected locks, I’d appreciate your feedback.

Thanks.
-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319-384-0938
e-mail: neil-john...@uiowa.edu<mailto:neil-john...@uiowa.edu>


** Participation and subscription information for this EDUCAUSE 
Constituent Group discussion list can be found at 
http://www.educause.edu/groups/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.educause.edu_groups_&d=CwMGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=CYuLo9E3nFauO_1q7Vz54s0evFy-qRGi6zN4VOktgIw&m=jQN_IkDWmkvRcvH-7FVl2Phvn-yhMGWEx3BuUp1QSbw&s=wqfOHLfpg1wKrXpXJCoL6Dx_jsG8pol4X6a3pySq-xY&e=>.

**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.



Certificate Expiration and IoT (Door Locks)

2016-11-02 Thread Johnson, Neil M

Our housing department is pushing pretty hard to replace keyed locks on dorm 
room doors with Wi-Fi connected proximity card locks (a pilot this summer and 
then eventually rolling out to ~3,000 rooms).

The locks would be “offline” locks that cache valid cards locally and only 
connect to the Wi-Fi network periodically for updates and when presented with a 
non-cached card.

While the locks support multiple methods for authenticating to the wireless 
network (everything from a PSK to PEAP/MSCHAPv2 to EAP-TLS), I think EAP-TLS is 
probably the most secure method for these devices.

My thinking is to setup a private PKI and generate a client cert for every 
lock. However, I have two issues concerning EAP-TLS.


1.   What should I use for a client certificate expiration date?
Our key and access folks don’t want to update the locks client certs very 
often. (They will have to touch each lock on a regular basis to replace 
batteries, but don’t want to have to connect a computer to the locks every 
year).
The same question applies for the server certificate expiration.


2.   Should I advertise a separate SSID?
We currently use eduroam as our primary campus SSID.  I would prefer not to 
have to add an additional SSID just for these devices, but their use case seems 
different enough to warrant one.

If your institution has implemented or thinking about implementing Wi-Fi 
connected locks, I’d appreciate your feedback.

Thanks.
-Neil

--
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319-384-0938
e-mail: neil-john...@uiowa.edu



**
Participation and subscription information for this EDUCAUSE Constituent Group 
discussion list can be found at http://www.educause.edu/groups/.