Re: [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt
Alan DeKok <aland@deployingradius.com> Sat, 15 February 2014 23:03 UTC
Return-Path: <aland@deployingradius.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 4B0621A02F1; Sat, 15 Feb 2014 15:03:08 -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 4mbIDKgxaEOC; Sat, 15 Feb 2014 15:03:06 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD261A00F5; Sat, 15 Feb 2014 15:03:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D7118224017A; Sun, 16 Feb 2014 00:03:03 +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 Ugd6qGcOh1Du; Sun, 16 Feb 2014 00:03:03 +0100 (CET)
Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 717112240128; Sun, 16 Feb 2014 00:03:02 +0100 (CET)
Message-ID: <52FFF22A.5010802@deployingradius.com>
Date: Sat, 15 Feb 2014 18:03:06 -0500
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stefan Winter <stefan.winter@restena.lu>
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu>
In-Reply-To: <52FDDD10.1050306@restena.lu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/qWSS0YGHILnHULToasp4KrfQj1c
Cc: "radext@ietf.org" <radext@ietf.org>, abfab@ietf.org, "dime@ietf.org" <dime@ietf.org>, "<emu@ietf.org>" <emu@ietf.org>
Subject: Re: [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.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: Sat, 15 Feb 2014 23:03:08 -0000
Some comments: Section 3: ... EAP- Response/Identity does not carry encoding information itself, so a conversion between a non-UTF-8 encoding and UTF-8 is not possible for the AAA entity doing the EAP-Response/Identity to User-Name copying. I'm unsure about this. The EAP-Response/Identity field is *supposed* to be UTF-8. So if it's not, the supplicant is non-compliant, and anything can happen. I think the recommendation here for EAP to RADIUS gateways (e.g. Access Points) is to do as little translation as possible. They should just copy the Identity blob into the User-Name attribute. The next paragraph does explain why this is a problem, but the quoted text above seems misleading to me. The AAA entity *can* copy the EAP-Response/Identity to User-Name. It's just data, so that copying is always possible. Consequence: If an EAP method's username is not encoded in UTF-8, and I would suggest "user identifier", to avoid confusion with User-Name. the EAP peer verbatimly uses that method's notion of a username for its EAP-Response/Identity field, then the AAA entity is forced to violate its own specification because it has to, but can not use UTF-8 for its own User-Name attribute. This jeopardizes the subsequent EAP authentication as a whole; request routing may fail or lead to a wrong destinationi, or the AAA payload may be discarded by the recipient due to the malformedness of the User-Name attribute. That is all true. I would note that the EAP-Response/Identity field does *not* have to be taken from the EAP methods user identifier field. They can be completely different. That should be noted here. Where the EAP methods user identifier field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible string for the EAP-Response/Identity field. How it gets that string is implementation dependent. :( Section 4: Where usernames between configured EAP types in an EAP peer differ, the EAP peer can not rely on the EAP type negotiation mechanism alone to provide useful results. If an EAP authentication gets rejected, the EAP peer SHOULD re-try the authentication using a different EAP- Response/Identity than before. The EAP peer SHOULD try all usernames from the entire set of configured EAP types before declaring final authentication failure. I see why this can be necessary, but it's ugly. EAP peers need to maintain state on the encoding of the usernames which are used in their locally configured EAP types. When constructing an EAP-Response/Identity from that username information, they SHOULD (re-)encode that username as UTF-8 and use the resulting value for the EAP-Response/Identity. If the EAP type is configured for the use of anonymous outer identities, the desired outer identity should also be (re-)encoded in UTF-8 encoding before being put into the EAP-Response/Identity. I would add "or allow the provisioning of an EAP-Response/Identity field independent form the EAP method user identifier" Section 5 It may be worth noting that supplicants should try the most secure EAP methods first (i.e. ones with anonymous outer identity). If those fail, they should proceed to more insecure methods. This prevents leakage. Also, supplicants could cache information about successful authentications. If the system appears to be "the same" as one where EAP method X previously worked, it makes sense to start off with EAP method X. How the supplicant determines that this is "the same" system is a subject for discussion. Alan DeKok.
- [radext] New Version Notification for draft-winte… Stefan Winter
- Re: [radext] New Version Notification for draft-w… Sam Hartman
- Re: [radext] New Version Notification for draft-w… Alan DeKok
- Re: [radext] New Version Notification for draft-w… Stefan Winter
- Re: [radext] New Version Notification for draft-w… Alan DeKok
- Re: [radext] New Version Notification for draft-w… Josh Howlett
- Re: [radext] [abfab] New Version Notification for… Sam Hartman
- Re: [radext] [abfab] New Version Notification for… Rafa Marin Lopez