Re: [Emu] Identities and draft-ietf-emu-tls-eap-types-03

Alan DeKok <aland@deployingradius.com> Tue, 03 August 2021 12:20 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3E3A2154 for <emu@ietfa.amsl.com>; Tue, 3 Aug 2021 05:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PjfPaM3fexZo for <emu@ietfa.amsl.com>; Tue, 3 Aug 2021 05:20:04 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BCC3A2155 for <emu@ietf.org>; Tue, 3 Aug 2021 05:20:04 -0700 (PDT)
Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 649D8216; Tue, 3 Aug 2021 12:20:02 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CO1PR00MB0996467D20415461A83119EA95EF9@CO1PR00MB0996.namprd00.prod.outlook.com>
Date: Tue, 3 Aug 2021 08:20:00 -0400
Cc: "emu@ietf.org" <emu@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <010AEE0C-2B4B-456B-8022-5FCEF2D6A5CB@deployingradius.com>
References: <502A7B31-1177-477D-B177-D415BAF67E61@deployingradius.com> <F810992C-CD75-493B-ABFB-F56AB838C90F@deployingradius.com> <CO1PR00MB0996467D20415461A83119EA95EF9@CO1PR00MB0996.namprd00.prod.outlook.com>
To: Tim Cappalli <Tim.Cappalli@microsoft.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/FXpc811gOvyFX05KeJx_gZ5wMoI>
Subject: Re: [Emu] Identities and draft-ietf-emu-tls-eap-types-03
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Aug 2021 12:20:08 -0000

On Aug 2, 2021, at 4:32 PM, Tim Cappalli <Tim.Cappalli@microsoft.com> wrote:
> 
> >> However, if the outer realm is "@example.com".com", then the inner realm cannot be "username@example.org".org".
> 
> I disagree with this requirement. Many organizations have multiple domains used for fully qualified usernames but for routing simplicity, may want to use the org's primary domain for routing.
> 
> It should be perfectly valid to configure an outer realm of @microsoft.com but have inner identities with other domains (ex: tim@github.com, tim@linkedin.com, etc)

  Does this happen a lot?  I must admit I've rarely seen anything like this.

  On top of that, enterprise routing is much rarer than in educational systems like Eduroam.  While enterprise "roaming providers" exist, they're typically not doing 802.1X.  So there's only one identity for them. 

  OpenRoaming is new, and enterprise, and 802.1X.  But it's not widely used, and the identities are typically automatically provisioned.  i.e. to your phone, via the telephone provider.  And there's no "legacy" issues, so the outer identity is for routing, and the inner identity is controlled and provisioned by the provider.

  So I can't think of many good reasons to have different outer/inner realms.  The use-cases are small, and rare.

  I'm OK with not forbidding it.  But I think there needs to be strong language saying "this is a terrible idea, and you really need to think hard before doing anything like this".

  Alan DeKok.