The question is: this document is about an applicability update, not a>
change of the on-the-wire behaviour of EAP.
[BA] That's right -- which is why I see no need for the applicability update to
depend on RFC 4282bis. It just needs to discuss the applicability aspects.
If we were to try and apply a proper fix to RFC3748 to make Identities UTF-8
everywhere
[BA] We are just talking about core EAP and RADIUS RFCs here.
Internationalization of method-specific identities (and passwords) is defined
by the EAP method specifications, so the "Identities UTF-8 everywhere" is a
much broader topic (and one which I'd argue is not relevant to an ABFAB
applicability statement).
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).
[BA] I would agree with a UTF-8 requirement for EAP-Response/Identities. That
is necessary in practice, because RFC 3579 requires that the
EAP-Response/Identity be copied into the RADIUS User-Name attribute, and RFC
2865 Section 5.1 states that:
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.
Internationalization of method-specific identities and passwords are up to the
methods, so the document can just point this out and say "see applicable RFCs."
Personally, I don't think that the ABFAB applicability statement has to mandate
normalization in NAIs - that would make it depend on RFC 4282bis, and that
doesn't seem necessary to me. Instead, it can just make the reader aware of
RFC 4282bis and say that uses need to conform to internationalization
requirements which are a work in progress.
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