Re: [radext] [abfab] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt

Rafa Marin Lopez <rafa@um.es> Wed, 19 February 2014 12:32 UTC

Return-Path: <rafa@um.es>
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 4CBBF1A047F; Wed, 19 Feb 2014 04:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level:
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, 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 IVeakirrNeCU; Wed, 19 Feb 2014 04:32:24 -0800 (PST)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 71D691A05A6; Wed, 19 Feb 2014 04:32:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 6D31B3FB60; Wed, 19 Feb 2014 13:32:20 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon21.um.es
Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TU9C1ZrztsuG; Wed, 19 Feb 2014 13:32:20 +0100 (CET)
Received: from inf-205-172.inf.um.es (inf-205-172.inf.um.es [155.54.205.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 662313FB5F; Wed, 19 Feb 2014 13:32:16 +0100 (CET)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <52FDDD10.1050306@restena.lu>
Date: Wed, 19 Feb 2014 13:32:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6347417E-BFC9-426E-B15F-09E9B1C50925@um.es>
References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu>
To: Stefan Winter <stefan.winter@restena.lu>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/SHq3bR1mKmqPGWeZ81oWDuFlXlg
Cc: "radext@ietf.org" <radext@ietf.org>, abfab@ietf.org, "dime@ietf.org" <dime@ietf.org>, "<emu@ietf.org>" <emu@ietf.org>, Rafa Marin Lopez <rafa@um.es>
Subject: Re: [radext] [abfab] 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: Wed, 19 Feb 2014 12:32:28 -0000

Hi Stefan:

I have taken a look to this draft. Regarding the conversion to UTF-8 nothing to say.

Regarding 

"1.  The choice of identity to send in EAP-Response/Identity may have
       detrimental effects on the subsequent EAP type negotiation."

as far as I remember, it was discussed long time ago as a problem of network selection (http://tools.ietf.org/html/rfc5113) See section 2.2. Identity Selection. Your approach here (if I properly understood) seems to allow the user to try all the identities before reporting an error (note that this may imply association/dissociation processes at link-layer to re-start the whole authentication process). The approach there is to provide the user with the required information to select the right username. 

In the particular case of WiFi networks it would be also good to take a look to IEEE 802.11u and hotspot 2.0 (e.g. these slides, which you may already know, are interesting http://www.terena.org/activities/tf-mobility/meetings/26/07-11u-Dave.pptx)

Just my 0.02 cents.

Best Regards.

P.D: Btw, I agree with Alan: it would good to have a "roaming inter-operations" WG. 

P.D.2: Among other things, it would be also good if some information about accessible realms from a NAS could be provided in a dynamic way to the peer. 


El 14/02/2014, a las 10:08, Stefan Winter <stefan.winter@restena.lu> escribió:

> Hello,
> 
> I've just submitted an -00 on a topic that we've been struggling with in
> ABFAB recently (but which exists in every EAP-over-AAA scenario, not
> limited to ABFAB).
> 
> http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapidentity-00.txt
> 
> Abstract:
>   There are some subtle considerations for an EAP peer regarding the
>   content of the EAP-Response/Identity packet when authenticating with
>   EAP to an EAP server.  This document describes two such
>   considerations and suggests workarounds to the associated problems.
> 
> The issue touches multiple areas and working groups (EAP, EAP methods,
> RADIUS, Diameter) so I had to do a guesstimate for a proper home. I
> would think radext is the best match, cc'ing abfab and dime, and also
> emu even though it's shutting down).
> 
> If you recall those in-depth discussions about fixing either EAP methods
> to use UTF-8, or why EAP Identity would need to be restrained to UTF-8
> even if a method doesn't do it, then yes: the draft is about that.
> 
> In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057:
> "Circumstances might require that applications need to perform
> conversion of identities from an application specific character set to
> UTF-8 or another character set required by a particular EAP method."
> 
> Which was enough to get the document through IESG, but this should
> better be fixed more generally for every EAP use case; hence this new draft.
> 
> It's short and concise - I'd appreciate if you could give it a read and
> comment.
> 
> If there's still free time on the agenda, I would also merrily discuss
> it in London.
> 
> Greetings,
> 
> Stefan Winter
> 
> P.S.: Don't miss my other submission about an EAP Configuration File
> Format, which I've been told to submit to ops-area/opsawg:
> 
> http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/
> 
> Annoucement here:
> http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html
> 
> -------- Original Message --------
> Subject: New Version Notification for
> draft-winter-radext-populating-eapidentity-00.txt
> Date: Fri, 14 Feb 2014 00:43:29 -0800
> From: internet-drafts@ietf.org
> To: Stefan Winter <stefan.winter@restena.lu>, "Stefan Winter"
> <stefan.winter@restena.lu>
> 
> 
> A new version of I-D, draft-winter-radext-populating-eapidentity-00.txt
> has been successfully submitted by Stefan Winter and posted to the
> IETF repository.
> 
> Name:		draft-winter-radext-populating-eapidentity
> Revision:	00
> Title:		Considerations regarding the correct use of EAP-Response/Identity
> Document date:	2014-02-14
> Group:		Individual Submission
> Pages:		6
> URL:
> http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapidentity-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidentity/
> Htmlized:
> http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00
> 
> 
> Abstract:
>   There are some subtle considerations for an EAP peer regarding the
>   content of the EAP-Response/Identity packet when authenticating with
>   EAP to an EAP server.  This document describes two such
>   considerations and suggests workarounds to the associated problems.
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> 
> 
> <0x8A39DC66.asc>_______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------