[radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery
"radext issue tracker" <trac+radext@trac.tools.ietf.org> Sun, 23 December 2012 00:42 UTC
Return-Path: <trac+radext@trac.tools.ietf.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3698D21F8A53 for <radext@ietfa.amsl.com>; Sat, 22 Dec 2012 16:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.666
X-Spam-Level:
X-Spam-Status: No, score=-102.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbfoHVsnC5gK for <radext@ietfa.amsl.com>; Sat, 22 Dec 2012 16:42:39 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC3521F8A4D for <radext@ietf.org>; Sat, 22 Dec 2012 16:42:39 -0800 (PST)
Received: from localhost ([127.0.0.1]:52047 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+radext@trac.tools.ietf.org>) id 1TmZeC-0006zb-Cj; Sun, 23 Dec 2012 01:42:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: radext issue tracker <trac+radext@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, bernard_aboba@hotmail.com
X-Trac-Project: radext
Date: Sun, 23 Dec 2012 00:42:32 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/147
Message-ID: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org>
X-Trac-Ticket-ID: 147
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org
X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: mikem@open.com.au, stefan.winter@restena.lu
Resent-Message-Id: <20121223004239.7EC3521F8A4D@ietfa.amsl.com>
Resent-Date: Sat, 22 Dec 2012 16:42:39 -0800
Resent-From: trac+radext@trac.tools.ietf.org
Cc: radext@ietf.org
Subject: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: radext@ietf.org
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Dec 2012 00:42:40 -0000
#147: Internationalization and draft-ietf-radext-dynamic-discovery Currently the internationalization advice provided in Section 2.3.1 appears to differ from that provided in RFC 4282bis, creating potentially unpredictable interactions. Dynamic server discovery as defined in this document is only applicable for AAA transactions where a RADIUS server receives a request with a realm for which no home RADIUS server is known. [BA] Does this paragraph really apply to RADIUS servers and not proxies? Typically a server will only check the realm and see if it represents a realm it is serving; if not an error is flagged. Asking RADIUS servers (not proxies) to route for realms for which they are not authoritative seems dangerous. Also, the meaning of "no home RADIUS server is known" is not clear. According to RFC 4282bis, only bit-by-bit comparisons are supported in the AAA infrastructure. As a result, were a client to not provide a normalized realm, the resulting failure of the comparison would trigger use of dynamic server discovery. Is this what is intended?? Section 2.3.1 Note well: The attribute User-Name is defined to contain UTF-8 text. In practice, the content may or may not be UTF-8. Even if UTF-8, it may or may not map to a domain name in the realm part. Implementors MUST take possible conversion error paths into consideration when parsing incoming User-Name attributes. [BA] This would appear to contradict RFC 4282bis requirements for realm normalization and realm correspondence to a legal FQDN. Although Section 2.2 does mention conversion to punycode, the exact steps to be performed are not described: It is expected that in most cases, the label used for the records is the DNS representation (punycode) of the literal realm name for which the server is the RADIUS server. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | dynamic-discovery@tools.ietf.org Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: In WG Last Call | Keywords: -------------------------------------+------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/147> radext <http://tools.ietf.org/radext/>
- [radext] #147: Internationalization and draft-iet… radext issue tracker
- Re: [radext] #147: Internationalization and draft… Stefan Winter
- Re: [radext] #147: Internationalization and draft… Stefan Winter
- Re: [radext] #147: Internationalization and draft… Sam Hartman
- Re: [radext] #147: Internationalization and draft… Bernard Aboba
- Re: [radext] #147: Internationalization and draft… Stefan Winter
- Re: [radext] #147: Internationalization and draft… radext issue tracker