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_ab...@hotmail.com> 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. >> >> >> >> >> >> >> >
