Subject: [Emu] EAP and UTF-8

From: Stefan Winter <[email-masked]>
Date: Thu, 11 Sep 2008 16:04:00 +0200

Hello,

I'm currently trying to figure out what would happen if a AAA roaming 
consortium (802.1X based, using EAP and RADIUS) were to use IDNs in its 
NAIs, i.e. a user name like [email-masked].

I was kindof expecting to see UTF-8 encoded User-Name attributes showing 
up at the RADIUS server, since RFC2865 defines User-Name to be UTF-8.

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

I was kindof expecting to witness a bug in the supplicant because it 
should have encoded the EAP-Response/Identity as UTF-8.

Taking a look at RFC3748, I noticed the following text in 5.1 Identity:

This field MAY contain a displayable message in the Request,
      containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
      the Request contains a null, only the portion of the field prior
      to the null is displayed.  If the Identity is unknown, the
      Identity Response field should be zero bytes in length.  The
      Identity Response field MUST NOT be null terminated.  In all
      cases, the length of the Type-Data field is derived from the
      Length field of the Request/Response packet.

It struck me that according to this clause, the supplicant in principle 
has the option of encoding the EAP-Response/Identity to its liking, 
since this clause only defines displayable messages in 
EAP-*Request*/Identity to be UTF-8 encoded.

What troubles me even more is that RADIUS (or Diameter, for that matter) 
requires UTF-8 encoding in the User-Name attribute, and that 802.1X 
authenticators are required to literally copy EAP-Identity into the 
User-Name attribute, even if it is not necessarily UTF-8. That would 
mark an incompatibility within IEEE 802.1X.

I seriously hope that I overlooked something, or that I have a language 
problem and this UTF-8 half-sentence should span over more than the 
displayable message in the Request, and would be happy if someone could 
clear this up. If the issue stands, it is a bit uneasy... making the 
encoding in the response undefined means that the auth traffic can look 
different depending on OS, locale, ... . In any case, out of two 
supplicants I tried, both did indeed *not* use UTF-8, so I wouldn't be 
the only one confused. This makes adding IDN NAIs somewhat difficult.

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

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Stefan Winter <[email-masked]>
Date: Thu, 11 Sep 2008 16:29:56 +0200

Hi,

>   RFC 3748 Section 5.1 allows additional data to be transmitted after
> the NUL in an Identity Request.  This could perhaps be leveraged to send
> a string such as "UTF-8", which could indicate to the supplicant that
> the server is requesting UTF-8 encoding.

Hmm... In 802.1X, the EAP-Request/Identity is sent by the authenticator, 
which, in a scenario with multiple home authentication servers and 
realms, does not necessarily know which home server expects which 
encoding. A negotiation would be very nice, but I doubt it can work that 
way in a 802.1X deployment.

Greetings,

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Sep 2008 16:23:42 +0200

> NAIs, i.e. a user name like [email-masked].

  On a related note, there was discussion in Dublin about updating RFC
4282 for internationalized NAI's.  This may be relevant.

> Windows-1252, not that this matters).

  I suspect so.  The supplicant is likely just copying the username from
some external source into the EAP packet.

  My $0.02 is that the supplicant _usually_, at some level, has access
to the current locale && character encoding.  The locale and character
encoding cannot be passed as part of an EAP transaction.  Therefore, the
supplicant should be responsible for transforming the name into a
wire-compatible form: UTF-8.

  The caveat here is that there are likely lots of deployments where the
stored User-Name on the server is just a cut&paste from the logs.  If
the supplicant doesn't send UTF-8, then the User-name on the server may
reflect the supplicant's choice of locale && encoding.

  Changing the supplicant to use UTF-8 may break authentication.

> EAP-*Request*/Identity to be UTF-8 encoded.

  Yes, unfortunately.

> mark an incompatibility within IEEE 802.1X.

  It would appear so.

> different depending on OS, locale,

  Yes.  This is the current situation.

> ... . In any case, out of two 

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Sep 2008 16:58:45 +0200

> way in a 802.1X deployment.

  The alternative is for supplicants to simply start using UTF-8.  It's
likely a good idea, in any case.

  A compatibility option would be for the server to look at it's list of
known users, and convert them (where appropriate) to UTF-8.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Sep 2008 07:50:01 +0200

Hi,

> likely a good idea, in any case.

Yes, I'd be very happy if supplicants did that. Obviously some refrained 
from doing it so far, and I don't think there is a lot of incentive to 
make them change their code if we can't even rightfully claim that the 
current behaviour is violating the EAP RFC.

> known users, and convert them (where appropriate) to UTF-8.

I start to wonder how this was supposed to work reliably anyway so far. 
The encoding is undefined, so even if a user db on the server side and 
what a client sends are in sync initially, the process could break at 
any time with a  character-set related change in the client's OS which 
is not necessarily related to the supplicant. I.e. it looks to me that 
using non-ASCII characters in EAP-Identities so far was a question of 
chance.

That, or simply people didn't use non-ASCII for identities. Which leads 
to the third option: screw non-ASCII in NAIs. Though that is probably 
not an overly popular approach. And RFC4282 includes it as valid explicitly.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Sep 2008 16:10:47 +0200

> using non-ASCII characters in EAP-Identities so far was a question of

  Yes.  However, we can reasonably expect that a user's locale &&
character encoding will change rarely on one machine.  We can reasonable
expect that the same locale && character encodings will result in the
same output data for different installations of the same OS.

  The result is that it's likely not much of a problem for non-roaming
situations.  It also bolsters my opinion that usernames are treated as
opaque tokens, and not as words in a language that should be
internationalized.

> not an overly popular approach. And RFC4282 includes it as valid

  People use non-ASCII strings for identities.  Breaking this is not nice.

  However, using UTF-8 is likely a better choice than depending on
implementation-specific behavior.

  Alan DeKok.

---

From: "Josh Howlett" <[email-masked]>
Date: Mon, 15 Sep 2008 09:52:52 +0100

> >   The alternative is for supplicants to simply start using UTF-8.  
> > It's likely a good idea, in any case.
> >   
> 
> Yes, I'd be very happy if supplicants did that. Obviously 
> some refrained from doing it so far, and I don't think there 
> is a lot of incentive to make them change their code if we 
> can't even rightfully claim that the current behaviour is 
> violating the EAP RFC.

Is there a good reason *not* to change the RFC to stipulate UTF-8? (I
can't see that this would break anything)

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 15 Sep 2008 10:48:20 -0700

> can't see that this would break anything)

I suppose that we could also propose new RFC boilerplate saying something
like "IF YOU ARE A MORON DON'T IMPLEMENT THIS SPECIFICATION." but I don't
think it would do much good.  RFC 4282 already allows UTF-8 for NAIs that
cannot be represented in ASCII.  If a supplicant doesn't use it, it's a bug
in the supplicant implementation, not in the NAI specification, let alone
EAP or .1X.  

...

---

From: Alan DeKok <[email-masked]>
Date: Mon, 15 Sep 2008 20:12:38 +0200

> can't see that this would break anything)

  It would break existing systems that have deployed non-UTF-8 systems.
 i.e. systems with unknown and/or arbitrary encoding.

  This may be a Good Thing.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 16 Sep 2008 08:22:43 +0200

Hi,

>   This may be a Good Thing.

I don't mind breaking undefined behaviour and replacing it for something 
that's working deterministically. :-)

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Tue, 16 Sep 2008 08:27:18 +0200

Hi,

> opaque tokens, and not as words in a language that should be

Even in non-roaming situations it might be an issue. Considering a user 
may have been given access on one device, and then buys a second one 
(say, smartphone) with a different OS, supplicant, networking stack. 
That user might reasonably expect his credentials to work on that other 
device in this local campus situation. The specs right now add a non-0 
chance that it won't. That may be less a concern in locked-down 
enterprise campuses, where employee's devices are handed out centrally 
and go through a certification, but in other environments like a typical 
university, where the network consumers are often allowed to use 
arbitrary devices, this could very well be an issue.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Tue, 16 Sep 2008 08:48:27 +0200

Hi,

> think it would do much good.

Me neither. Call me prejudiced, but I would expect that a typical moron 
lacks the required self-awareness to think of himself as being a moron. 
So the likely effect of such a sentence is that the moron laughs and 
thinks to himself: "Ha - what a funny document, they are even dealing 
with morons here!" and implements it anyway because such a sentence is 
of course meant for other people.

As a side-thought, I've tried two popular industry-quality supplicants 
and they indeed both didn't use UTF-8. If that kind of thing happens, 
one might wonder if it's really morons at the wheel, or if the 
specification is just too ambiguous for comfort.

So I would suggest to be a little bit more specific about what to do or 
not to do. Like writing "UTF-8 in EAP-Response/Identity is REQUIRED." or 
similar.

>   RFC 4282 already allows UTF-8 for NAIs that

RFC3748 mentions NAI a few times, but nowhere does it restrict the use 
of the user name identifier to be a NAI (and, subsequently, UTF-8) , nor 
does any updating RFC state this. Clarifying this was exactly my 
question at the start of this thread.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Sep 2008 09:11:11 +0200

> lacks the required self-awareness to think of himself as being a moron.

  This is not idle speculation.

http://www.apa.org/journals/features/psp7761121.pdf

Title: Unskilled and Unaware of It: How Difficulties in Recognizing
One's Own Incompetence Lead to Inflated Self-Assessments

> specification is just too ambiguous for comfort.

  The specification isn't ambiguous.  It's unclear.  UTF-8 should be
used, but if it isn't, your software will still work, and be
inter-operable.  Mostly.

> not to do. Like writing "UTF-8 in EAP-Response/Identity is REQUIRED." or

  And why.  The specifications aren't just a collection of MUST and MUST
NOT.  There's also a need for additional text that explains *why* it's
done this way.

  Alan DeKok.

---

From: "Josh Howlett" <[email-masked]>
Date: Tue, 16 Sep 2008 09:52:14 +0100

> > > Yes, I'd be very happy if supplicants did that. Obviously some 
> > > refrained from doing it so far, and I don't think there 
> is a lot of 
> > > incentive to make them change their code if we can't even 
> rightfully 
> > > claim that the current behaviour is violating the EAP RFC.
> > 
> I suppose that we could also propose new RFC boilerplate 
> saying something like "IF YOU ARE A MORON DON'T IMPLEMENT 
> THIS SPECIFICATION." but I don't think it would do much good. 

I don't think this is a question of anyone being a moron. The supplicant
implementors read the spec, noticed that it did not recommended or
stipulate any particular encoding, and therefore (ab)used the subsequent
wriggle-room to do their own thing - while still observing both the
letter and spirit of the spec.

>  RFC 4282 already allows UTF-8 for NAIs that cannot be 
> represented in ASCII.  If a supplicant doesn't use it, it's a 
> bug in the supplicant implementation, not in the NAI 
> specification, let alone EAP or .1X.  

This would be a supplicant bug if the spec stipulated an encoding, and
the implementors ignored it. This isn't the case, and so IMHO the
encoding needs to be constrained so that we get the deterministic
behaviour that Stefan alluded to previously.

josh.