Re: [radext] I-D Action: draft-ietf-radext-nai-07.txt

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 24 September 2014 05:07 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BCD1A8A80 for <radext@ietfa.amsl.com>; Tue, 23 Sep 2014 22:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level:
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yo5VUqInjUn for <radext@ietfa.amsl.com>; Tue, 23 Sep 2014 22:07:12 -0700 (PDT)
Received: from BLU004-OMC2S9.hotmail.com (blu004-omc2s9.hotmail.com [65.55.111.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352A91A8A82 for <radext@ietf.org>; Tue, 23 Sep 2014 22:07:12 -0700 (PDT)
Received: from BLU181-W71 ([65.55.111.73]) by BLU004-OMC2S9.hotmail.com with Microsoft SMTPSVC(7.5.7601.22724); Tue, 23 Sep 2014 22:07:11 -0700
X-TMN: [w4Zp/ETaehq1AC22FRN58UX1Sky9bjBZ]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU181-W718EA808CC22B97BBC93E793B10@phx.gbl>
Content-Type: multipart/alternative; boundary="_3381e883-e096-48ab-b1c1-b0d5cf8ab535_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Alan DeKok <aland@deployingradius.com>, "radext@ietf.org" <radext@ietf.org>
Date: Tue, 23 Sep 2014 22:07:10 -0700
Importance: Normal
In-Reply-To: <542210D8.10900@deployingradius.com>
References: <20140923232150.1601.20067.idtracker@ietfa.amsl.com>, <542210D8.10900@deployingradius.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Sep 2014 05:07:11.0482 (UTC) FILETIME=[65D935A0:01CFD7B5]
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/2I9EV9DQf5gCQoQraYJnezvi02Y
Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-07.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Wed, 24 Sep 2014 05:07:14 -0000

I would not say that the revision addresses all concerns.   Some of the advice is quite brittle: 
   For example, much of the common realm routing can be done on the
   "utf8-realm" portion of NAI, through simple checks for equality.
   This routing can be done even if the AAA proxy is unaware of
   internalized domain names.  All that is required is for the AAA proxy
   to be able to enter, store, and compare 8-bit data.
Realm routing based on 8-bit data comparisons has never worked reliably, since it fails even with latin character sets given inconsistent capitalization, let alone when international character sets are used.  Given that normalization on the end system is not common today, blessing 8-bit comparisons for realm routing is a bad idea - since if followed it would be likely to result in continuing problems with routing of internationalized realms. 
In this particular case, there are more reliable ways to do the comparison that should be discussed. 

> Date: Tue, 23 Sep 2014 20:31:20 -0400
> From: aland@deployingradius.com
> To: radext@ietf.org
> Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-07.txt
> 
>   I believe this revision addresses all open concerns.  Maybe we could
> do a last call before the next meeting?
> 
> internet-drafts@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >  This draft is a work item of the RADIUS EXTensions Working Group of the IETF.
> > 
> >         Title           : The Network Access Identifier
> >         Author          : Alan DeKok
> > 	Filename        : draft-ietf-radext-nai-07.txt
> > 	Pages           : 25
> > 	Date            : 2014-09-23
> > 
> > Abstract:
> >    In order to provide inter-domain authentication services, it is
> >    necessary to have a standardized method that domains can use to
> >    identify each other's users.  This document defines the syntax for
> >    the Network Access Identifier (NAI), the user identity submitted by
> >    the client prior to accessing network resources. This document is a
> >    revised version of RFC 4282, which addresses issues with
> >    international character sets, as well as a number of other
> >    corrections to the previous document.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-radext-nai/
> > 
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-radext-nai-07
> > 
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-nai-07
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> > 
> > _______________________________________________
> > radext mailing list
> > radext@ietf.org
> > https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext