>>>>> "Stefan" == Stefan Winter <stefan.winter@xxxxxxxxxx> writes:
>> However, I absolutely agree that if an application is going to
>> use EAP it needs to follow EAP's i18n conventions whatever those
>> may be. A rrequirement on anti-causal investigation for current
>> implementation efforts has never stopped us before. I also agree
>> the current document does not speak to this.
>>
>> My recommendation is that we point out the issue. And say that
>> strings used within a specific EAP method MUST follow the rules
>> for that method. If AAA is used, strings used within AAA MUST
>> follow the rules for the AAA protocol in use. We can add an
>> informative citation to 4282bis as a snapshot of current
>> thinking.
Stefan> Pushing the requirement down to the EAP method won't work
Stefan> IMHO. Take as example EAP-TTLS in RFC5281. A full-text
Stefan> search for "UTF" in it yields 0 hits; and a look at section
Stefan> 7.3 ("EAP Identity Information") does not speak of any
Stefan> encodings.
Stefan> IMHO, not being explicit in the EAP spec itself has brought
Stefan> us to the i18n problems we are seeing.
Nah, you'd just be living in a different hell if you'd been explicit in
the EAP spec. I know: other parts of the IETF are in that hell. The
protocols are clear and everything is fine until you realize that the
backend authentication systems you're dealing with are using a totally
different set of rules than the protocols.
That hell sucks too.
Some EAP methods are going to care a lot. They'll care more about
passwords than they will usernames. Usernames are complex because they
can be carried in AAA, EAP identity and within a method.
However, if someone ever does EAP-Kerberos, it's going to have to
specify its own string rules so it can send valid Kerberos PDUs.
MSCHAPV2 had to be compatible with the NTLM hash.
Only the method is in a position to know what strings to send.
We have an unfortunate situation where some methods don't specify. As
you point out TTLS is delightfully ambiguous here. I can point to
similarly annoying deficiencies in the TTLS spec in other areas.
we can write a guidance document for non-standards-track methods that
are ambiguous giving the best advice we can. We can give good
requirements in standards-track methods. TEAP is in last-call now; I'm
fairly sure it gets this reasonably OK, but we should probably check
that.
However, none of the above matters for this document.
We're not tasked with documenting EAP. We're certainly not tasked with
fixing EAP. We're tasked with giving applications requirements for
working with EAP.
I'm fairly sure the requirement is that applications need to do whatever
EAP expects, understanding that there could be more clarity about that.
Applications need to follow the requirements of EAP, of the AAA
protocols they use and of the EAP methods they use.
There's probably disagreement about what those requirements are; we
should not allow this document to be blocked on resolving that
disagreement.