[radext] Fwd: New Version Notification for draft-winter-radext-populating-eapidentity-01.txt

Stefan Winter <stefan.winter@restena.lu> Mon, 27 October 2014 12:11 UTC

Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id AFC721A9237 for <radext@ietfa.amsl.com>; Mon, 27 Oct 2014 05:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id e70l79FekEK4 for <radext@ietfa.amsl.com>; Mon, 27 Oct 2014 05:11:55 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D41C1A9173 for <radext@ietf.org>; Mon, 27 Oct 2014 05:11:51 -0700 (PDT)
Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9A264403B7 for <radext@ietf.org>; Mon, 27 Oct 2014 13:11:49 +0100 (CET)
Message-ID: <544E3685.6010906@restena.lu>
Date: Mon, 27 Oct 2014 13:11:49 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
References: <20141027115149.1961.53790.idtracker@ietfa.amsl.com>
In-Reply-To: <20141027115149.1961.53790.idtracker@ietfa.amsl.com>
OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
X-Forwarded-Message-Id: <20141027115149.1961.53790.idtracker@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NmlP671J998g1f5PsdiJk3tPRt4wRRC5k"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/Fq-1HS3QIbsy5Ts0gpDhM13SSnY
Subject: [radext] Fwd: New Version Notification for draft-winter-radext-populating-eapidentity-01.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: Mon, 27 Oct 2014 12:11:58 -0000


just to let you know that I've updated my "homeless" draft regarding the
interplay of EAP methods, EAP-Response/Identity and the AAA User-Name field.

As per the discussion at IETF90, I have removed the claim that
intermediate proxies or pass-through authenticators might drop the
packet due to malformedness as this has not been observed in the wild.

The general point in that regard, the possibility of mis-routing the
packet due to different interpretations of the content by intermediate
systems, is still as valid as it was before :-)

There was a comment about RFC3748 and RFC3579's identity hints in
EAP-Request/Identity which could help alleviate one of the two problems
in the draft (client has multiple identities to choose from; and EAP
negotiation is not enough for an exhaustive try).

The provisions in RFC3579 are not sufficient to solve the problem, because

* EAP-Request/Identity is optional in some scenarios; peers can (and at
least in the Wi-Fi case, typically *do*) initiate the conversation with
their EAP-Response/Identity (EAPoL-Start) immediately; i.e. they make
the identity selection at a point in time where no hint is available

* EAP-Request/Identity may be sent by the NAS instead of the EAP server,
and the NAS may not have all identity hints available if it is part of a
large multi-operator network (e.g. if a roaming consortium contains
thousands of realms, while the NAS only has a "Default Route" to a

* The piggybacking of identity hints in EAP-Request/Identity after a NUL
separator is in general a horrible hack. It is bound to fail *at least*
in a situation where the list of acceptable realms gets longer than 1020
octets (which is a tiny amount when again looking at a roaming
consortium with thousands of realms), see RFC3748 section 5.1. So even
if the NAS or a RADIUS server has the full list of realms, it may not be
able to send it.

A much more general solution than trailing bytes in an optional Request
packet are needed, unfortunately.

Also, none of this removes the second problem which the draft addresses,
namely the requirement of UTF-8 encoding for the EAP-Response/Identity.


Stefan Winter

-------- Forwarded Message --------
Subject: New Version Notification for
Date: Mon, 27 Oct 2014 04:51:49 -0700
From: internet-drafts@ietf.org
To: Stefan Winter <stefan.winter@restena.lu>lu>, Stefan Winter

A new version of I-D, draft-winter-radext-populating-eapidentity-01.txt
has been successfully submitted by Stefan Winter and posted to the
IETF repository.

Name:		draft-winter-radext-populating-eapidentity
Revision:	01
Title:		Considerations regarding the correct use of EAP-Response/Identity
Document date:	2014-10-27
Group:		Individual Submission
Pages:		7

   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