Subject: Internationalization and draft-ietf-abfab-eapapplicability

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jul 2013 12:42:29 -0700

After reading this document, I believe that this document omits discussion of an important aspect, which is  internationalization.  Since the contents of the EAP Identity and RADIUS User-Name attributes are specified to be encoded in UTF-8, application protocols that utilize encodings other than UTF-8 for user identities and passwords could have issues utilizing EAP (and RADIUS).  Currently RFC 4282bis proposes that all EAP implementations normalize identities and passwords before utilizing them, and therefore application protocols that do not do this will be at variance with RFC 4282bis.  
IMHO the document needs to state what the internationalization requirements are for application-layer protocol use of EAP.  There are potential workarounds, such as requiring that application protocols convert identities and passwords to UTF-8 prior to use of EAP, or modifying RFC 4282bis so as to require normalization in RADIUS proxies or servers.   However, without fixes being applied and/or changes to RFC 4282bis, use of EAP by applications may not be compatible with either existing specifications or implementations. 
Background

EAP and protocols that carry it (e.g. RADIUS) assume that the EAP-Response/Identity is encoded in UTF-8.  For example, RFC 3748 Section 1.2 defines "displayable message" as follows: 
   Displayable Message
      This is interpreted to be a human readable string of characters.
      The message encoding MUST follow the UTF-8 transformation format
      [RFC2279].
Therefore EAP messages including EAP Identity and Notification that are described as "displayable messages" have a UTF-8 encoding requirement applied to them. 
Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute:    In order to permit non-EAP aware RADIUS proxies to forward the
   Access-Request packet, if the NAS initially sends an
   EAP-Request/Identity message to the peer, the NAS MUST copy the
   contents of the Type-Data field of the EAP-Response/Identity received
   from the peer into the User-Name attribute and MUST include the
   Type-Data field of the EAP-Response/Identity in the User-Name
   attribute in every subsequent Access-Request.
Therefore for use with EAP, the User-Name Attribute also inherits a UTF-8 encoding requirement, restricting the potential encodings permitted by RFC 2865 Section 5.1 (User-Name Attribute): 
      The format of the username MAY be one of several forms:

      text      Consisting only of UTF-8 encoded 10646 [7] characters.

      network access identifier
                A Network Access Identifier as described in RFC 2486
                [8].

      distinguished name
                A name in ASN.1 form used in Public Key authentication
                systems.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 17 Jul 2013 06:29:55 +0200

> IMHO the document needs to state what the internationalization requirements are for application-layer protocol use of EAP.  There are potential workarounds, such as requiring that application proto…

In addition to this, if the string is to be compared with other strings (directly or indirectly) just specifying encoding is not enough. You must also specify the matching algorithm used, and one such can be for example to normalize the string(s) before doing character by character comparison and specifying what the normalization algorithm is.

   Patrik Fältström

> Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is copied into the RADIUS User-Name Attribute: 
>    In order to permit non-EAP aware RADIUS proxies to forward the

---

From: Stefan Winter <[email-masked]>
Date: Wed, 17 Jul 2013 08:52:02 +0200

Hi,

> After reading this document, I believe that this document omits
> discussion of an important aspect, which is  internationalization.
>  Since the contents of the EAP Identity and RADIUS User-Name attributes
> are specified to be encoded in UTF-8, application protocols that utilize
> encodings other than UTF-8 for user identities and passwords could have
> issues utilizing EAP (and RADIUS).  Currently RFC 4282bis proposes that
> all EAP implementations normalize identities and passwords before
> utilizing them, and therefore application protocols that do not do this
> will be at variance with RFC 4282bis.  
> 
> IMHO the document needs to state what the internationalization
> requirements are for application-layer protocol use of EAP.  There are
> potential workarounds, such as requiring that application protocols
> convert identities and passwords to UTF-8 prior to use of EAP, or
> modifying RFC 4282bis so as to require normalization in RADIUS proxies
> or servers.   However, without fixes being applied and/or changes to RFC
> 4282bis, use of EAP by applications may not be compatible with either
> existing specifications or implementations. 

The discussion in radext on RFC4282bis was very long and much thought
has gone into "fixing" internationalisation aspects. The fix is still
partial only, because of the said uncertainties about the input encoding
and normalization. RADIUS servers or proxies touching and manipulating
the Identity/User-Name was seen as the bigger of two evils; the lesser
one being the requirement on EAP supplicants to perform normalization on
their own.

If a change is needed in the eapapplicability draft, I'd prefer to
change eapapplicability to be in line with 4282bis, not the other way
around.

> Background
> 
> EAP and protocols that carry it (e.g. RADIUS) assume that the
> EAP-Response/Identity is encoded in UTF-8.
>
>  For example, RFC 3748
> Section 1.2 defines "displayable message" as follows: 
> 
>    Displayable Message
> Therefore EAP messages including EAP Identity and Notification that are
> described as "displayable messages" have a UTF-8 encoding requirement
> applied to them. 

I disagree with your reading of RFC3748.

It's true that "displayable messages" need to be encoded in UTF-8; but
the document does not state that an EAP-Response/Identity is a
"displayable message". Section 5.1 of RFC3748 uses the term "displayable
message" several times, but never in conjunction with the Identity
*response*:

"An optional displayable message MAY be included to
      prompt the peer in the case where there is an expectation of
      interaction with a user. "

(which is for the request, and it is optional)

and later on:

"Type-Data

      This field MAY contain a displayable message in the Request,
      containing UTF-8 encoded ISO 10646 characters [RFC2279]."

This is the normative language for the previous text.

I keep staring at section 5.1 of that RFC and see nothing that would
require the EAP-Response/Identity to be UTF-8.

I also believe that the lack of being clear at that particular point is
"the root of all evil" because it allows EAP supplicant implementers to
choose arbitrary encodings for conveying the identities.

It is somewhat understandable that EAP-Response/Identity was not tagged
as "displayable message" back in the day - its purpose is not to be
displayed anywhere; it's input to the authentication algorithm and is
meant to be processed by an EAP server. So, if there's nothing to
display, it's not a displayable message.

RFC3748 would have achieved more clarity and better interop if it would
have explicitly demanded the EAP-Response/Identity to be UTF-8 even
though it's not a displayable message.

Now, that would suggest an update to RFC3748, introducing a UTF-8
requirement at that spot. And guess what - we're writing a document that
updates RFC3748!

The question is: this document is about an applicability update, not a
change of the on-the-wire behaviour of EAP. If we were to try and apply
a proper fix to RFC3748 to make Identities UTF-8 everywhere, then the
impact is way beyond ABFAB. We previously tried to make the
applicability statement "for all of EAP", but later decided to restrict
ourselves to ABFAB-specific updates.

The next best solution then would be to require that only ABFAB-using
EAP supplicants are required to use UTF-8 (and possibly also require a
normalisation). That would indeed solve ABFAB's i18n'ed use of EAP, but
not everybody else's. That's a bit selfish, but it would certainly be
better than nothing.

I wonder what the other authors think about nailing down a
UTF-8/NFC-normalised Identity into the draft.

Greetings,

Stefan Winter

> Since RFC 3579 Section 2.1 specifies that the EAP-Response/Identity is
> copied into the RADIUS User-Name Attribute: 
> 
> Therefore for use with EAP, the User-Name Attribute also inherits a
> UTF-8 encoding requirement, restricting the potential encodings
> permitted by RFC 2865 Section 5.1 (User-Name Attribute): 
> 

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jul 2013 11:35:33 +0100

Hi Bernard, Patrik,

Thanks for the comment. Checking that out now and will
get back.

Cheers,
S.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Jul 2013 07:04:20 -0400

>>>>> "Stephen" == Stephen Farrell <[email-masked]> writes:

    Stephen> Hi Bernard, Patrik,

    Stephen> Thanks for the comment. Checking that out now and will get
    Stephen> back.

Bernard, thanks for the comment.  I expected to feel really frustrated
at how late the comment was sent but after reading your message I agree
it was appropriate to send at this stage (although sooner is always
better).

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.

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.

I would not support a normative reference to 4282bis.

---

From: Stefan Winter <[email-masked]>
Date: Wed, 17 Jul 2013 13:41:00 +0200

Hi,

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

> 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

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 17 Jul 2013 13:53:43 +0200

Hi,

> Pushing the requirement down to the EAP method won't work IMHO.

Further to this: now that I have EAP-TTLS on screen, its words of wisdom
about EAP type selection show that it won't work quite clearly. And they
are valid beyond EAP-TTLS. Section 7.3 of RFC5281 states:

"Note that at the time the initial EAP-Response/Identity packet is
   sent the EAP method is yet to be negotiated.  If, in addition to EAP-
   TTLS, the client is willing to negotiate use of EAP methods that do
   not support user anonymity, then the client MAY include the name of
   the user in the EAP-Response/Identity to meet the requirements of the
   other candidate EAP methods."

This was written for anonymisation reasons; but it applies to i18n as
well. If EAP-Type A uses encoding X, and EAP-Type B uses encoding Y, in
which encoding should the initial EAP-Response/Identity be sent?

One can only hope that all the EAP types which are configured on the
supplicant share one common encoding that is allowed in all of them, and
that the supplicant chooses wisely. Otherwise the question above can
turn into a "does not compute".

Sure, a half-baked answer is that the real identity is in a tunnel
anyway, and the EAP type is known at that time; but that doesn't cover
all cases. EAP-pwd has no tunnel, and needs to rely on the "outer"
identity being in a format it can process. There are more untunneled EAP
types.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Jul 2013 08:17:59 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

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

    Stefan> Pushing the requirement down to the EAP method won't work
    Stefan> IMHO. Take as example EAP-TTLS in RFC5281. A full-text
    Stefan> search for "UTF" in it yields 0 hits; and a look at section
    Stefan> 7.3 ("EAP Identity Information") does not speak of any
    Stefan> encodings.

    Stefan> IMHO, not being explicit in the EAP spec itself has brought
    Stefan> us to the i18n problems we are seeing. 

Nah, you'd just be living in a different hell if you'd been explicit in
the EAP spec.  I know: other parts of the IETF are in that hell.  The
protocols are clear and everything is fine until you realize that the
backend authentication systems you're dealing with are using a totally
different set of rules than the protocols.
That hell sucks too.

Some EAP methods are going to care a lot. They'll care more about
passwords than they will usernames.  Usernames are complex because they
can be carried in AAA, EAP identity and within a method.

However, if someone ever does EAP-Kerberos, it's going to have to
specify its own string rules so it can send valid Kerberos PDUs.
MSCHAPV2 had to be compatible with the NTLM hash.

Only the method is in a position to know what strings to send.
We have an unfortunate situation where some methods don't  specify.  As
you point out TTLS is delightfully ambiguous here.  I can point to
similarly annoying deficiencies in the TTLS spec in other areas.

we can write a guidance document for non-standards-track methods that
are ambiguous giving the best advice we can.  We can give good
requirements in standards-track methods.  TEAP is in last-call now; I'm
fairly sure it gets this reasonably OK, but we should probably check
that.

However, none of the above matters for this document.
We're not tasked with documenting EAP.  We're certainly not tasked with
fixing EAP.  We're tasked with giving applications requirements for
working with EAP.
I'm fairly sure the requirement is that applications need to do whatever
EAP expects, understanding that there could be more clarity about that.
Applications need to follow the requirements of EAP, of the AAA
protocols they use and of the EAP methods they use.
There's probably disagreement about what those requirements are; we
should not allow this document to be blocked on resolving that
disagreement.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Jul 2013 05:33:40 -0700

> The question is: this document is about an applicability update, not a> change of the on-the-wire behaviour of EAP. 
[BA] That's right -- which is why I see no need for the applicability update to depend on RFC 4282bis.  It just needs to discuss the applicability aspects. 
> If we were to try and apply a proper fix to RFC3748 to make Identities UTF-8 everywhere
[BA]  We are just talking about core EAP and RADIUS RFCs here.  Internationalization of method-specific identities (and passwords) is defined by the EAP method specifications, so the "Identities UTF-8 everywhere" is a much broader topic (and one which I'd argue is not relevant to an ABFAB applicability statement). 
> normalisation). 
[BA] I would agree with a UTF-8 requirement for EAP-Response/Identities.  That is necessary in practice, because RFC 3579 requires that the EAP-Response/Identity be copied into the RADIUS User-Name attribute, and  RFC 2865 Section 5.1 states that:
      The format of the username MAY be one of several forms:

      distinguished name
                A name in ASN.1 form used in Public Key authentication
                systems.
Internationalization of method-specific identities and passwords are up to the methods, so the document can just point this out and say "see applicable RFCs."
Personally, I don't think that the ABFAB applicability statement has to mandate normalization in NAIs -  that would make it depend on RFC 4282bis, and that doesn't seem necessary to me.  Instead, it can just make the reader aware of RFC 4282bis and say that uses need to conform to internationalization requirements which are a work in progress. 

That would indeed solve ABFAB's i18n'ed use of EAP, but

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Jul 2013 05:48:29 -0700

> informative citation to 4282bis as a snapshot of current
[BA] That works for me. 
>     Stefan> 7.3 ("EAP Identity Information") does not speak of any
[BA] You are right that a number of method specifications are deficient in the internationalization area.  However, I don't think that's an issue that an ABFAB applicability statement can solve.   Sam's proposed approach seems like the only feasible one. 
Sam said:  > Nah, you'd just be living in a different hell if you'd been explicit in
> different set of rules than the protocols.
[BA] I totally agree. 
> can be carried in AAA, EAP identity and within a method.

[BA] Yes, but at least the method-specific identities and passwords are opaque to the EAP core implementation and the AAA protocol. 
> we can write a guidance document for non-standards-track methods that> are ambiguous giving the best advice we can.  We can give good
> that.>> However, none of the above matters for this document.
[BA] Exactly.  It's just an applicability statement, not a prescription for world peace :)

---

From: Stefan Winter <[email-masked]>
Date: Wed, 17 Jul 2013 15:16:42 +0200

Hi,

>> different set of rules than the protocols.

I'm joyfully naïve here.

Right now, the receiving end has no guarantees about the encoding and
normalisation of the incoming string. If it doesn't match its
expectations in that regard, then that's unrecoverable.

In the other hell, it can be sure to receive UTF-8 in NFC, and if that
doesn't match what it needs, it can convert it.

In my naïve thinking, that second hell is a lot less hot and much more
habitable.

Could you point out where my thinking goes wrong?

Also: we're dealing with writing specifications here. If our
specifications are correct, and some implementations do it wrong anyway
- that's their problem, right?

> [BA] Exactly.  It's just an applicability statement, not a prescription

Sure: we need more than an applicability statement update to achieve
peace in the EAP world. But if an applicability statement update is all
we can work with, we could try and do our best in that one.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 17 Jul 2013 15:30:55 +0200

Hi,

> [BA]  We are just talking about core EAP and RADIUS RFCs here.
>  Internationalization of method-specific identities (and passwords) is
> defined by the EAP method specifications, so the "Identities UTF-8
> everywhere" is a much broader topic (and one which I'd argue is not
> relevant to an ABFAB applicability statement). 

Indeed; sorry for the imprecise use of "everywhere". What needs to be
tackled is EAP's "outer" or "only" identity (for methods that don't have
the luxury of sending a different identity in their method-specific
payload).

> [BA] I would agree with a UTF-8 requirement for EAP-Response/Identities.
>  That is necessary in practice, because RFC 3579 requires that the
> EAP-Response/Identity be copied into the RADIUS User-Name attribute, and
>  RFC 2865 Section 5.1 states that:

You are conflating AAA with RADIUS. EAP-Response/Identity can be used in
other contexts; I heard that some use Diameter instead of RADIUS, so any
reference to RFC2865 would not apply there. And if I write
MyOwnAAAProtocol and require EAP Identities in EBCDIC encoding in my
equivalent of User-Name, then that's my thing alone and RFC2865 has
nothing to say to me.

The EAP supplicant doesn't know which AAA is going to be used behind the
authenticator; so how would it know whether to use EBCDIC or UTF-8?

Unless, of course, there is a place outside of RFC2865 which forces me
to accept/use exclusively UTF-8. An update to RFC3748 stating that comes
to mind.

> Internationalization of method-specific identities and passwords are up
> to the methods, so the document can just point this out and say "see
> applicable RFCs."

As stated elsewhere in the thread, the initial EAP-Identity needs to be
sent before the EAP method is negotiated.

> Personally, I don't think that the ABFAB applicability statement has to
> mandate normalization in NAIs -  that would make it depend on RFC
> 4282bis, and that doesn't seem necessary to me.  Instead, it can just
> make the reader aware of RFC 4282bis and say that uses need to conform
> to internationalization requirements which are a work in progress. 

This is a cliffhanger text with a forward-reference into the future. I
could live with a statement like that, but ...

... just listing 4282bis is not enough; EAP identities don't have to be
NAIs - if we state that applications need to conform to that future RFC,
and they read things in it like "This document only defines NAIs, if you
don't use NAIs, there's nothing in it for you" - then implementations
have a way too easy loophole to not care about i18n; they can just say:
oh, we don't use NAIs. It's all unstructured identities; any presence of
an @ in there is just coincidence.

I could live with it very well if there is a promise to continue the
cliffhanger situation with an all-encompassing update that covers all
EAP Identities; be they NAIs or not and be they transported over RADIUS
or not.

I.e. if we can agree that updating RFC3748 with stricter i18n rules is
going to be chartered work and will happen, then I can live with a
cliffhanger statement of "stay tuned for that update" in the
eapapplicability draft.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Jul 2013 06:38:24 -0700

> we can work with, we could try and do our best in that one.

[BA] The goal of an applicability statement to provide guidance as to the applicability of a particular standard. 
Using a marine analogy, it can say "it is ok to take a boat of this size out into the ocean", but it doesn't have to provide a detailed map of every harbor. 
So it seems like there is a need to address application-layer protocols that don't encode their identities in UTF-8 over the wire today.  Is EAP applicable to these protocols?  If so, is there something they need to be aware of?  Going beyond that is probably for other documents, not this one.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Jul 2013 10:31:53 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> In the other hell, it can be sure to receive UTF-8 in NFC,
    Stefan> and if that doesn't match what it needs, it can convert it.

    Stefan> In my naïve thinking, that second hell is a lot less hot
    Stefan> and much more habitable.

This discussion has also moved to the abfab list.
I'm responding there because ultimately we'll need WG consensus for any
change.

however there's one point I'll respond in my last message on this
thread..

you have: a UTF-8 NFC hashed password response to your password
challenge.

You want: the same input to the hash except the input should be UTF-16
encoded with the normalization implicit in the Windows input method.

Or
you have: a UTF-8 NFC encoded username

you want: whatever PAM wants.  Your PAM stack is complex and may involve
network protocols with their own encodings.

The second example is intended to illustrate why OS folks like Nico
Williams tend to favor normalizing usernames as late as possible.  In
this case the original client and PAM probably have more information
about what is required than the goo in the middle, and you can win in
cases where you preserve the form the user gave their system but not in
other cases.
Full interop in this second case is probably impossible.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 17 Jul 2013 10:44:33 -0400

Also, note that the important thing is not that applications use UTF-8
for usernames.
It's that they know what character set they are using  and follow EAP's
(lack of) rules when using EAP.

In general, I would not expect an application to encode a username
that's also used in EAP authentication as part of the authentication.

The same username may be encoded in the app protocol in response to
whoami style oppcodes or in response to ACL operations.
But the situation is somewhat complicated by things like SASL
authorization identities and other forms of proxy authorization.

We don't get to place requirements on applications except to say what
they need to do to use EAP.  The protocol requirement for that is that
applications using EAP need to know what character set they have so that
EAP can convert the identity to UTF-8 and so that EAP methods can do any
needed conversions.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Jul 2013 07:56:42 -0700

> EAP can convert the identity to UTF-8 and so that EAP methods can do any
 
[BA] That sounds right.

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Jul 2013 02:02:02 -0400

--On Wednesday, July 17, 2013 07:56 -0700 Bernard Aboba
<[email-masked]> wrote:

> Sam said: 
>> We don't get to place requirements on applications except to
>> say what they need to do to use EAP.  The protocol
>> requirement for that is that applications using EAP need to
>> know what character set they have so that EAP can convert the
>> identity to UTF-8 and so that EAP methods can do any needed
>> conversions.
>  
> [BA] That sounds right. 

I think it is right, with one qualification that might
reasonably be reflected in the document (perhaps as a Security
Consideration).  In the complex world of multiple coded
character sets and models for designing them, there is no
guarantee of a unique, reversible, mapping from any given one of
them to and from Unicode.  There is obviously no problem with
ASCII (or, more precisely, ISO 646 IRV) or ISO 8859-1 because
the Unicode ranges 0020..007F and 00A0..00FF are defined in
terms of those specs.  But, if the CCS used in an application,
is some odd code page, mappings onto Unicode may be a matter of
conventions and judgment, not a standard or universally-accepted
rule.  That problem is further complicated by issues of
normalization and precomposed characters versus composing
sequences, but would exist even without it.

As Sam more or less points out, this is an application problem,
not an EAP one, but the conversion process may lead to
surprising EAP results, particularly including false negatives.

best,
   john

---

From: Stefan Winter <[email-masked]>
Date: Thu, 18 Jul 2013 14:28:55 +0200

Hi,

> EAP can convert the identity to UTF-8 and so that EAP methods can do any

That text sounds pretty good, and is probably all ABFAB needs to say
about this.

I'm still not happy with the i18n situation in EAP; especially that EAP
itself doesn't always know its requirements regarding encoding and
normalization.

I think the basic problem is that identities and other credentials are
eap-type specific and one might expect that neither core EAP nor the AAA
transport have to care about what an EAP method thinks it wants as encoding.
But that isn't true, since at least the Identity part (not the
passwords; I'm not saying these would need to be normalised at all) may
be needed by the EAP method, but they transpire through to the
EAP-Identity and RADIUS/other-AAA User-Names. It's a spill-over effect,
where an EAP method's decisions re encoding and normalisation impose
something on other protocols.

Due to that, an EAP method's way of constructing *identities* needs to
be regulated so that the method, core EAP, and AAA transports can get along.

Nothing of this needs to happen in ABFAB, but I think work needs to be done.

Either by modifying EAP itself to impose a common encoding and maybe
normalisation on EAP-Identity (which in turn forces EAP methods to use
that same encoding and/or normalisation in their "outer" or "only"
phase), or by making sure all EAP methods use an encoding that does not
create problems on EAP core and the AAA layer.

I think this really has "force use of UTF-8" written all over it. The
question for me is which path to take, and where/who does the work.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473