On 16 jul 2013, at 21:42, Bernard Aboba <bernard_aboba(_at_)hotmail(_dot_)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.