Subject: [abfab] Haunted by I18n

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 17:13:07 -0400

So, I noticed that we don't specify the character set of the GSS-EAP
name.  Well, that's sort of easy.  We can say UTF-8.  Which of course
raises the question of "what then."

That, shall we say, is kind of a mess.  Most of that mess is not our
problem.  However, the part that definitely is is the comparison of the
acceptor name attribute provided via AAA with the attribute provided by
EAP channel bindings.

We want some sort of normalization insensitive comparison that has nice
happy properties.  In practice, of course what we'll get is octet
comparison on the RADIUS server.

Advice from people who have sailed this swap before?

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 17:04:09 -0500

> Advice from people who have sailed this swap before?

What's the issue?  Open source Unicode libraries with various styles
of licenses exist that should suffice for your purposes.  Do you need
normalization or normalization insensitivity only, or do you also need
to apply various mappings?

Open source Unicode C implementations include:

 - ICU
 - the u8_textprep stuff in OpenSolaris (CDDL)
 - Heimdal has a normalization library

I bet there's more.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 20:24:13 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> On Wed, Oct 19, 2011 at 4:13 PM, Sam Hartman
    >> Advice from people who have sailed this swap before?

    Nico> What's the issue?  

What behavior do we specify?
I'm not interested in code--I'm interested in spec text that will work
today and will evolve well.

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 19:50:38 -0500

On Wed, Oct 19, 2011 at 7:24 PM, Sam Hartman
<[email-masked]> wrote:
>    >> Advice from people who have sailed this swap before?
>
>    Nico> What's the issue?
>

Whenever possible aim to do norm-insensitive comparisons, allowing
nodes to just-send-UTF-8.

> today and will evolve well.

Well, you stated that RADIUS servers can't be expected to do more than
byte-wise comparison.  Why is that?  And if that really is true then
you'll need to send normalized strings.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Oct 2011 21:59:00 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> On Wed, Oct 19, 2011 at 7:24 PM, Sam Hartman
    >> What behavior do we specify?

    Nico> Whenever possible aim to do norm-insensitive comparisons,
    Nico> allowing nodes to just-send-UTF-8.

Sure.
But the current IESG seems to believe that you want at least a SHOULD
for what comparison algorithm.

We want something that maximizes  interop with:

* The comparison specified in NAI document
* saslprep
* whatever Kerberos eventually does
* IDNA 2008 for hostnames

    >> I'm not interested in code--I'm interested in spec text that will
    >> work today and will evolve well.

    Nico> Well, you stated that RADIUS servers can't be expected to do
    Nico> more than byte-wise comparison.  

Sorry. I was being flip. I suspect we're all lazy and the first
implementations will not do more than is required to work most of the
time.  I suspect as people run into real problems we'll write better
code.

Note that I'm not writing aRADIUS server.

--Sam

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Oct 2011 21:34:05 -0500

This is for the acceptor name, yeah?

For hostbased services you could say use IDNA A-labels...  Yeah, I
know.  That's ugly.

But note that if something's a domainname slot then the comparison
semantics are already set.

Nico
--

---

From: Alan DeKok <[email-masked]>
Date: Thu, 20 Oct 2011 08:06:50 +0200

Nico Williams wrote:
> 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.

>  And if that really is true then

  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.

  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.

  Alan DeKok.

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Oct 2011 12:14:43 -0500

> may require information (locale, etc.) which is not available in the

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 :)

> 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?

> asking an intermediate RADIUS proxy to normalize the data.  It just

OK, thanks.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 Oct 2011 13:21:07 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> For the acceptor name I think it's best to say that the peer
    Nico> makes right.

I don't.
Both the initiator and acceptor send this to the EAP server.
I think the EAP server is in a much better position to do comparison
here than either the peer or acceptor.
It's also totally new code.

---

From: Nico Williams <[email-masked]>
Date: Thu, 20 Oct 2011 13:15:54 -0500

> It's also totally new code.

Failure to match leads to fail-safe though, no?  But if it's all new
code, sure, I'd rather you do norm-insensitive comparison in the EAP
server.

Nico
--