ExtremeWireless - shared secret with § doesn't work

[Ronald_Dvorak]

I've upgraded a customers controller a while ago from 09.21.04.0007 to 09.21.11.0004 and after that 802.1X auth wasn't working.
We've loaded the rescue image as there was not enough time to troubleshoot the issue.

Last week we've tried again this time we went to v10.11 and had the same issue.
After some troublshooting I've changed the shared secret to 12345678 just to make sure that there was no issue with the very strong key that we've used and it was working.

Today I was able to find the "problem" character - if § is used it doesn't work.

I assume it's a supported character as the controller doesn't show any error message if I save the key.

Customer used Windows NPS and I've used my NAC to test it so it looks like a problem on the controller.

-Ron

[Ty_Kolff]

That is really good information to know. Thanks for sharing Ron!

[Erik_Auerswald]

Hi Ron,

that character is not part of 7 bit ASCII, thus it is encoded differently into byte values based on the character encoding used.

On my Unicode enabled system using the en_US.UTF-8 locale, § is implemented as Unicode character U+00A7, encoded as the single byte 0xA7 in ISO-8859-1 (latin1) encoding, the two bytes 0xC2 and 0xA7 in UTF-8 encoding and the four bytes 0xFE, 0xFF, 0x00, and 0xA7 in UTF-16 encoding.

The RADIUS shared secret is based on byte values, which could differ if different encodings are used on NAS and NAC.

To avoid such problems, I would suggest restricting passwords to use 7 bit ASCII characters only.

Erik

[Erik_Auerswald]

You should use a US keyboard, that does not provide non-ASCII characters accessible via head banging. 

[Ronald_Dvorak]

MMMmhhhh, that doesn't work with my strong key generation process = banging my head 10 times on the keyboard 🙂