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

Tim Cappalli <Tim.Cappalli@microsoft.com> Mon, 02 August 2021 20:32 UTC

Return-Path: <Tim.Cappalli@microsoft.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 67A2F3A1B75 for <emu@ietfa.amsl.com>; Mon, 2 Aug 2021 13:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 RqjJLRr23-xB for <emu@ietfa.amsl.com>; Mon, 2 Aug 2021 13:32:08 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640093.outbound.protection.outlook.com [40.107.64.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4DE3A1B74 for <emu@ietf.org>; Mon, 2 Aug 2021 13:32:08 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XbS3Gl/OSIK8tH3mU89aH8O0MnXcIwoIReDxY9H/IbuI9aGjKY+lg0mWsqVwCpGQHfNZq2DSa6x1pqCwKckqpITnCvaaCJfpembDszq67GtzkGFdLvozNYj1f7iiXkqCH+NJ5Qb4eSph8zH99Ygup82xSPN11DJpP6TM+KWfw4oCEhcCyKn8nNxJxRxcEXp0d1BwVoa2EzDdWcFv4Txn6yMQf7gyInLJgy0yI0nfGjC+sOYRid5GjyVNsAsr9kchP7crQgw2z0ZX3uumiXyDG3hr9gNHhnmyyo8rGgDQnli9dlGMHwT+Eu9SZQPkH5WhaTTLPUqiQw0uVQADJIe5PA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oKJsrfpVw0UgQUVkba4L2TCTz25OR8mwZ3D7/TLmpVw=; b=jewU++7RIZqky1CqS72RWYHen9L5qI8V7ZndlJXCVC2t2XBzB7FDMwk1nEw9pizdLM/4j34yA1I0y73pIEmbbNuePDYYURvYvaniy0UJ5SwWLo3mYoY3N45W9/gqyuwQC4tgYu3rwWGsWUm7g8965aF1FgV90vAd6xs9RrxgMYgiZBE6/VufrKTNdTVjxcC5FmWVG8HY95zaIVwZfRmDa1jg7sq9SbzfzS1eIly/1qTVgw7fp5GQECkuqVdaPHUt2UDZ+ihcL5PPSI76ten/qQhmDmbUjf+vO8raIDk6SKRzkK99xNEUOhH/PGi95gi7ebqYEE+ReB6WCS2O1RoMug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oKJsrfpVw0UgQUVkba4L2TCTz25OR8mwZ3D7/TLmpVw=; b=cEY6Vq8eBHtyJaoyEDMl9WJpaa7kYJs/otsO7l1Y0Hqf4hIQgfcF2KDCXPqpARJ0F/rQ2ibJar5ttFOu/u+p9oz59be8Zx5WWHoH0NUKSy0liPc8U1DstEGzTmhTZjt9G/AL+sQW5k6u5jCANZ+qBNVi5dG/Qak/YkZrI5XKmww=
Received: from CO1PR00MB0996.namprd00.prod.outlook.com (2603:10b6:303:97::16) by MW4PR00MB1132.namprd00.prod.outlook.com (2603:10b6:303:bd::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4419.0; Mon, 2 Aug 2021 20:32:04 +0000
Received: from CO1PR00MB0996.namprd00.prod.outlook.com ([fe80::6dc3:8a93:8f86:e24a]) by CO1PR00MB0996.namprd00.prod.outlook.com ([fe80::6dc3:8a93:8f86:e24a%6]) with mapi id 15.20.4428.000; Mon, 2 Aug 2021 20:32:04 +0000
From: Tim Cappalli <Tim.Cappalli@microsoft.com>
To: "aland@deployingradius.com" <aland@deployingradius.com>
CC: "emu@ietf.org" <emu@ietf.org>
Thread-Topic: [Emu] Identities and draft-ietf-emu-tls-eap-types-03
Thread-Index: AQHXghPUZx++8U9H3kG6COe1gsBotqtbweqAgATzoAY=
Date: Mon, 2 Aug 2021 20:32:04 +0000
Message-ID: <CO1PR00MB0996467D20415461A83119EA95EF9@CO1PR00MB0996.namprd00.prod.outlook.com>
References: <502A7B31-1177-477D-B177-D415BAF67E61@deployingradius.com> <F810992C-CD75-493B-ABFB-F56AB838C90F@deployingradius.com>
In-Reply-To: <F810992C-CD75-493B-ABFB-F56AB838C90F@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-08-02T20:27:43.1691175Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard
authentication-results: deployingradius.com; dkim=none (message not signed) header.d=none;deployingradius.com; dmarc=none action=none header.from=microsoft.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 07a523aa-2766-417b-c9a8-08d955f496f2
x-ms-traffictypediagnostic: MW4PR00MB1132:
x-microsoft-antispam-prvs: <MW4PR00MB1132C62361DDC6CEDDCE7FBE95EF9@MW4PR00MB1132.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pn2j0fyMbHFYuepJEdBZf99O+VUfJD/wHjPMG3ZHY5dVVd2+ntsQHV6lJqa5hzZ/j40RU1pltK7Mb8osQ4NoI2oj3UHxZNlWzEF0F5Noczgvg7tBXQCkXRK9U8gZWyhzMWT1NHhYmv60V0etwk1cxuG49/XJlGESGl+5OYhPHAUqbFqC0v8zCaWoHTy/HXUdMMksMMZjpLddbIfoP+AOsIWUIZpGtfZ0SpaIkUr7Bv0DhmO4uaxj1UUw94VRWqhIykp8tfGhmtkR4gKKDV4IHBXvgo+i1W6ZjhSwoQM7aqUBpYMEeW31udPmYYQ0z40XuQsmw2/9MXo1EbAG3SzV03lLd0A2xKsx7RqJ0yrlqSaOdv7l1x5FioqW5ZaQOnmIlP0I0vfxrG0GBOvxeAMGR61nVrtbyxKkAODrnlPG5b0COfi9lHgX5I4rYoVOzhKUjYDEZ8Xpxff8Rwpq0HCTC//0CTyBIw7HL+uiJPtEvQqWNkZmWO5xMPS7CYF5KW+mmsbQFM7keqB2AxN16W56xQHSbRPOWHn3kyj04bEiaLpu85kTK2/xyHJnc7wdQ8kXWoHjBAj17yUycHfWyclZmESrGITIKab8DfT7JdJlL9BcSj3oGNwkZsLY5xdvyw73r3ODaT5OLEGw6u2ekt6P+173TcG/ycMUjzgnonT7klpHAIXKDMZ5HojyBiMfa0GC1JGwN19cmu/OQgxD53hiUQSNrA20nQ9UpfGRg5NCAkvGD1e2UMR+SWftZtQA6Pyi9b8etAaUtDusG1jjSFI/YRvXeUnMvTup1h2b+tv534U=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR00MB0996.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(64756008)(66556008)(316002)(66476007)(53546011)(55016002)(8936002)(508600001)(4326008)(6506007)(38070700005)(2906002)(5660300002)(91956017)(76116006)(66946007)(66446008)(82960400001)(82950400001)(86362001)(8990500004)(26005)(52536014)(38100700002)(122000001)(6916009)(71200400001)(33656002)(8676002)(186003)(9686003)(966005)(7696005)(19627405001)(10290500003)(83380400001)(166002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?iZSa8Vn79IXxcLYtOP6fJs+eOb4SaQh3c7sOrsu2rqYyVhlTbg02OVmZe275?= =?us-ascii?Q?R6GuU+4tQPogYX7CF9HFeQBJAteW0A4U/kemV8Teq6oNI8Bsx/L8rE7K6LYd?= =?us-ascii?Q?EzXjkll9b4HxWtu7nqI61fdGJTgNDSC8r+Sl9x9RvS+z2QO7jWsIAQX9sjlY?= =?us-ascii?Q?/5ONBM6d/ZjPVq1q4Bffn54iAqqHqrf3OA8J9o+DVq/PcZ9uqNqT25nnEOdr?= =?us-ascii?Q?uGnPNi/pqn/EfzO2/bvHc8e1fw+18VH2Zea7QstxxkcN0tru1yw5/eBtyxOW?= =?us-ascii?Q?0KtnqPUZ+c2/aJ8eQspAk/oMGYKG6ntZ07tM1SxQrfI/ZAakpNtggUKj0igE?= =?us-ascii?Q?1U2p87XRTaHKAeRXgnKeZtjRqsyX70nqncQUZTX5oTBp+7Nd/o96flryN/o1?= =?us-ascii?Q?hpTEw6egpbtAJrni6R/gOBl/fWdfvYPfswJ6J1t4oSb/gO5rpno7cIwtxoQa?= =?us-ascii?Q?OcPsELWuSSvF5gdf+q53evI2/qYmL5DH8xqoco7upIq5DJslkDtl/jrbV8cj?= =?us-ascii?Q?17LnPdyvt9HDuNgXoPBz+NbLj29ef7B4DLVSelTdKzooB+batpSEgmSwZguR?= =?us-ascii?Q?LCawQ440jeF4k9eInEULWzH10hBhV+HyV4dwwFE4q62dy8OaqNqGHSUUd9kV?= =?us-ascii?Q?m+mgOnzWkIN1sBm2RbeDqNPUjFoOvGvqXPHCyXy98QYSeJR+N6bcG+iLwhlX?= =?us-ascii?Q?gaf6ZBYEtR1T94mjPYazXPDGWUtx0o0gOgq5a0zV4kVn/VO1aTtc4ifqXjhC?= =?us-ascii?Q?NQGdHeiYl25kmusx4lN0kZuDAOKYngND1Ox+91R59hmg2td0Ix04zMjJIa/J?= =?us-ascii?Q?lS2dC7e//SNRfsJWtN7v3FIwUtGGypG/rNpf9AJKKterHbYNNBBO5lqAOvHQ?= =?us-ascii?Q?XJbv/ByshJDLM+luTTkoDmSxJKiBoXJQ9UAQIRCHlbQjSo6+nkh5/NCYlz64?= =?us-ascii?Q?ybRYVEZ/Cc6sDeK/xb74WdbAMg8mca+NRJO8+sUjfcRgGbivw4e2QNtBk3xZ?= =?us-ascii?Q?KJmgWDorriTwhs0CXaHEgQAuCsLFlt0+sNkGHQJQNWQXQRnCh8j9GNHtQ35h?= =?us-ascii?Q?+FqwFuZBYs7Ki3WuX1Tpil2r2Az5ojkHo/+AcSHd0ckugJi7smoi8PkxBEco?= =?us-ascii?Q?A2eVJ33sasEgL+wQXB3lI3TA62ZfqzFnGffMdWY+HilKhoqTRXJN1Db8MF70?= =?us-ascii?Q?WK43TJd1ACZG9Xi49rcZaem3OGEqpmOcCWP+UnZzFHHZR3xbBMNAzL0Zl/Sy?= =?us-ascii?Q?L06cUHyzH47dwYUm+nCnUVprm8BVdnA+9GuHwZUf3A=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CO1PR00MB0996467D20415461A83119EA95EF9CO1PR00MB0996namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR00MB0996.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 07a523aa-2766-417b-c9a8-08d955f496f2
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2021 20:32:04.0937 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: g5CYcG6eXSuv67ZFeoVjRbr1IoEOA6tlb58EIIn+UqwU28k7hxOUdP+4qF/9pHwbHtDdmBGkR3obz/8wsZj4Og==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR00MB1132
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/v4XkdIvYusZi3iaOSMlL6cwPmo8>
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: Mon, 02 Aug 2021 20:32:15 -0000

>> 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)

tim
________________________________
From: Emu <emu-bounces@ietf.org> on behalf of Alan DeKok <aland@deployingradius.com>
Sent: Friday, July 30, 2021 12:50:43 PM
To: Alan DeKok <aland@deployingradius.com>
Cc: EMU WG <emu@ietf.org>
Subject: Re: [Emu] Identities and draft-ietf-emu-tls-eap-types-03

  Based on comments from the meeting yesterday, I propose changing the last few paragraphs to this:


Implementations SHOULD NOT use inner identies which contain an NAI
realm.  The outer identity contains an NAI realm, which ensures that
the inner authentication method is routed to the correct destination.
As such, any NAI realm in the inner identity is usually redundant.

However, if the inner identity does contain an NAI realm, the inner
realm MUST be a subdomain of the outer realm.  The inner realm MUST
NOT be from a different realm than the outer realm.  There are very few
reasons for those realms to be different.

For example, if the outer realm is "@example.com".com", then the inner
identity could be "username", or "username@example.com".com", or
"username@students.example.com".com".  However, if the outer realm is
"@example.com".com", then the inner realm cannot be
"username@example.org".org".




> On Jul 26, 2021, at 7:45 AM, Alan DeKok <aland@deployingradius.com> wrote:
>
>  I propose to add a new section which discusses identities.
>
>  As background, an (un-named) vendor recently made changes to their EAP stack.  The configuration for TTLS/PEAP now takes the external (anonymous) identity, and uses that as the inner identity.
>
>  i.e. instead of sending "@example.com" for the outer identity, and "myname" for the inner one, it just sends "@example.com" for both.
>
>  Perhaps unsurprisingly, this causes authentication to fail.  The work-around is to reconfigure the supplicant so that the outer identity is the "real" one.  This has privacy implications, as the inner identity is now being exposed.
>
>  I'm proposing new text which explains some basic ideas about identities, and what should/should not be done.  I don't think that these proposals are controversial, but they are perhaps surprising to some implementors.
>
>
>
> Identities
> ------------
>
> [EAPTLS] Sections 2.1.3 and 2.1.7 recommend the use of anonymous NAIs
> [RFC7542] in the EAP Identity Response packet.  However, as EAP-TLS
> does not send application data inside of the TLS tunnel, that
> specification does not address the subject of "inner" identities in
> tunneled EAP methods.  This subject, however, must be addressed for
> the tunneled methods.
>
> Using an anonymous NAI has two benefits. First, an anonymous identity
> makes it more difficult to track users.  Second, an NAI allows the EAP
> session to be routed in an AAA framework.
>
> For the purposes of tunneled EAP methods, we can therefore view the
> outer TLS layer as being mainly a secure transport layer.  That
> transport layer is responsible for getting the actual (inner)
> authentication credentials securely from the EAP peer to the EAP
> server.  As the outer identity is simply an anonymous routing
> identifier, there is little reason for it to be the same as the inner
> identity.  We therefore have a few recommendations on the inner
> identity, and its relationship to the outer identity.
>
> For the purpose of this section, we define the inner identity as the
> identification information carried inside of the tls tunnel.  For
> PEAP, that identity may be an EAP Response Identity.  For TTLS, it may
> be the User-Name attribute.
>
> Implementations MUST not use anonymous identities for the inner
> identity.  If anonymous network access is desired, eap peers MUST use
> EAP-TLS without peer authentication, as per [EAPTLS] section 2.1.5.
> EAP servers MUST cause authentication to fail if an EAP peer uses an
> anonymous identity.
>
> Implementations SHOULD NOT use inner identies which contain an NAI
> realm.  The outer identity contains an NAI realm, which ensures that
> the inner authentication method is routed to the correct destination.
> As such, any NAI realm in the inner identity is redundant and
> unnecessary.
>
> However, if the inner identity does contain an NAI realm, that realm
> MUST be identical to the outer identity NAI realm.  There is no reason
> for these realms to be anything other than bit-for-bit identical.
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C9d3e525eb5674a6d863708d9537a408f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637632606826401422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qNLewg8EXZzpyJjJi55L9l37uHkPCErKt82nAkiTvYk%3D&amp;reserved=0

_______________________________________________
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C9d3e525eb5674a6d863708d9537a408f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637632606826401422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=qNLewg8EXZzpyJjJi55L9l37uHkPCErKt82nAkiTvYk%3D&amp;reserved=0