Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[James Andrewartha]

The maximum for a public certificate is changing on 1 March 2018 to 27
months, with suggestions that it might drop down to 13 months later on:

https://www.digicert.com/shortening-validity-periods-for-ov-dv-certificates/
https://www.digicert.com/blog/cabforum-votes-shorten-certificate-lifetime-validity-periods-impacts/

One distinction about using a private CA is that you can have an
extremely long root CA, and then have shorter lived certificates signed
by that CA that are rotated. However, without onboarding to install the
CA for the SSID vs just trusting the certificate (which I know is what
macOS and iOS do) then it's not much of a distinction in practice. This
also means I have the same certificate installed on all RADIUS servers.

On EAP-TLS, we briefly tried enabling Windows Credential Guard last week
on a few IT laptops, and immediately had to turn it off as it breaks
MSCHAPv2 authentication:
https://docs.microsoft.com/en-us/windows/access-protection/credential-guard/credential-guard-considerations

I had a meeting with Microsoft yesterday and they said that certificate
auth is really the only secure answer. Since our devices are owned by
the school, we'll probably look at setting up a private Windows CA first
rather than going down the CloudPath or SecureW2 path.

On 31/10/17 12:46, Craig Simons 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
>  University Dr., Burnaby, B.C. V5A 1S6
> T: 778.782.8036 | M: 604.649.7977
> 
>       
> SFU   SIMON FRASER UNIVERSITY
> IT SERVICES
> 
> 
>> On Oct 30, 2017, at 1:19 PM, Mike Atkins > > 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
>>
>>  
>>
>>  
>>
>>    .__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 

Re: Radius certificate length vs. onboarding opinions

[Richard Nedwich]

Hi Craig,

I'm not sure if anyone from Cloudpath already advised you, but I did forward 
your question to Kevin Koster, Cloudpath Founder and Chief Architect, for his 
opinion of the pros/cons of these options.  I thought I would share them, in 
case this forum found it useful.

Best,
Rich
-=-=-=-=-=-=-=

Option 1: Using a self-signed/private PKI and a 10 year cert. Onboard with 
"verify server certificate" enabled
Pros:  You control the issuing CA, so you control if/when you change the 
issuing CA.  Client will validate the RADIUS server certificate, thereby 
protecting the user’s password and prevent device from connecting to 
man-in-the-middle.  
Cons:  Need to generate the private CA (ie need CA tool or openssl skills).  
Need to install private CA on end-user devices (ie need onboarding tool).  
 
Option 2: Removing all traces of “verify server certificate” from OnBoard 
configuration and use 2-year certs from CAs
Pros:  “It just works.”
Cons.  This disables all security built into WPA2-Enterprise.  Device will give 
the password to any network, real or fake.  Device will join evil twins.  
Commentary:  With validation disabled, credentials are so at-risk that the 
network’s attempt to authenticate wifi users becomes moot.  If you use this 
model, you would do less damage to your end-users by using PSK (or even better, 
Dynamic PSK) or having everyone use a static password (like “password”).  

Option 3: Use 2-year CA certificates, enable “verify server certificates” and 
educate/prepare every two years for connection issues.
Commentary:  This is essentially “use a public CA and be prepared to deal with 
issues when issuer chain changes”.  This normally occurs when protocols become 
obsolete (1024 to 2048, SHA-1 to SHA-2, etc), but can potentially occur 
anytime.  For 802.1X, these changes are impactful to (properly configured) 
end-users.  Unfortunately, most revenue for public CAs is from web server 
certificates (which are not affected by issuing CA changes), so they don’t 
always see chain changes as something to be avoided.  
Pros:  Like #1, credentials are protected.
Cons:  Requires client configuration.  If CA changes its chain, the network 
will break for the device.  
Work-Around:  The impact of this can be reduced by buying 2-year certificates 
every 12 months.  Then, if the chain does change, you have a 12 month window to 
transition.  This doesn’t change the need to transition, but it does provide a 
window to make life easier.  

Option 4 (probably the best long-term answer): Move to private PKI and EAP-TLS.
Commentary:  While EAP-TLS has benefits beyond this particular issue, EAP-TLS 
does not change this particular issue.  The following scenarios with EAP-TLS 
would map to 1-3 above:  
- Using EAP-TLS with a RADIUS cert from private CA would be similar to #1.  
- Using EAP-TLS with a RADIUS cert from public CA would be similar to #3.  
- Using EAP-TLS with server cert validation disabled would be similar to #2 
(user would be still exposed to connecting to evil twins but the cleartext 
password wouldn’t be leaked).

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

Re: [WIRELESS-LAN] Radius certificate length vs. onboarding opinions

[Walter Reynolds]

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  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
>  University Dr., Burnaby, B.C. V5A 1S6
> 
> 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  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
>  University Dr., Burnaby, B.C. V5A 1S6
> 
> T: 778.782.8036 <(778)%20782-8036> | M: 604.649.7977 <(604)%20649-7977> |
> 

Re: [WIRELESS-LAN] IOS 11 problem with eap-mschapv2/peap authentication

[Becker, Jason]

We are seeing the same issue here on our Cisco deployment.  I've been telling 
users to reboot or forget it and reconnect unfortunately.  After this they've 
been good, but  I see your point with several certs.



Jason


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Cappalli, Tim (Aruba 
Security) 
Sent: Tuesday, October 31, 2017 9:33:35 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] IOS 11 problem with eap-mschapv2/peap authentication

Just curious. Why aren't you using the same EAP server certificate across all 
of your RADIUS servers?


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Linchuan Yang 

Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 

Date: Tuesday, October 31, 2017 at 10:28 AM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: [WIRELESS-LAN] IOS 11 problem with eap-mschapv2/peap authentication

Dear All

Good morning. All of our IOS users start having authentication problem after 
they upgrading to IOS 11. The devices keep asking the user name and password. 
The only way we can fix for now is that “forget” the old profile, and manually 
create a new one, after trusting the certificate, the IOS 11 devices can 
connect to the wireless network. However, we have more than three radius 
servers, if the clients go to other buildings, they have to do this again. In 
some case, the clients have to repeat the procedure every morning when they 
come back to the office.

We noticed that some related discussion on Cisco and Apple Communities. But 
there is not any solution for it. Do you have the same problem for your 
wireless network? Could you please give us some suggestions?

​Thank you, and have a nice day.

Yours,
Linchuan Yang (Antony)
MEng, ACMP
Wireless Networking Analyst
Network Assessment and Integration,
IITS-Concordia University
Tel: (514)848-2424 ext. 7664

** 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.


The materials in this message are private and may contain Protected Healthcare 
Information or other information of a sensitive nature. If you are not the 
intended recipient, be advised that any unauthorized use, disclosure, copying 
or the taking of any action in reliance on the contents of this information is 
strictly prohibited. If you have received this email in error, please 
immediately notify the sender via telephone or return mail.

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

Re: [WIRELESS-LAN] IOS 11 problem with eap-mschapv2/peap authentication

[Cappalli, Tim (Aruba Security)]

Just curious. Why aren't you using the same EAP server certificate across all 
of your RADIUS servers?


From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
 on behalf of Linchuan Yang 

Reply-To: The EDUCAUSE Wireless Issues Constituent Group Listserv 

Date: Tuesday, October 31, 2017 at 10:28 AM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: [WIRELESS-LAN] IOS 11 problem with eap-mschapv2/peap authentication

Dear All

Good morning. All of our IOS users start having authentication problem after 
they upgrading to IOS 11. The devices keep asking the user name and password. 
The only way we can fix for now is that “forget” the old profile, and manually 
create a new one, after trusting the certificate, the IOS 11 devices can 
connect to the wireless network. However, we have more than three radius 
servers, if the clients go to other buildings, they have to do this again. In 
some case, the clients have to repeat the procedure every morning when they 
come back to the office.

We noticed that some related discussion on Cisco and Apple Communities. But 
there is not any solution for it. Do you have the same problem for your 
wireless network? Could you please give us some suggestions?

​Thank you, and have a nice day.

Yours,
Linchuan Yang (Antony)
MEng, ACMP
Wireless Networking Analyst
Network Assessment and Integration,
IITS-Concordia University
Tel: (514)848-2424 ext. 7664

** 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.

IOS 11 problem with eap-mschapv2/peap authentication

[Linchuan Yang]

Dear All

Good morning. All of our IOS users start having authentication problem after 
they upgrading to IOS 11. The devices keep asking the user name and password. 
The only way we can fix for now is that “forget” the old profile, and manually 
create a new one, after trusting the certificate, the IOS 11 devices can 
connect to the wireless network. However, we have more than three radius 
servers, if the clients go to other buildings, they have to do this again. In 
some case, the clients have to repeat the procedure every morning when they 
come back to the office.

We noticed that some related discussion on Cisco and Apple Communities. But 
there is not any solution for it. Do you have the same problem for your 
wireless network? Could you please give us some suggestions?

​Thank you, and have a nice day.

Yours,
Linchuan Yang (Antony)
MEng, ACMP
Wireless Networking Analyst
Network Assessment and Integration,
IITS-Concordia University
Tel: (514)848-2424 ext. 7664


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

RE: Radius certificate length vs. onboarding opinions

[Osborne, Bruce W (Network Operations)]

We currently use Option 3, but the clients only trust the certificate CHAIN, 
not the server certificate itself. This lets us replace the server certificate 
providing the chain remains the same. This worked fine for us for several years 
with a 1 year server certificate. Unfortunately, we have changed chains twice 
in the past year and will likely change chains again in January. ☹ Some of the 
clients we onboarded at the start of this semester have our “best guess” for 
the new certificate chain too.

We will be moving some clients to Option 4, though.


Bruce Osborne
Senior Network Engineer
Network Operations - Wireless
 (434) 592-4229
LIBERTY UNIVERSITY
Training Champions for Christ since 1971

From: Craig Simons [mailto:craigsim...@sfu.ca]
Sent: Monday, October 30, 2017 2:22 PM
Subject: 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
 University Dr., Burnaby, B.C. V5A 1S6
T: 778.782.8036 | M: 604.649.7977 | 
www.sfu.ca/itservices

[http://www.sfu.ca/content/dam/sfu/creative-studio/images/email/sfu-horizontal.png]

** 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.

RE: [WIRELESS-LAN] Big flaw in WPA2

[Chris Toth]

Has anyone implemented this workaround and heard any negative feedback 
regarding wireless quality?  It seems changing the retries down to 0 would 
result in more dropped sessions and the appearance of a flakier network and 
possibly triggering more client exclusions?

Chris Toth
Senior Network Technician
Bowling Green State University
(419) 372-8462

From: The EDUCAUSE Wireless Issues Constituent Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Scharloo, Gertjan
Sent: Friday, October 27, 2017 6:06 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] Big flaw in WPA2

SMALL Update about Cisco Client workaround:


  *   Troubleshooting 
TechNotes

Wireless KRACK attack client side workaround and detection

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/212390-wireless-krack-attack-client-side-workar.html

Regards,

Gertjan Scharloo
ICT Consultant
_

Universiteit van Amsterdam | Hogeschool van Amsterdam

ICT Services
Leeuwenburg | kamer A9.44
Weesperzijde 190 | 1097 DZ Amsterdam
+31 (0)20 525 4885
Mobiel : +31(0) 61013-5880
www.uva.nl
uva.nl/profile/g.scharloo
Beschikbaar : Ma | - | Wo | Do | Vr |


From: wireless-lan 
> 
on behalf of Gertjan Scharloo >
Reply-To: wireless-lan 
>
Date: Friday, 27 October 2017 at 09:49
To: wireless-lan 
>
Subject: Re: [WIRELESS-LAN] Big flaw in WPA2

Hi folks,

In a Cisco environment there is a workaround for the client vulnerability :

Workaround for CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080 
and CVE-2017-13081
Please read : 
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpa#workarounds

And read https://twitter.com/vanhoefm/status/923651649595478018

Workaround is very simple (!) :

Global Config, (CLI only option)

config advanced eap eapol-key-retries 0



(5520) >show advanced eap
EAP-Identity-Request Timeout (seconds)……….. 30
EAP-Identity-Request Max Retries….. 2
EAP Key-Index for Dynamic WEP…….. 0
EAP Max-Login Ignore Identity Response……….. enable
EAP-Request Timeout (seconds)…….. 30
EAP-Request Max Retries.. 2
EAPOL-Key Timeout (milliseconds)….. 1000
EAPOL-Key Max Retries…. 0
EAP-Broadcast Key Interval……….. 3600


Regards,

Gertjan Scharloo
ICT Consultant
_

Universiteit van Amsterdam | Hogeschool van Amsterdam

ICT Services
Leeuwenburg | kamer A9.44
Weesperzijde 190 | 1097 DZ Amsterdam
+31 (0)20 525 4885
Mobiel : +31(0) 61013-5880
www.uva.nl
uva.nl/profile/g.scharloo
twitter : wireless_kid
Beschikbaar : Ma | - | Wo | Do | Vr |


From: wireless-lan 
> 
on behalf of Jake Snyder >
Reply-To: wireless-lan 
>
Date: Thursday, 19 October 2017 at 15:24
To: wireless-lan 
>
Subject: Re: [WIRELESS-LAN] Big flaw in WPA2

You have more faith in the WFA than I.  I’m sure our next houses will be Wi-Fi 
certified Krack-Free.
Sent from my iPhone

On Oct 19, 2017, at 5:13 AM, Osborne, Bruce W (Network Operations) 
> wrote:
The specification, like many, was vague in implementation details and 
practically all vendors chose a poor, insecure design.  The only claw in WPA2 
was vagueness in the specification. I understand the Wi-Fi Alliance is working 
on remedying that as well as specifically testing for KRACK in its 
certification testing.

Since many implementations were likely based off the chipmakers reference 
designs, this is not very surprising.


Bruce Osborne
Senior Network Engineer
Network Operations - Wireless
 (434) 592-4229
LIBERTY UNIVERSITY
Training Champions for Christ since 1971

From: Marcelo Maraboli [mailto:marcelo.marab...@uc.cl]
Sent: Wednesday, October 18, 2017 11:56 AM
Subject: Re: Big flaw in WPA2

if it were a Design Flaw, no patch can fix it we would need to upgrade to 
WPA3 or something.

the fact that there is patch going on, is that either every implementation is 
wrong (not likely) or
the specification (how to code the Design) did not address boundaries or 
restrictions that should/must
be cared for.

or am I wrong ?


regards,
On 10/16/17 4:32 PM, Hector J Rios wrote:
The short answer is Yes.

Hector Rios
Louisiana State University

From: The EDUCAUSE Wireless Issues Constituent Group Listserv