Re: i18n and RADIUS
Alan DeKok <aland@deployingradius.com> Sat, 10 September 2011 13:56 UTC
Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D07121F84CF for <ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com>; Sat, 10 Sep 2011 06:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liW+e-qjr71P for <ietfarch-radext-archive-IeZ9sae2@ietfa.amsl.com>; Sat, 10 Sep 2011 06:56:41 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4F121F84CC for <radext-archive-IeZ9sae2@lists.ietf.org>; Sat, 10 Sep 2011 06:56:41 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.76 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1R2O1S-000Lek-SO for radiusext-data0@psg.com; Sat, 10 Sep 2011 13:55:08 +0000
Received: from [2a01:e0b:1:76:21c:c0ff:fe27:7b54] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <aland@deployingradius.com>) id 1R2O1M-000Lds-MO for radiusext@ops.ietf.org; Sat, 10 Sep 2011 13:55:01 +0000
Message-ID: <4E6B6C2F.3010807@deployingradius.com>
Date: Sat, 10 Sep 2011 15:54:55 +0200
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Subject: Re: i18n and RADIUS
References: <BLU152-W25223C97B2AA7EE62AADE193000@phx.gbl>
In-Reply-To: <BLU152-W25223C97B2AA7EE62AADE193000@phx.gbl>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>
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/>
- i18n and RADIUS Alan DeKok
- Re: i18n and RADIUS Bernard Aboba
- Re: i18n and RADIUS Alan DeKok
- RE: i18n and RADIUS Bernard Aboba
- Re: i18n and RADIUS Alan DeKok