Hi, > Pushing the requirement down to the EAP method won't work IMHO. Further to this: now that I have EAP-TTLS on screen, its words of wisdom about EAP type selection show that it won't work quite clearly. And they are valid beyond EAP-TTLS. Section 7.3 of RFC5281 states: "Note that at the time the initial EAP-Response/Identity packet is sent the EAP method is yet to be negotiated. If, in addition to EAP- TTLS, the client is willing to negotiate use of EAP methods that do not support user anonymity, then the client MAY include the name of the user in the EAP-Response/Identity to meet the requirements of the other candidate EAP methods." This was written for anonymisation reasons; but it applies to i18n as well. If EAP-Type A uses encoding X, and EAP-Type B uses encoding Y, in which encoding should the initial EAP-Response/Identity be sent? One can only hope that all the EAP types which are configured on the supplicant share one common encoding that is allowed in all of them, and that the supplicant chooses wisely. Otherwise the question above can turn into a "does not compute". Sure, a half-baked answer is that the real identity is in a tunnel anyway, and the EAP type is known at that time; but that doesn't cover all cases. EAP-pwd has no tunnel, and needs to rely on the "outer" identity being in a format it can process. There are more untunneled EAP types. Greetings, Stefan Winter -- 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