Re: i18n and RADIUS

[Alan DeKok <aland@deployingradius.com>]

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

  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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>