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