Hi, > [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). Indeed; sorry for the imprecise use of "everywhere". What needs to be tackled is EAP's "outer" or "only" identity (for methods that don't have the luxury of sending a different identity in their method-specific payload). >> 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: You are conflating AAA with RADIUS. EAP-Response/Identity can be used in other contexts; I heard that some use Diameter instead of RADIUS, so any reference to RFC2865 would not apply there. And if I write MyOwnAAAProtocol and require EAP Identities in EBCDIC encoding in my equivalent of User-Name, then that's my thing alone and RFC2865 has nothing to say to me. The EAP supplicant doesn't know which AAA is going to be used behind the authenticator; so how would it know whether to use EBCDIC or UTF-8? Unless, of course, there is a place outside of RFC2865 which forces me to accept/use exclusively UTF-8. An update to RFC3748 stating that comes to mind. > 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." As stated elsewhere in the thread, the initial EAP-Identity needs to be sent before the EAP method is negotiated. > 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. This is a cliffhanger text with a forward-reference into the future. I could live with a statement like that, but ... ... just listing 4282bis is not enough; EAP identities don't have to be NAIs - if we state that applications need to conform to that future RFC, and they read things in it like "This document only defines NAIs, if you don't use NAIs, there's nothing in it for you" - then implementations have a way too easy loophole to not care about i18n; they can just say: oh, we don't use NAIs. It's all unstructured identities; any presence of an @ in there is just coincidence. I could live with it very well if there is a promise to continue the cliffhanger situation with an all-encompassing update that covers all EAP Identities; be they NAIs or not and be they transported over RADIUS or not. I.e. if we can agree that updating RFC3748 with stricter i18n rules is going to be chartered work and will happen, then I can live with a cliffhanger statement of "stay tuned for that update" in the eapapplicability draft. Greetings, Stefan Winter > > > > > > 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 >> -- 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
Attachment:
signature.asc
Description: OpenPGP digital signature