Subject: Re: i18n and RADIUS

From: Bernard Aboba <[email-masked]>
Date: Fri, 9 Sep 2011 23:16:03 -0700

It has occurred to me that the most fundamental mistake of RFC 4282 is the assertion that there is a single NAI encoding for every protocol.
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.   EAP and RADIUS implementations can and do carry UTF-8 natively.  The only time a conversion from a U label to an A label would be required would be for a DNS lookup such as what is envisaged in the Dynamic Discovery document. 
That said, issues of internationalization could come up within specific EAP methods.  However,   not all methods utilize the same internationalization mechanisms.  For example, none of the authentication methods defined in RFC 3748 specify the use of SASLPREP, and as far as I am aware, no implementations of those methods (e.g. EAP-MD5) use it.   There is substantial variety in EAP methods defined elsewhere (compare say, EAP-EKE with EAP-TLS and EAP-MS-CHAP, for example).  
Given this, the following sentence in RFC 3748 Section 5 (quoted by PRECIS)  is not just inappropriate (the choice should be left to the method spec), but actually misleading because the methods defined in RFC 3748 do not in fact use SASLPREP. 
   EAP methods MAY support authentication based on shared secrets.  If
   the shared secret is a passphrase entered by the user,
   implementations MAY support entering passphrases with non-ASCII
   characters.  In this case, the input should be processed using an
   appropriate stringprep [RFC3454] profile, and encoded in octets using
   UTF-8 encoding [RFC2279].  A preliminary version of a possible
   stringprep profile is described in [SASLPREP].

Alan DeKok said:
  As discussed at the last IETF, RFC 4282 has some problems.  My draft
(expired) describes the issues, and proposes a way to address them.

  The Precis working group is looking at i18n issues across a wide
variety of protocols.  The framework document applies to RADIUS and to
EAP, though neither is explicitly mentioned:

http://tools.ietf.org/id/draft-blanchet-precis-framework-02.txt

  I'd recommend reading Section 3, which defines stringprep "classes"
for names and secrets.  Section 10 deals with "confusable" strings, and
says that applications need to find a way to deal with them.

  It looks like the work in Precis will allow RADIUS and EAP to continue
with their current way of dealing with names and passwords.  Since
neither RADIUS nor EAP show strings to users, "confusable" strings can
be avoided in the protocol transport.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 10 Sep 2011 15:54:55 +0200

Bernard Aboba wrote:
> It has occurred to me that the most fundamental mistake of RFC 4282 is
> the assertion that there is a single NAI encoding for every protocol.

  I would be wary of defining different encodings for different protocols.

> 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.

>   EAP and RADIUS implementations
> can and do carry UTF-8 natively.  The only time a conversion from a U
> label to an A label would be required would be for a DNS lookup such as
> what is envisaged in the Dynamic Discovery document. 

  Yes.

> That said, issues of internationalization could come up within specific
> EAP methods.  However,   not all methods utilize the same
> internationalization mechanisms.  For example, none of the
> authentication methods defined in RFC 3748 specify the use of SASLPREP,
> and as far as I am aware, no implementations of those methods (e.g.
> EAP-MD5) use it.   There is substantial variety in EAP methods defined
> elsewhere (compare say, EAP-EKE with EAP-TLS and EAP-MS-CHAP, for
> example).  

  I'm not aware of any implementations which use SASLPREP for EAP.
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.

> Given this, the following sentence in RFC 3748 Section 5 (quoted by
> PRECIS)  is not just inappropriate (the choice should be left to the
> method spec), but actually misleading because the methods defined in RFC
> 3748 do not in fact use SASLPREP. 
> 

  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.

  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.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 10 Sep 2011 10:48:57 -0700

>   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.   
>   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 :(
[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
> 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. 
[BA] The EAP methods defined in RFC 3748 do not do that.  However, there are some EAP methods (such as EAP-EKE) that do.  
>   The only changes are dates && idnits fixes.  So the text might not be
[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.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 10 Sep 2011 20:19:21 +0200

Bernard Aboba wrote:
> 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. 

  That's why I wrote 4282bis...

> [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 :(

  The document says that explicitly: No one has implemented the
recommendations of 4282.

> [BA] Rather than doing an RFC 4282bis, I am wondering whether it might
> make sense to recast this as "Internationalization in RADIUS". 

  Having a 4282bis would mean that 4282 would no longer be relevant.
The current document is simple, and has a simple focus.  i18n in RADIUS
might be a longer document.

> 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. 

  The 4282bis document does that extensively.

  Alan DeKok.