Re: Internationalization and draft-ietf-abfab-eapapplicability

Hi,

> I think assuming that 4282bis has reached consensus on
> internationalization is wildly wishful thinking at this stage.  I
> continue to be dubious that the right parties are involved in the
> discussion and even if we have consensus in radext expect significant
> discussion at ietf last call, appsdir review and IESG review.
I had the impression we are getting somewhere, but that's just a
personal opinion of course.

> However, I absolutely agree that if an application is going to use EAP
> it needs to  follow EAP's i18n conventions whatever those may be.  A
> rrequirement on anti-causal investigation for current implementation
> efforts has never stopped us before.
> I also agree the current document does not speak to this.
>
> My recommendation is that we point out the issue.  And say that strings
> used within a specific EAP method MUST follow the rules for that method.
> If AAA is used, strings used within AAA MUST follow the rules for the
> AAA protocol in use.  We can add an informative citation to 4282bis as a
> snapshot of current thinking.
Pushing the requirement down to the EAP method won't work IMHO. Take as
example EAP-TTLS in RFC5281. A full-text search for "UTF" in it yields 0
hits; and a look at section 7.3 ("EAP Identity Information") does not
speak of any encodings.

IMHO, not being explicit in the EAP spec itself has brought us to the
i18n problems we are seeing. An EAP supplicant supporting EAP-TTLS can
use latin-1 or foobar as encoding for the EAP identity; he'll send that
bytestream on the wire without the encoding information being known,
meaning a UTF-8 sanitisation isn't possible anywhere further down the
route. The supplicant also doesn't know that the authenticator will wrap
this in RADIUS, so can't be aware of the next-hop's requirement to use
UTF-8.

The poor pass-through authenticator now gets a blob with not valid
UTF-8, and is forced to either violate RFC2865 by putting non-UTF-8 into
a RADIUS User-Name, or by rejecting the entire EAP authentication for a
reason the EAP supplicant can do nothing about because it doesn't know
about it. In the IEEE 802.1X network access case, there's also no
signalling what exactly was the reason for EAP to break; EAPoL is not
very verbose. I don't know about ABFAB; GSSAPI could well have a way to
signal that it choked on encoding - or not.

In the end, all participants in the conversation can claim they did the
"right thing", and yet nothing worked.

> I would not support a normative reference to 4282bis.
That I agree with; 4282bis is about NAIs exclusively. I could well
imagine ABFAB being deployed inside an enterprise where EAP identities
do not follow the NAI provisions; any restrictions on the encoding or
normalization should apply to those deployments nontheless.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

signature.asc
Description: OpenPGP digital signature