IETF Logo Mail Archive

Re: [radext] Review of draft-winter-radext-populating-eapidentity-01

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 21 July 2015 23:11 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 728BA1AC3FC for <radext@ietfa.amsl.com>; Tue, 21 Jul 2015 16:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3MP-QSj_FxSF for <radext@ietfa.amsl.com>; Tue, 21 Jul 2015 16:11:46 -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 0D8D71A872B for <radext@ietf.org>; Tue, 21 Jul 2015 16:11:45 -0700 (PDT)
Received: from BLU406-EAS34 ([65.55.111.72]) by BLU004-OMC2S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 21 Jul 2015 16:11:44 -0700
X-TMN: [t+bJKntEQ0IIUoaRDhGI2h3JgyWoXaIn]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS346AF21C878460C2F9BC0F93840@phx.gbl>
Content-Type: multipart/related; boundary="_191f66a6-0e5e-49aa-bca5-b5b3b5b100e2_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
Date: Wed, 22 Jul 2015 01:11:18 +0200
References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <tsllhid84gm.fsf@mit.edu> <BLU181-W6B49664DD504DDAF5CC9F93F40@phx.gbl> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <BLU181-W86B005505E6468F75180593F40@phx.gbl> <tsl4mp182ku.fsf@mit.edu> <BA6CBD09-148F-4F8C-9B81-8A4A88B64287@deployingradius.com> <BLU406-EAS343D630A63D85F897C0EC8793F40@phx.gbl> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <BLU181-W94C6FC52C2E3CD666F631A93850@phx.gbl> <55AE9EDF.9000105@restena.lu>
To: Stefan Winter <stefan.winter@restena.lu>
In-Reply-To: <55AE9EDF.9000105@restena.lu>
X-OriginalArrivalTime: 21 Jul 2015 23:11:44.0784 (UTC) FILETIME=[9C7C1900:01D0C40A]
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/pgFFqJLAlciHNi4YCtW7fvFs9tQ>
Cc: "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 21 Jul 2015 23:11:48 -0000

On Jul 21, 2015, at 21:35, Stefan Winter <stefan.winter@restena.lu> wrote:
> 
> And yet, this is what pretty much every supplicant I've seen does.
> Inner ID: john@example.com
> Outer ID: (not configured)
> EAP-Response/Identity: john@example.com
> 
> (again, an example: this is what Windows 7 does if you do not configure Identity Privacy)
> 
> That may be a bad idea (but what's the alternative?

[BA] One thought might be to configure identity privacy by default both on clients and RADIUS servers. Now that we are more privacy aware, why not try to move things in this direction? 

> True, if the format is not what is needed on the routing level, the authentication still won't succeed. However, in the absence of an actual outer ID config, there's nothing an RFC can do to fix this; the user needs to fix his config then.

[BA] Having valid outer config would help too. 

> Encoding (as in: to UTF-8) should always be possible (the EAP peer hopefully knows the original encoding). Again, if the resulting string is not a NAI but a NAI would be needed to route the authentication - time to give up.

[BA] The EAP implementation needs to provide an NAI for the outer identity because the standard requires it. No need to sugar code it - not doing so is broken.
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

v2.23.0 | Report a Bug | By Email