IETF Logo Mail Archive

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

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 20 July 2015 12:34 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 A80CC1A8701 for <radext@ietfa.amsl.com>; Mon, 20 Jul 2015 05:34:02 -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 Z4TtHi3uEQne for <radext@ietfa.amsl.com>; Mon, 20 Jul 2015 05:34:00 -0700 (PDT)
Received: from BLU004-OMC2S36.hotmail.com (blu004-omc2s36.hotmail.com [65.55.111.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4700E1A86E4 for <radext@ietf.org>; Mon, 20 Jul 2015 05:34:00 -0700 (PDT)
Received: from BLU406-EAS122 ([65.55.111.72]) by BLU004-OMC2S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Jul 2015 05:33:59 -0700
X-TMN: [SMAWpd1B+6ot/0pvGJHv2FYumTdTDYHl]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS122D6B206E6EADC5A67F61193850@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: Mon, 20 Jul 2015 14:33:58 +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>
To: radext@ietf.org
In-Reply-To: <tslzj2r5aoj.fsf@mit.edu>
X-OriginalArrivalTime: 20 Jul 2015 12:33:59.0036 (UTC) FILETIME=[59E893C0:01D0C2E8]
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/PQvEWIVLiclWvswnOtIkDo0j52o>
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: Mon, 20 Jul 2015 12:34:02 -0000

On Jul 20, 2015, at 13:29, Sam Hartman <hartmans@painless-security.com> wrote:
> Other implementations request both identities from the user.
> However, I don't know anything that tries to map back from a method
> identity to an eap response.

[BA] Neither do I - it's a bad idea.  That's why Section 4's advice seems so strange:

    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 user identifiers from the entire set of configured EAP types
   before declaring final authentication failure.

[BA] "all user identities" appears to imply using method-specific identities to construct the EAP-Response/Identity.
 
   EAP peers need to maintain state on the encoding of the user
   identifiers which are used in their locally configured EAP types.
   When constructing an EAP-Response/Identity from that user identifier,

[BA] Again, this seems to imply using method-specific identities to construct the EAP-Response/Identity.

v2.23.0 | Report a Bug | By Email