We use SecureW2 JoinNow and the actually recommend option 2.  Still the
security vs. simplicity for users.

We are using option 3 and the last change in certificate we had overall
went pretty well.  We did try hard to get some media out there to notify
users as well as worked with the help desk and unit IT support.  Yes there
were still issues but it was not as bad as I was fearing.

Though to be honest I think most people either just accepted the pop up to
trust the new cert if they got it or removed their settings and started
from scratch (again getting a pop up).  The majority of the users are
students and they have pretty much grown up with Wi-Fi and are not afraid
of it.


------------------------
Walter Reynolds
Principal Systems Security Development Engineer
Information and Technology Services
University of Michigan
(734) 615-9438

On Tue, Oct 31, 2017 at 12:46 AM, Craig Simons <craigsim...@sfu.ca> wrote:

> These are very helpful and thoughtful points to consider. I think of this
> issue using the angel and devil on the shoulder analogy. On one shoulder,
> as a security conscious engineer (and technophile) I see why shorter
> certificates (I believe the maximum is 39 months now?) with all allowances
> made for security are the necessary evil. On the other, we want the campus
> WiFi experience to be easy, simple and as painless for the user (and
> Service Desk people) as possible. In many ways, a good onboarding tool lets
> you have your cake and eat it too... but our recent experience has shown us
> that even this has it’s limits.
>
> I suppose the “correct” answer is the one that is supportable. This
> requires the Service Desk/Desktop Support people to be willing and able to
> handle the hordes when they arrive in the interests of security “tough
> love”.
>
> However, I still believe there is a large role to play for EAP-TLS in the
> future. In the IoT world, the willingness of users to put their personal
> credentials on low-end devices is a security threat before even getting to
> the certificate conversation.
>
> Thanks to all that replied!
>
> *Craig Simons*
> Network Operations Manager
>
> Simon Fraser University | Strand Hall
> 8888 University Dr., Burnaby, B.C. V5A 1S6
> <https://maps.google.com/?q=8888+University+Dr.,+Burnaby,+B.C.+V5A+1S6&entry=gmail&source=g>
> T: 778.782.8036 <(778)%20782-8036> | M: 604.649.7977 <(604)%20649-7977>
>
>
> SFU SIMON FRASER UNIVERSITY
> IT SERVICES
>
> On Oct 30, 2017, at 1:19 PM, Mike Atkins <matk...@nd.edu> wrote:
>
> We are option 3 with 3 year certs.  We were in the same boat as Craig just
> over a year ago.  We moved to a different onboarding utility and different
> CA.  It is a long story so feel free to hit me up offline.  That said, in
> the future we will likely end up using both options 3 & 4 to be flexible
> with device/owner/use.
>
>
>
>
>
>
> *Mike Atkins *
> Network Engineer
> Office of Information Technology
> University of Notre Dame
> Phone: 574-631-7210 <(574)%20631-7210>
>
>
>
>
>      ----  .__o
>    ----- _-\_<,
>    ---  (*)/'(*)
>
>
> *From:* The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] *On Behalf Of *Craig Simons
> *Sent:* Monday, October 30, 2017 2:22 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN] Radius certificate length vs. onboarding
> opinions
>
>
> All,
>
>
> I know the subject has been broached on the list a few times before, but
> I’m looking for informal opinions/survey about how you are deploying your
> Radius EAP certificates for PEAP/TTLS users (non-TLS). We use Cloudpath to
> onboard users, but recently went through a difficult renewal period to
> replace our expiring certificate. As we had configured all of our clients
> to “verify the server certificate” (as you should from a security
> perspective), we found that iOS/MacOS and Android clients did not take
> kindly to a new certificate being presented. This resulted in quite a few
> disgruntled users who couldn’t connect to WiFi as well as a shell-shocked
> Service Desk. To help prevent this in the future (and because we are moving
> to a new Radius infrastructure), what is the consensus on the following
> strategies:
>
>
> Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with
> "verify server certificate" enabled
>
>
> Option 2: Removing all traces of “verify server certificate” from OnBoard
> configuration and use 2-year certs from CAs
>
>
> Option 3: Use 2-year CA certificates, enable “verify server certificates”
> and educate/prepare every two years for connection issues.
>
>
> Option 4 (probably the best long-term answer): Move to private PKI and
> EAP-TLS.
>
>
> Opinions?
>
>
> *Craig Simons*
> Network Operations Manager
>
> Simon Fraser University | Strand Hall
> 8888 University Dr., Burnaby, B.C. V5A 1S6
> <https://maps.google.com/?q=8888+University+Dr.,+Burnaby,+B.C.+V5A+1S6&entry=gmail&source=g>
> T: 778.782.8036 <(778)%20782-8036> | M: 604.649.7977 <(604)%20649-7977> |
> www.sfu.ca/itservices
>
>
> ********** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
> ********** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
>
>
> ********** Participation and subscription information for this EDUCAUSE
> Constituent Group discussion list can be found at http://www.educause.edu/
> discuss.
>
>

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

Reply via email to