Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

John Mattsson <john.mattsson@ericsson.com> Thu, 17 June 2021 16:04 UTC

Return-Path: <john.mattsson@ericsson.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 CA4E13A2541 for <emu@ietfa.amsl.com>; Thu, 17 Jun 2021 09:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level:
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=ericsson.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 cZ_dxjHtFjiu for <emu@ietfa.amsl.com>; Thu, 17 Jun 2021 09:04:23 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130044.outbound.protection.outlook.com [40.107.13.44]) (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 B93053A253C for <emu@ietf.org>; Thu, 17 Jun 2021 09:04:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZzoYHrOp3RkbFtI8RChgpMpJmJf9S20ynkbGMaomwkdqrFpOZdAOzPZtWHh9noVm+TqlZ0tDuPm05eqnFDzZD/u7htP4xGbycjUjpByHf9TZsM/EXnlh7UJjHTcMM+F6UOObkirmhbmr3GJCpsbiCZW8dNpgofnPAKxmZar+xkr2LHTTRKDYpW3lUFnG3JG9m3eBtAnXJVSvi1y/Wfed+y+373UOaWoEvjxvducZ6wWSo+gnBaBG9d5HwgdPyeZPF21hLroih5Xl6DjvImafI2DvkyUAqlB9NdoFciRtbM6IBvnSz0sULHhRVfnONrp6HlX7ogRml3ocDrZMaVoXyg==
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=LdYv/fXd/OE8+oHRDvIIJwHNlhvIzcVCo+jsyZdMcBo=; b=GNoyGvH2IL8s9ruPwnGHL05mYwCxFsnjDQktAWHpBJhJkrBhH4tF39D8gDoh73R35pjJDgXvpgmLN9GX8nq0BV9YlmeB74HfJtZG3WU4ySwv1+u8w5n/SdGt7jzY5fukN7blMHcgDPZpcJxcFOXyiLFygB280wnn5oO+1U854Mcjosgg++BWDi6ZGYz04bMQmqsI7VbUxtEzH8GzAiNWR5QAtmllKJUQSN74idVD3G8CkCigcdqBbUUDO+jMyZbcA4IqhUjh3/MHWT+4XplgD4UEEGlvUBwOHgD5gzG1D8jukPZq9u1czBBSjus+vpLHZ3gah86Y7EU319Mky1yNlA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LdYv/fXd/OE8+oHRDvIIJwHNlhvIzcVCo+jsyZdMcBo=; b=ZYboQS2rb2EK/csREtq5wZMj6gj5LuEFcir2K6eEvKNwORfoIXCF0wCBSKP4gi1HgU83bqO1u4mvcdPzYDvBdyyGQ8rNjX8SDCMjEB052qeB6NdCnNUXk55h14wiTK1GsotcQ1eFoLcMTU0LYgMZaPIpdlAo2lQfh2MtHV1dm2k=
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com (2603:10a6:3:4b::8) by HE1PR0702MB3546.eurprd07.prod.outlook.com (2603:10a6:7:8d::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.13; Thu, 17 Jun 2021 16:04:19 +0000
Received: from HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3]) by HE1PR0701MB3050.eurprd07.prod.outlook.com ([fe80::b071:a4a:817d:2d3%11]) with mapi id 15.20.4242.018; Thu, 17 Jun 2021 16:04:19 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Joseph Salowey <joe@salowey.net>, Alan DeKok <aland@deployingradius.com>, Bernard Aboba <bernard.aboba@gmail.com>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, EMU WG <emu@ietf.org>
Thread-Topic: [Emu] draft-ietf-emu-eap-tls13-16.txt
Thread-Index: AQHXXscdds+DY3eNO0q1UEG99SzLd6sPHTYAgAAVRICAA213gIAACPqAgAW8oLY=
Date: Thu, 17 Jun 2021 16:04:19 +0000
Message-ID: <HE1PR0701MB3050725DA65963DCAB065A90890E9@HE1PR0701MB3050.eurprd07.prod.outlook.com>
References: <CAOgPGoBXRAABeC_kCcCrsUPC03e8C_GGpzJHB+aWAue5sE=9zw@mail.gmail.com> <4789411B-9D6A-4A33-B465-DCEC2369E671@deployingradius.com> <BA5BC7E9-EC6F-4A10-9F19-284572AF2710@deployingradius.com> <ac3fda5a-65ef-0e57-fdb0-fffdc08bb9e1@ericsson.com> <4F473CF1-CE5C-4834-AF7E-7FCB2457B199@deployingradius.com> <CAOgPGoCoFRF-0uowFiVRtDyWATzr0d3pNKz7DJo5CDBesiDP5Q@mail.gmail.com>, <7B957BC5-DEC4-48D6-A032-C8AC1CBFD210@deployingradius.com>
In-Reply-To: <7B957BC5-DEC4-48D6-A032-C8AC1CBFD210@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 83ac41f6-a947-4dfa-06d9-08d931a99098
x-ms-traffictypediagnostic: HE1PR0702MB3546:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0702MB35463670E03977B212D660C9890E9@HE1PR0702MB3546.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: +8XId8i+8li+5tfL4yaEhS5fwnEvjX7QPSJNr6Q5OCJOsFnQZGGIVa0a5XdJ+/LUJgzqe7l4aPPtEf97ap5QIZHUbCpt6A+LOQXSgwlAVmlL/zanfhIQ1oK4fh5qPu9aEjE4M3NfzL8af5zR3FanabGnZ0APAuIoW4TBUrO74UN3bDpNDH+kQbA3jt+Yv71LtHlkbeqjFd8i0EwV+icV632YmSb/PKbSeVJxH9+mVo4/cyNcldOHL7/ifGksvW1OHruwWDkzGKhnVNMReqwSZ5ks7soZ0Qr+AVPDsneNJHX5Io/UdwqquMr69oOjyOLJ2TsuIcPajweQkZLtN7RoXMRCDcLdJjSvFodTVrAZ4oU8GDBaG6wJZTHoYqAYZRMhXrZ1+8i7PuHhBYCu9Bg1HGl2mzkgtxHI7hXLi7QmCEWN+U30T+59/SvPo7o2XCgSgXqSsC6g7KjOfVE8mbCHSSviHYp2vvlrssgnYxDi4iqxFkEfeq8grTxlgl0GkToVOkdxtQ2XI8UH5d/64oEK/QIQe2bwJbp3gpn3woKqpG7tsorJlAlyNxJCSSBh5DCy8PeK/yQbCa61VtI6YJojDaXRgNzivoIVuKWPswAEZx0llhHnyu5sqnht5RrGkyrFqf/bfESnzFB5ZaxlJiZv+sTlBkIKcg5tJZh6emplRV4rAKJQZ4SxMPV23H85Js6K/vBOtEauJVj1iztyqeYL4YYKQQP8276ezIOndt+4Ua6fDS9rozLiUwhcBgRmwf59P4eehw7FbUqzdrfDT1vHuVCKjQtqCmeOeBygR9GkNxqEXax8gORCBXxYJ3pZkDWA
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0701MB3050.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(136003)(376002)(346002)(39860400002)(64756008)(8676002)(166002)(66476007)(76116006)(966005)(66446008)(66556008)(33656002)(66946007)(52536014)(7696005)(8936002)(86362001)(478600001)(316002)(18074004)(110136005)(2906002)(38100700002)(53546011)(5660300002)(55016002)(26005)(122000001)(71200400001)(6506007)(9686003)(186003)(44832011)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?mlJXJjNMmTJ+In77lPjqygBD02B/AB5Gj3jAeelXmaYBJCa+ZF5/LiI1d4bW?= =?us-ascii?Q?iweOMYjP1fS13Dzm4dLx2BouZqqM+00lqF83jYvp+Mf59tismMpl5KgboF+j?= =?us-ascii?Q?mXVwjYUlYf7jBeo+vn2sqXsfnx4/KITlsRLUHYrQi9se5Ja3RUGs0bi5DDUA?= =?us-ascii?Q?uBZ7QMW2fxpiklzq+kZYFjeSHlbEH9wKdmWg6e5r88SQvi43FHGYn3Lr3oW8?= =?us-ascii?Q?sfURXkzzr0oS5Uw8GXc+k9qZLcxrVxSPY3T9CQldq5vN/yucsLVRWBVM+d8M?= =?us-ascii?Q?2Yui1FmkMNzo/k0zyB0XRtr7G4t4BYDK3koCDYTIZJHUqxdrAYMaihv/7fxJ?= =?us-ascii?Q?tg54xlrJfm0Awf6ACQcOXYMvkSdEDYwGLd8QIfxVIlZFuHefbAIC1Zy+Z90C?= =?us-ascii?Q?o2ANIMSBdjv4c/sqB9BMibUot7EkpVwSGmScwZbfsgS+AXINPJhWt93bfHHQ?= =?us-ascii?Q?ntVYZJENVvxS+RYUgc7ES2NjCYolbMz1G9hRtrRY5HKBPwjQ0D8Oh8FEnesT?= =?us-ascii?Q?QHZYhPoIC8y+Vrl6bXbc7G1rm2k5da9KeVXlVTrsI3bCv/jPNalMpj6OheaU?= =?us-ascii?Q?CqbFKxMehWuv60/i/8zsVOODseUo7a/3mpuFH+d6HvRr8lg8ndZ04IbM0sUo?= =?us-ascii?Q?Pj4oxvbS1fw6JMwMHLbPTsuhgYaodjG8Xzh7HHoTMk7hRK/hOFZoRn5rfBYT?= =?us-ascii?Q?M6wALxk+f0nTHeeOnsTFt3MIn+KEAkJc6bfsTQf4cTyzgxCrMrVFV4iSKzG+?= =?us-ascii?Q?nTqZka7AhW6L7P8KEPj1OArCXBg5kD5DCe8q/7gWezpnH4ILTGeQwFc7zYOD?= =?us-ascii?Q?ubusjx8IasCwGBjVKCCzSUkAs72GpFTncc70jRGuuvm74rMqxs3hQBcYyMaR?= =?us-ascii?Q?5RyrVk81QnhiSGJHVREpUi/BDUZpuU5Y6oKAdtHsRYeJAT53pNWUlnQWdATT?= =?us-ascii?Q?7PzzJ9UY0zMvB0qqzlxIN0Ap0anGeX7ciblWzOaWw17tPo8j1mngxkA7Tf6l?= =?us-ascii?Q?gRL4BqKhJvmcIx8CecTyyDJR9xyKZ/HoxSHR96IATYfRNZ1hrl9gDtP4dH12?= =?us-ascii?Q?Xmee11ktpfCnoqrGfHwiSIiOk8l0cj+gK3KSrweigTtv7dF688aR3GKx2Ujy?= =?us-ascii?Q?znpUsJMnnu87ZnVGmTFHyoCKF5vu8jyxzCr4tMb1W4jTVJ3z3zvPRsb/llcB?= =?us-ascii?Q?odWNqv3WRf4QxJW+BZQzgOc56QJcJbhoPlSKW9sVf3ORBg5ovlP8JDj+AgiH?= =?us-ascii?Q?Eao7XleEYB1Sdh1JK1QLrdtiawTwBo1jbAtuJWWDgpStw/5Jrm//FjgUGoJq?= =?us-ascii?Q?YtNNAfnMHoM2xwBIbapPYZJV86ai35+d0X9a+hloUfteuQ=3D=3D?=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB3050725DA65963DCAB065A90890E9HE1PR0701MB3050_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0701MB3050.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 83ac41f6-a947-4dfa-06d9-08d931a99098
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2021 16:04:19.3582 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: aDQ5HNryunN1gEaJCbZITg0vLedjAi6nCvr5x0qm9ZNvoc7FyDQ0iH/cyY3KQE2XMhC+e9fT+JBx+qt74wMNDwM0RVsDRHTzl7N2zPgLkPI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3546
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/qwptWJBTSxddnnTyJfECFAQ7Gwg>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt
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: Thu, 17 Jun 2021 16:04:28 -0000

Hi,

Thanks Joe for making such very clear and concrete issues on GitHub!

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues

I have made a single PR addressing all the currently listed issues in the way suggested by Joe.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files

- Does PR #83 address the currently listed issues?

- Are there any other remaining issues that are not listed on GitHub?

Cheers,
John

From: Emu <emu-bounces@ietf.org> on behalf of Alan DeKok <aland@deployingradius.com>
Date: Monday, 14 June 2021 at 02:22
To: Joseph Salowey <joe@salowey.net>et>, EMU WG <emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt
On Jun 13, 2021, at 7:49 PM, Joseph Salowey <joe@salowey.net> wrote:
> [Joe]  The existing text already refers to relying on the underlying TLS version negotiation.

  Yes.  I was trying to address the confusion between version negotiation and other handshake negotiation.

> [Joe]  I don't see a problem with covering new TLS handshake messages in the document, however they are covered somewhat inconsistently.  Perhaps we should cover them all in a "new handshake messages section".

  My point was that if the EAP layer doesn't need to do anything with those new handshake messages, then there isn't a need to mention them in the specification.

> TLS 1.3 introduces several new handshake messages including HelloRetryRequest, NewSessionTicket, KeyUpdate.  In general, these messages will be handled by the underlying TLS libraries and are not visible to EAP-TLS, however there are a few things to note.
>
> The HelloRetryRequest is used by the server to reject the parameters offered in the ClientHello and suggest new parameters.  When this message is encountered it will increase the number of round trips used by the protocol.

  If that's the only change, then I would suggest there's no need for a section dedicated to HelloRetryRequest.  Perhaps just saying "there are a number of new messages in TLS 1.3 which affect round trips, but the EAP layer doesn't have to do anything other than exchange more TLS messages".

> [Joe]  OK how about adding:
>
> "An example of limiting network access would be to invoke a vendor's walled garden or quarantine network functionality."

  Sounds good.

> >>   I don't understand why it's necessary to include discussion of TLS negotiation in EAP, when that negotiation does not affect EAP in any way.
> > See above.
>
>   In short: TLS version negotiation does affect EAP-TLS.  HelloRetryRequest messages do not.
>
> [Joe] The EAP TLS layer needs to know which TLS version was negotiated.  HelloRetryRequests affect the number of round trips in the exchange, but are opaque with respect to EAP-TLS.

  Yes.  I was confused at Section 2.1.6. which essentially says "HelloRetryRequest is a new TLS message, here's a diagram of using it with EAP-TLS".   As an implementor, the immediate question is "What do I *do* with this message?"  and the answer is essentially "nothing".

  Pretty much every other section in the document says "this is new in TLS 1.3, and here's how to handle it".

> [Joe]  HelloRetryRequest is a feature of the underlying TLS library so the RFC8446 Should determine the underlying behavior, specifying a different behavior is problematic.

  Sure.

> >>   The updated text is clearer, but still does not address some of the questions raised below about calling this out as a new requirement from 5216, and what happens in an HA environment.
> > Please let us know a good reference to "implementation and
> > interoperability experience." about the upper limit on EAP packet
> > exchanges. This would also be useful for draft-ietf-emu-eaptlscert.
>
>   I posted references on this list previously:
>
> https://mailarchive.ietf.org/arch/browse/emu/?qdr=y
>
> [Joe] I think this is the wrong link.

  Yes.  The new mail archive interface is substantially worse than the older "mailman" interface.  It's difficult to follow threads, quickly search by dates, etc.

  In any case, this is the previous message:  https://mailarchive.ietf.org/arch/msg/emu/y3d6KGFeImAeSLEqF6XqVMev2Zc/

> >>> Requiring a supplicant to be configured with a peer name is a new requirement from RFC 5216, and isn't called out as such.
> > I agree with you that we could benefit from more clarification on
> > relationship between section 2.2 and 5.2 of this draft vs. the old RFC
> > 5216. Do you have a suggestion how best to split the text and reflect
> > the updates to RFC5216?
>
>   Updating 2.2 with a note after the text on page 18 seems best:
>
> While this requirement to verify domain names is new, and was not mentioned in [RFC5216], it has been widely implemented in EAP peers.  As such, we believe that this section contains minimal new interoperability or implementation requirements on EAP peers.
>
> [Joe] This does not seem to add to the specification.

  I agree that text doesn't add any new requirements to the specification.  However, it's useful to make a note for implementors that while Section 2.2. is officially a new requirement in theory, there is little to do in practice, because implementations already meet these requirements.  There has been similar text in many other specifications.

  Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu