Hi,
> ... wpa_supplicant does not really care about the encoding of the
> identity field, i.e., it is just sent out as arbitrary binary data.
>
> [...]
>
> Checking the source, there are no references to UTF-8 in anything
> other than comments.
I stand corrected. That makes wpa_supplica
Stefan Winter wrote:
> KNetworkManager (openSUSE Linux 11.0, 32-Bit)
> ---
>
> encoding of @müller.de to @m[0xC3][0xBC]ller.de (UTF-8, no punycode)
> encoding of cryillic characters to 2-byte encodings starting with d0 and
> d1 ->
Hi,
> Unfortunately, in at least some implementations, this is not the case.
> However, I'd be interested if there exist implementations that handle
> UTF-8 usernames. That would provide a reference to test a fix against.
>
Indeed. After some more tests:
Lancom Client Utility (same Window
Hi,
> * User-Name in GUI: some cyrillic letters
> * encoded on wire: all transcribed to the same symbol "?" in
> ISO-8859-15 or similar encoding (which is not very helpful!)
>
> To get to the cyrillic letters, I installed multi-language support and
> complex IMEs, i.e. everything I could find in
Bernard Aboba wrote:
> " The CUI is often created as "[EMAIL PROTECTED]". i.e. based off of the
> User-Name. So it's worth double-checking the effects of changing
> User-Name on all down-stream uses."
>
> Presumably the hash can be calculated on UTF-8 as well as ASCII, no?
Yes. If the "exa
Alan DeKok said:
" Or, it was easier to say 'ASCII', and to avoid any unknowns that might
occur of 8-bit data is used.
Given Stefan's test of MS-CHAP && ISO-8895-15 encodings, I think the
ASCII limitation in the spec is not matched by any similar limitations
in the code."
Unfortunately, in at
Bernard Aboba wrote:
> [BA] I agree. I don't know of any EAP peers that encode the NAI this way
> (although, based on Stefan's tests, they may not use UTF-8 either).
I think the correct term is "memcpy".
> [BA] Interesting. NAIs and e-mail addresses are similar; ...
Often the same. Lever
Alan DeKok said:
"> [BA] RFC 4282 actually proposes that the realm portion of the NAI be
> encoded in punycode, not UTF-8.
That's just wrong.
[BA] I agree. I don't know of any EAP peers that encode the NAI this way
(although, based on Stefan's tests, they may not use UTF-8 either).
> ...it
Bernard Aboba wrote:
> [BA] RFC 4282 actually proposes that the realm portion of the NAI be
> encoded in punycode, not UTF-8.
That's just wrong. No AAA client or server does that.
At the last IETF, I had proposed in a hallway conversation, to update
portions RFC 4282 to describe what impleme
FWIW, Kerberos has a similar problem (with different but similarly
obscure origins); see Section 5.2.1 of RFC4120 for some background. The
Kerberos WG is currently chartered to fix this, but there's not been
much movement yet AFAIK.
It occurred that to me that EAP & Kerberos implementors might app
Hi Bernard,
thanks for providing more insight. What a mess.
> I got an encoding of ü ::= 0xfc, which hinted that the supplicant was
> not using UTF-8 but some locale (I expect it to be either ISO-8859-15 or
> Windows-1252, not that this matters).”
>
>
> [BA] Can you provide more details on th
11 matches
Mail list logo
