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
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.
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:
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.
--
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
signature.asc
Description: OpenPGP digital signature