On Thu, Oct 20, 2011 at 1:06 AM, Alan DeKok <[email protected]> wrote: > Nico Williams wrote: >> On Wed, Oct 19, 2011 at 7:24 PM, Sam Hartman >> Well, you stated that RADIUS servers can't be expected to do more than >> byte-wise comparison. Why is that? > > It's what hey do today. It's the easiest thing to do. Normalization > may require information (locale, etc.) which is not available in the > protocol.
Normalization does not require locale information. Case-folding does (because of things like the Turkish i), but the information loss in locale-less case-insensitive comparisons is probably much less problematic than in case-folding for storage strings, say. But we're not talking about case-folding :) >> And if that really is true then >> you'll need to send normalized strings. > > Pretty much. My take is that normalization is out of scope for both > the RADIUS server and for the EAP peer. They both rely on some > user-facing UI to obtain the user credentials. That UI should perform > normalization, as it has information no one else has. See above. The only information needed for normalization is the input string's codeset and encoding (can we assume UTF-8?) and the desired normalization form (unless we're talking about normalization-insensitive comparison, in which case NF is of little interest). If the relevant strings in RADIUS have historically not had codeset and encoding defined then it will likely be best to say that the peer makes right. For the acceptor name I think it's best to say that the peer makes right. As for GSS_C_NT_HOSTBASED_SERVICE we really need to decide some day whether we want A-labels, U-labels or what. If we say the app must pass A-labels to gss_import_name() then that will apply to all mechs, but if we don't then each mech could convert to A-labels if it wanted to. Perhaps it's time to tackle this at KITTEN? > Requiring the EAP peer to normalize the data is for me just like > asking an intermediate RADIUS proxy to normalize the data. It just > doesn't make sense. OK, thanks. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
