|
> 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 > |