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:59 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 E51081A8785 for <radext@ietfa.amsl.com>; Mon, 20 Jul 2015 05:59:41 -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 fCk-6nzdmP9G for <radext@ietfa.amsl.com>; Mon, 20 Jul 2015 05:59:40 -0700 (PDT)
Received: from BLU004-OMC2S33.hotmail.com (blu004-omc2s33.hotmail.com [65.55.111.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5301A8787 for <radext@ietf.org>; Mon, 20 Jul 2015 05:59:38 -0700 (PDT)
Received: from BLU406-EAS107 ([65.55.111.72]) by BLU004-OMC2S33.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Jul 2015 05:59:37 -0700
X-TMN: [11plWKJYPDz/jLAfYUm1QMOI4dsHwEPE]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU406-EAS10798807662BFBB4E6BE3E393850@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:57:47 +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> <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> <BLU406-EAS922E8820069F5C62F8D5E193850@phx.gbl> <23999_1437395949_55ACEBED_23999_2405_14_6B7134B31289DC4FAF731D844122B36E01CCA48F@OPEXCLILM43.corporate.adroot.infra.ftgroup>
To: "lionel.morand@orange.com" <lionel.morand@orange.com>
In-Reply-To: <23999_1437395949_55ACEBED_23999_2405_14_6B7134B31289DC4FAF731D844122B36E01CCA48F@OPEXCLILM43.corporate.adroot.infra.ftgroup>
X-OriginalArrivalTime: 20 Jul 2015 12:59:37.0973 (UTC) FILETIME=[EF2FBA50:01D0C2EB]
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/zeyhs4WF2X97QJ_A5ZAYg1h4Rcg>
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: Mon, 20 Jul 2015 12:59:42 -0000

On Jul 20, 2015, at 14:39, lionel.morand@orange.com wrote:
> 
> Hi bernard,
> 
> after a quick review, I think I understand your concerns.

[BA] Thanks. 

> I really think that the point is not to make any assumption on the method-specific ID that could be used in EAP-Response.

[BA] Right. The method-specific identity might be in a different format that is not convertible to an NAI (REDMOND\bernarda versus bernarda@microsoft.com). It might be in a different encoding (e.g. Not UTF-8).  The method-specific ID could identify the user while the EAP-Response/Identity might be anonymous. So you can't assume the method-specific ID is a valid NAI suitable for the EAP-Response/Identity or even can be transformed into one.

> I think we can update the text to make it clear.
> 
> To sum-up, I would say that the intention of the draft is to:
> 
> - clarify that the EAP-Response can be used for routing
> - When it is the case, two consequences:
>    -  it may be needed to use different ids to reach different EAp servers, when a single EAP server cannot be used to support all the methods supported by the peer.
>    - a specific encoding of the id encapsulated in the EAP-Response is required to ensure a correct use over RADIUS/Diameter
> 
> Do we agree?

[BA] Those things make sense. You can also point out the bad things that can happen by using method-specific identities in the EAP-Response/Identity (if that is something implementations have gotten into trouble with). 

One other potential relevant point is how RADIUS servers are configured to deal with realms they aren't configured to natively handle. Most of the time those realms are rejected but sometimes the RADIUS server can proxy.

v2.23.0 | Report a Bug | By Email