Re: [secdir] SecDir Review of draft-ietf-radext-nai-10

Alan DeKok <aland@deployingradius.com> Fri, 14 November 2014 14:02 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584DC1A010D; Fri, 14 Nov 2014 06:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3vhDzHUO0o-S; Fri, 14 Nov 2014 06:02:54 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13E581A0120; Fri, 14 Nov 2014 06:02:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6546F22402AF; Fri, 14 Nov 2014 15:02:46 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Htu8odFT-oLE; Fri, 14 Nov 2014 15:02:46 +0100 (CET)
Received: from Thor.local (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 943E8224013A; Fri, 14 Nov 2014 15:02:45 +0100 (CET)
Message-ID: <54660B84.3060905@deployingradius.com>
Date: Fri, 14 Nov 2014 09:02:44 -0500
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yoav Nir <ynir.ietf@gmail.com>
References: <7DF70E98-A89F-4401-B704-DC6FED6FFDB0@gmail.com>
In-Reply-To: <7DF70E98-A89F-4401-B704-DC6FED6FFDB0@gmail.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/77SCuaFCKN3A7Xb6z3d9-zJkrx0
Cc: draft-ietf-radext-nai.all@tools.ietf.org, IESG <iesg@ietf.org>, secdir <secdir@ietf.org>
Subject: Re: [secdir] SecDir Review of draft-ietf-radext-nai-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Nov 2014 14:02:57 -0000

Yoav Nir wrote:
> Some nits:
> 
> In section 2.6:
> 
>    Conversion to Unicode as well as normalization SHOULD be performed by
>    edge systems such as laptops that take "local" text as input.  These
>    edge systems are best suited to determine the users intent, and can
>    best convert from "local" text to a normalized form.
> 
> 
> I think it’s weird to use “laptop” here, as the luggability plays no
> part. “PC” would be better. In fact, I don’t think mobile phones are any
> different in this respect.

  True.  That could be:

... edge systems (e.g. laptops, desktops, mobile phones, etc.) that ...

> The same section says that Edge systems should normalize text, so AAA
> systems should not. It then goes on to say that today edge systems don’t
> always normalize text, so the AAA systems should. That’s a strange way
> to move forward, unless we’re sure that double-normalization does not
> cause problems.

  We can tell that the text is normalized.  So there's no possibility to
double normalize it.

  The problem here is that we WANT edge systems to normalize.  They
should have been normalizing.  We had a discussion about this Tuesday in
RADEXT.  Bernard (as author of EAP - 3579) admitted it was an oversight
that the document didn't say EAP-Identity MUST be UTF-8.

  RADEXT also has interest in working on an EAP document to fix this
issue in EAP.

 So the document has (a) the recommendation for EAP systems to behave
properly, and (b) recommendations for what AAA servers should do until
the EAP systems are fixed.

  Alan DeKok.