|
> I would be wary of defining different encodings for different protocols. [BA] Luckily, I believe that all protocols which can carry an NAI are 8-bit clean and support UTF-8, so I think that in practice I am not aware of any network access protocol (including Diameter) that requires punycode encoding of the NAI. However, if such a protocol were to exist, it would have no bearing on the encoding within EAP/RADIUS. That is an important point to make, because RFC 4282 proponents often point to the encoding of an email address in say, EAI, as somehow implyiing that the same encoding needs to be enforced in EAP and RADIUS. That argument is fundamentally unsound, and needs to be laid out clearly. The IDNA documents make much the same point, by stating that the encoding of a domain name in DNS has no bearing on how it is to be encoded in other protocols. But somehow this message has not been clearly stated to apply to network access protocols which are 8-bit clean. > > In reality, the protocol in which the NAI is encoded makes the decision > > about the encoding. Where the protocol is 8-bit clean and requires > > UTF-8 (both EAP and RADIUS fall in this category), the encoding > > described in RFC 4282 does not apply. > > I agree completely. That's been my push for ~4 years. [BA] I believe that this argument is already laid out clearly in RFC 2865, 3748 and other related RFCs, and has been implemented very widely. So this is not just an "opinion", it is a reality which aligns with the RFCs. This unique convergence of reality and standards should be celebrated, not punished :( > I'm not aware of any implementations which use SASLPREP for EAP. [BA] That is certainly true of implementations of the EAP methods described in RFC 3748 (e.g. Identity, EAP-MD5, OTP, etc.). However EAP-EKE (RFC 6124) does reference SASLPREP (see Section 5.1): This protocol supports internationalized, non-ASCII passwords. The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output is the binary representation of the processed UTF-8 [RFC3629] character string. Prohibited output and unassigned code points encountered in SASLprep preprocessing SHOULD cause a preprocessing failure and the output SHOULD NOT be used. > Talking to the various authors (open source && commercial) leads me to > conclude that they treat the user identifier as an opaque string. If > the local encoding is UTF-8, that is used. If it's something else, that > is used. [BA] I believe this is true of the Identity-Response, which is of the most relevance to RADIUS (since it is placed into the User-Name field as noted in RFC 3579). Not sure how individual EAP methods handle this, but that doesn't affect RADIUS. > The existing methods don't do that. But I can see it being useful. > e.g. when a local 16-bit character encoding is used, that MUST NOT go on > the wire. It has to be converted (somehow) into a form that third > parties can recognize. [BA] The EAP methods defined in RFC 3748 do not do that. However, there are some EAP methods (such as EAP-EKE) that do. > I've refreshed my 4282bis document: > > http://www.ietf.org/id/draft-dekok-radext-nai-01.txt > > The only changes are dates && idnits fixes. So the text might not be > perfect. [BA] Rather than doing an RFC 4282bis, I am wondering whether it might make sense to recast this as "Internationalization in RADIUS". Since RFC 4282 is fundamentally wrong in its approach to internationalization, it may be better to focus on explaining why it does not apply in a document that focuses on RADIUS. |