Subject: ESSID ietf-v6only at IETF 100

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 07:03:12 +0100

Hi,

I have problems connecting to the IPv6-only ESSID "ietf-v6only".

It is a problem of certificates.

I have this problem on Windows since several IETF meetings; it may not 
be related in particular to IPv6.

The message in the window below says: "The server 
services.meeting.ietf.org presented a certifcate valid emitted by 
Starfield CA, but that is not configured as a valid anchor to approve 
this profile".

I dont thave this kind of certification refusal problem on 
ietf-legacy100 ESSID (and all earlier ietf-legacy), neither on 
ietf-nat64-unencrypted.

This ietf-nat64-unencrypted is now appearing first time at IETF.  I 
suppose people realized there was a problem with certs and created an 
'unencrypted' version.  That's not a best practice to fix security :-)

And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.

Alex

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Nov 2017 14:08:41 +0800

Hi Alex,
  This has nothing to do with IPv6. You will have the same certificate issue with the ietf SSID. 

Thanks
Suresh

> On Nov 14, 2017, at 2:03 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Hi,
> 
> I have this problem on Windows since several IETF meetings; it may not be related in particular to IPv6.
> 
> The message in the window below says: "The server services.meeting.ietf.org presented a certifcate valid emitted by Starfield CA, but that is not configured as a valid anchor to approve this profile".
> 
> I dont thave this kind of certification refusal problem on ietf-legacy100 ESSID (and all earlier ietf-legacy), neither on ietf-nat64-unencrypted.
> 
> This ietf-nat64-unencrypted is now appearing first time at IETF.  I suppose people realized there was a problem with certs and created an 'unencrypted' version.  That's not a best practice to fix security :-)
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Nov 2017 14:24:10 +0800

On Tue, Nov 14, 2017 at 2:03 PM, Alexandre Petrescu <
[email-masked]> wrote:

> Starfield CA, but that is not configured as a valid anchor to approve this
> profile".
>
> I dont thave this kind of certification refusal problem on ietf-legacy100
> ESSID (and all earlier ietf-legacy), neither on ietf-nat64-unencrypted.
>

​That's because the legacy (and unencrypted) SSIDs are unencrypted and you
don't need to talk to a RADIUS server (which presents the certificate)

> 'unencrypted' version.  That's not a best practice to fix security :-)

​Nope. We have the legacy SSIDs because some people apparently had issues
connecting to encrypted SSIDs (because of old OS / broken wpa_supplicant,
etc) - this wasn't issue with certs, but rather providing a solution for
those who are unable to do WPA enterprise / have old cards, etc.
 There was an assertion made that some people were not using nat64 and were
using ietf-legacy were easier, and so there should be parity, and so the
ietf-nat64-unencrypted was created.
We are changing the name of the ietf-legacyXXX network at each meeting
because we don't people who connected to it at a previous meeting to become
sticky to it and keep joining -- it requires a specific action at each
meeting for the user to choose the unencrypted network -- we'd all prefer
that people use the encrypted network...

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 07:59:07 +0100

Le 14/11/2017 à 07:24, Warren Kumari a écrit :
[...]

> ​Nope. We have the legacy SSIDs because some people apparently had 
> issues connecting to encrypted SSIDs (because of old OS / broken 
> wpa_supplicant, etc) - this wasn't issue with certs, but rather 
> providing a solution for those who are unable to do WPA enterprise / 
> have old cards, etc.

Well - sorry, but all these reasons seem light for me.

I have Windows 7 which is not old.  Updated regularly from Microsoft and 
from employer IT.

The WPA_supplicant comes from original.  It is widely accepted at many 
other hotspots.

My laptop is very well able to do WPA enterprise, and WPA2 Enterprise.

The laptop is a Dell E7440, 2 or 3 years old.  I dont accept to call 
that old.  What makes laptops old is when they break; they often break 
because of mechanically moving parts like hd, but this one is SSD.

Rather, I suspect there is a preference at the Access Point to favorise 
Macintosh variations of WiFi Clients, rather than Windows.

I also wonder why my Windows complains that the cert emmitted by IETF is 
"not configured as a valid anchor".  Should I manually install that 
cert?  If so, that is little reasonable to ask.

Alex

>   There was an assertion made that some people were not using nat64 and 
> were using ietf-legacy were easier, and so there should be parity, and 
> so the ietf-nat64-unencrypted was created.
> because we don't people who connected to it at a previous meeting to 
> become sticky to it and keep joining -- it requires a specific action at 
> each meeting for the user to choose the unencrypted network -- we'd all 
> prefer that people use the encrypted network...
> 
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>
> I don't think the execution is relevant when it was obviously a bad idea 
> in the first place.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 20:26:43 +1300

> I have Windows 7 which is not old.  Updated regularly from Microsoft and 

My Windows 7 box is a ~5 years old Samsung and has no problem such as you report.
It is patched up to date as far as I know. I seem to think I had to authenticate
the first time I joined ietf-nat64, but that was no surprise.
...> Rather, I suspect there is a preference at the Access Point to favorise 
> Macintosh variations of WiFi Clients, rather than Windows.

I have seen no evidence of that. I expect it is a problem with the
particular WiFi device and driver built into your Windows box.
Go and see the friendly NOC staff.
https://tickets.meeting.ietf.org/wiki/IETF100network#HelpDesk

    Brian

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 08:30:08 +0100

> https://tickets.meeting.ietf.org/wiki/IETF100network#HelpDesk

I went and they updated by WiFi driver.  It worked during that IETF.

No it no longer works.  Maybe it's because my IT rolled me back into the 
earlier driver.  If so, they must have their reasons for doing so.

I go many hotspots and currently only IETF rejects my card.

I may need to check that again.

Alex

---

From: joel jaeggli <[email-masked]>
Date: Tue, 14 Nov 2017 15:31:28 +0800

> I have Windows 7 which is not old.  Updated regularly from Microsoft and

Mainstream support ended January 13, 2015. It works, if you were looking
for a more streamlined experience, the user experience has improved a
bit since then, it has not been backported.

> Macintosh variations of WiFi Clients, rather than Windows.

There's no obvious basis for that assertion.

> cert?  If so, that is little reasonable to ask.
https://tickets.meeting.ietf.org/wiki/IETF100network
https://802.1x-config.org/?idp=137&profile=101

> Alex
> 
>>   There was an assertion made that some people were not using nat64
>> and were using ietf-legacy were easier, and so there should be parity,
>> and so the ietf-nat64-unencrypted was created.
>> become sticky to it and keep joining -- it requires a specific action
>> at each meeting for the user to choose the unencrypted network -- we'd
>> all prefer that people use the encrypted network...
>>
>>
>>
>> I don't think the execution is relevant when it was obviously a bad
>> idea in the first place.
>> regret at having chosen those particular rabid weasels and that pair
>> of pants.
>>     ---maf
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Nov 2017 08:32:44 +0100

I Can connect ok to ietf-nat64-unencrypted.

Here is my feedback:

I use VPN to check emails, and the email checking and sending is much 
slower than when I do it on ietf-legacy100, or on Terminal Room Ethernet.

It has intermittency and 'hiccups'.  Sometimes the VPN gets disconnected.

Alex