Hi Bernard, Patrik, Thanks for the comment. Checking that out now and will get back. Cheers, S. On 07/17/2013 05:29 AM, Patrik Fältström wrote: > > On 16 jul 2013, at 21:42, Bernard Aboba <bernard_aboba@xxxxxxxxxxx> wrote: > >> 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. > > 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 > >> 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. >> >> >> >> >> >> >> >