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

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 21 July 2015 22:55 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 66B201B321B for <radext@ietfa.amsl.com>; Tue, 21 Jul 2015 15:55:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=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 lfHw-pXi1LJg for <radext@ietfa.amsl.com>; Tue, 21 Jul 2015 15:55:54 -0700 (PDT)
Received: from BLU004-OMC1S36.hotmail.com (blu004-omc1s36.hotmail.com [65.55.116.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A451A877A for <radext@ietf.org>; Tue, 21 Jul 2015 15:55:54 -0700 (PDT)
Received: from BLU406-EAS411 ([65.55.116.9]) by BLU004-OMC1S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 21 Jul 2015 15:55:53 -0700
X-TMN: [r3OEb7iv1Hdfj5WVj2JG38ztoiMH7YlW]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS411F9192C4EDE4C93E5586493840@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
Date: Wed, 22 Jul 2015 00:54:59 +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> <tslzj2r5aoj.fsf@mit.edu> <BLU406-EAS122D6B206E6EADC5A67F61193850@phx.gbl> <tslwpxv3sx1.fsf@mit.edu> <55AE9BD8.6040909@restena.lu>
To: Stefan Winter <stefan.winter@restena.lu>
In-Reply-To: <55AE9BD8.6040909@restena.lu>
X-OriginalArrivalTime: 21 Jul 2015 22:55:53.0638 (UTC) FILETIME=[658EBC60:01D0C408]
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/J5lbkqms_5jMASS1kElWDj5bhfQ>
Cc: Sam Hartman <hartmans@painless-security.com>, "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 22:55:56 -0000

On Jul 21, 2015, at 21:22, Stefan Winter <stefan.winter@restena.lu> wrote:
> 
> The Win 7 PEAP config allows to configure the method inner identity.
> There's also a separate place for the outer identity.
> However: you can't type a NAI realm in the outer ID box, only a non-NAI
> string.
> 
> What happens when you type "anonymous" as outer ID, and
> "john@example.com" as the inner ID, is that the supplicant will send an
> EAP-Response/Identity of "anonymous@example.com".

[BA] That is bad behavior for sure in both cases. 

> That is, the config options for inner vs. outer are different, yet
> related. The supplicant blends two different config items into one
> resulting string. Hopefully, both are in the same encoding, and
> hopefully, the encoding is UTF-8.

[BA] As they say, "hope is not a strategy". 

> The draft's intention is exactly to move implementations towards UTF-8
> for the EAP-Response/Identity *no matter where they take the string
> from,

[BA] that is a fine goal, well supported by RFC 3748.

> be it from an inner identity, explicit configuration of an outer
> identity, or a blend of the two*. It is not the intention to spill inner
> identities to EAP-Response/Identity if an outer identity is configured.

[BA] Blending the two does not seem like a practice to be encouraged, nor do I recall any one else doing something like that. So pointing at out the potential ill effects as well as the right thing to do seems appropriate.