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