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

John Mattsson <john.mattsson@ericsson.com> Fri, 18 June 2021 21:23 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 0F4C83A0E5A for <emu@ietfa.amsl.com>; Fri, 18 Jun 2021 14:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, HTTPS_HTTP_MISMATCH=0.1, 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 7npqyTjalkjx for <emu@ietfa.amsl.com>; Fri, 18 Jun 2021 14:23:50 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (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 512383A0E59 for <emu@ietf.org>; Fri, 18 Jun 2021 14:23:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fUcJFd5MCOsHxWfIWBTtoiCI3EbeA6r3Kg4rrT/TDxBZeGZo/bkLN7DVkN452dtemvwjl87rVqqsS1f7n1H5dfXM7HPMesZoP9HelINv+fULpfiSRxhxyJ+GgRXh7tgY77H4msCYOSMor74sJ+sZgBLtK6ZqWXZxrBLkIn3XFSYZYWkjQTjxtwIwGZJLMzq4wP2/b3PJTMZClw/veq6aPHFXFtXmyJp9HVBhEBmhB65+13tCPrEhJXfrQ/7ukPyM0p+rJOItXcRm8cSsMbm/rqxg93DtD3W+KFb0C90CmfYiM1Jv2wNNRa6aTtS7WqohjIVl8WjHzpG2fLqVmAhwmg==
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=y3EKww4Ak5Sa8nvtoWYxP6lVVhAwSAHnz5Fq1nMx0bk=; b=RmfHnx/z8lxr0Db/oRuQHpEYrH8dw2xyvTDbwCLMcDBph1U45Bk5H/AocupQKU2BEov/zNONDNHq5TepriJoCepw2XRldxpVNNqzJeCXSypxJbRRWFyMaHmcHCJDiSk1vHzaL8iQuXiEOOG6rL4UFNFR/EGEYTZ9wuZSA1esBpbnDLrYAZyYUYsBFy+Jg51kMKntTcn/efZaFqbMrKil5UvcLIJ/LNj3/cNlA7URBrzUKBDfsA6LJMn006L0kCKFbm/NL7Gzqr5aNTcuYwMrfjHdzFJBzNFjm1knzBwbrLfys8kmC6OZVfWBjMTWC2TE1h8N+jXe5MuMmiNsmMvMCA==
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=y3EKww4Ak5Sa8nvtoWYxP6lVVhAwSAHnz5Fq1nMx0bk=; b=M3B6zVLlYMb6DLgAhwGYlTHoRK89JaMQYFCgi0TGdvNzpSyEpWMDhADKabkX/69yKWFr+YLmPi6qnWM5LwdVrMnWojfp1wXHaeY8KPQaafK/xjTbTWHmCxRv5TkQYEBAFmqyyinicaEiMrmPmzgOsRKR3PayzED2gq8kE8LPIuI=
Received: from DB6PR0701MB3047.eurprd07.prod.outlook.com (2603:10a6:4:74::7) by DB6PR07MB4248.eurprd07.prod.outlook.com (2603:10a6:6:50::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.14; Fri, 18 Jun 2021 21:23:43 +0000
Received: from DB6PR0701MB3047.eurprd07.prod.outlook.com ([fe80::f0fb:72b:8eac:53e8]) by DB6PR0701MB3047.eurprd07.prod.outlook.com ([fe80::f0fb:72b:8eac:53e8%4]) with mapi id 15.20.4264.010; Fri, 18 Jun 2021 21:23:43 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Joseph Salowey <joe@salowey.net>, Alan DeKok <aland@deployingradius.com>
CC: 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+DY3eNO0q1UEG99SzLd6sPHTYAgAAVRICAA213gIAACPqAgAW8oLaAACDlAIABvZgAgAAOVkk=
Date: Fri, 18 Jun 2021 21:23:42 +0000
Message-ID: <DB6PR0701MB30475BB3FE63914734BD8851890D9@DB6PR0701MB3047.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> <HE1PR0701MB3050725DA65963DCAB065A90890E9@HE1PR0701MB3050.eurprd07.prod.outlook.com> <63475285-E12B-43FA-9340-CCE99B50ECF9@deployingradius.com>, <CAOgPGoA7HgsMPgUJi=2kNp7SMCQsXqted-3MoWcwr90T91E9ww@mail.gmail.com>
In-Reply-To: <CAOgPGoA7HgsMPgUJi=2kNp7SMCQsXqted-3MoWcwr90T91E9ww@mail.gmail.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: 96dda8f1-3997-48b0-7c4f-08d9329f5976
x-ms-traffictypediagnostic: DB6PR07MB4248:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6PR07MB4248EDA7E6D6BFFE7BB89C2C890D9@DB6PR07MB4248.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: XkfOet6zQBeYuS1Zag6TbyOO9bqa5kZfAf6h/+L5VwbB+7bObcs9I5TYfUkWHjks0U2oznAD+YNccTmlhqi7Aw1B2NVEvBrh71pr9eQHmJHWhqSaWwJReZNHz45PMUDePNxWjjA0ewCKYZlHqiK06VRsUW9+GZ2c8QFSMDjM3DjEOAVt0yqy+qdm0xdH8NMmrV2tSIF2dtKeXUsa1y4sGsa7jAMB73ZcCRNDtIu4djI+rEhZkkO2SzYi0wjPgwtvnIPX+x6BEfRZyTw1sg88nVa1h4YSl/5n8WyIjVMdUe6ScxF/uoZWpdYsgEwP9uNVvyp2BTqYizBu1R8YKWS1+m+VtTY/k20uV2F2iD3S5Bg9voXBVaPZwLXVLgVhlzGdOH0r4mNqM6yXDiI7npzYVbHJjDRmRn80LbU0zIExhGi6aBHU/Nxsmkn8BEkvBUr2ycr+2wVbduEkEixJkuPJ1wba5gy9rfH0FUjFkihfYZGHZJX3LjZxZs8A3QOUD0EbvbZZUYk+L87np30vSScGsp6Gjiz01eaPRVu8lC2K9SdbDZnWpFlNmOik4mHyJ6Zj0HyY9+TMIlsx9wcm9GAq4//BQJkFEBkhninhMU5/LbuKXh31Z7guz2ibY/npRre1jGBbi/ZO0aeW5Umf3PGgiCN/Jl7Hvy0btfE4fyqSDLrFZOMiSQTgDtT9/UaAaKCzNECAyfwuBo99iXUD5ZXTRkdMTYf08fNev0722G67xzS+A/C5BSvvWxITRORx9HgQPU7tP8PGa8tkPCgBWaGzFg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR0701MB3047.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(53546011)(8936002)(55016002)(7696005)(186003)(110136005)(4326008)(54906003)(5660300002)(122000001)(44832011)(26005)(2906002)(52536014)(8676002)(966005)(91956017)(9686003)(86362001)(33656002)(71200400001)(83380400001)(166002)(498600001)(76116006)(66946007)(66556008)(38100700002)(66476007)(64756008)(66446008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ijhy0kVE1VdshNF9endcbltBv/2bjgQ2ol0BTj3+IEFa73STvnt38/W+sS8vuW4QezPenpuhM4TbbDmy6nlGHDvEKHP9EzylLDczHYXZstsDTSQNqKzY/0ULBbYl/WdY+vRRHCfZlvia/9qMKDdhyBwDfvnZmCF5WgjgLyDYS9vHzmdrRkfLIEGIDxcFgNQ8zwF09XspPMo0yeJ7uUjLSqvEcMU8O8ob3cJzk8i9WlLFNsDp0M1B9fk6v6ger4E319OkjdPrMl2hfC52Izm3kwKi7WTkyqSBPs8dK5Zu1ICff2TJ49Cfu7sU/2Tcr9trRF1yeDbENRSzDSaozDfobR81asitlZ6v9i/u3uwq41U7yvuIxz7pQy4O3TO/xU35Fk8zEUQ2Ug74WWrzvlsgoifoVrW/a/i6AnGVy0uBXZ0LXDubuqpVAaUbUh9RsWJSTcegVQ24mojLelJOv38yYySid+hkV5QzXeuSJoS41ejnmfAGN13c3IWqeDHKcAEyXoUU8XObeKX+PPTzVLKc70j2yB4ia7I5NiAIWdSVxYKn8asnzP+D5zRPpHh1O5Zs91cPtlHiZMPhXrnpFxZJbUyZ26E8ynzaou8qlnEJJY/eBnQ27b5untUMe5M1UKXu4nKUuoyPY4cTc3TgHufLIx6knrTXFV6sL5V3whR7TC+Way3PyJNPWh+FNVrwqtSl0UkyxYnDPKokwZptudIbQVHcqiuB2eA/1tbpdXMPUc5NlRI5T1/kaxKo1xd10ct+AI5dBaccnhViM2HhpkM9BGUP+r3dbXnJB9D7g0LBEqqgWqq+U3LVUv8aNmsarJ8ANJwhEqu9ThY+bAGP5hkVx7RJI2+Hg+DNKFWdhuLTZOv9w5aHj3xh/cPiiH91oY+br6SWlYLjUK1Uhg4Z8rs3w5cOi6INoSWYt8ee0Ord+uQxCqCrbrG9myeBTIC/N2UVuPAJU5GF+HBXjh6rx8uUjVxZ2idOzoc6pzaI1X1Yd3w/UUmaHZ2bf3bRYUJbfXYM99K1RchzNmI4bVXkubjKqMka7GRLm5qshPZ0Ux1mvcosQ5MLfnRYI6Rfl0voBeb2qVePdeIlWulRjRHaULAuoi0MvXxc3l6C5Bns76fAwSQQPCm0HS/iPjnBGEGis74fTiyC8P9fBJjNVx3AU0mbO4nQ9rGVjR41135Uu0869c4d1nS6cIfnqTZdAFBfjgS/Q4GBjsOdLVAieTxB2tTVvPv94ES/5KymirHz0DGNm/xeHKJE0GB4hnV9jSAtWu223Kh2LIlN/qcyKGH5UCGpYSopNokd4tN+WqR6N48+qsG5MpdFdgyCiYwzgRKkCD6EdNh3DzsbAXKSjtQV2e+TfA==
Content-Type: multipart/alternative; boundary="_000_DB6PR0701MB30475BB3FE63914734BD8851890D9DB6PR0701MB3047_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB6PR0701MB3047.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 96dda8f1-3997-48b0-7c4f-08d9329f5976
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2021 21:23:42.9273 (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: ddeHebFBiesW9MIe3fVAp1LiIEimFSorkuBuDB7ACqNIfdPaBcUv5ZHCwOw9LHTRAwKpOPiwn24cOgzMx7ltbwQDYASigynW9/m6RtIdB2A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4248
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/FRK2JmiFiD46Bh1nGdRhti2bTiU>
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: Fri, 18 Jun 2021 21:23:57 -0000

Hi Alan,

Thanks for your thorough review of version -16. Based on the suggested changes Joe made in GitHub issue #83, I have made commits to PR #83.

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

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




Below is a summary of the suggested changes to section 5 to address your comments:

>From Alan's review of section 5

    Section 5.1 says:

    [4] Cryptographic Negotiation: TLS 1.3 increases the number of
    cryptographic parameters that are negotiated in the handshake. When
    EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
    negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
    groups, and signature algorithm, see Section 4.1.1 of [RFC8446].

    Question: what does this mean in practice for EAP-TLS? i.e. this text
    describes a capability. It does not describe what that capability
    does, or how it benefits EAP-TLS.

Joe: How about:
"[4] Cryptographic Negotiation: The TLS layer handles the negotiation of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic negotiation of AEAD algorithm, HKDF hash algorithm, key exchange groups, and signature algorithm, see Section 4.1.1 of [RFC8446]."

John: I made a commit based on Joe’s suggestion to shorten this down. Having this text is a requirement from RFC 3748 if I am correct.



    Section 5.2 says:

    No updates to section 5.2 of [RFC5216].

    This isn't true. Section 2.2 has substantial new text with new requirements, and new security impacts.

Joe: Add note that "Section 2.2 has additional discussion on identities."

John: I added "Note that Section 2.2 has additional discussion on identities."



    Section 5.3 says:

    While certificates may have long validity periods,

    Comment: Certs issued by public CAs are generally short-lived, as in a year or so. It may be worth discussing this.

Joe: It's not clear what to add here.

John: Alan has a good point here. I suggest just deleting "While certificates may have long validity periods,". There is already text describing that certificates can have very short lifetimes.




    Section 5.4 says:

    Some deployments may permit no peer authentication for some or all
    connections. When peer authentication is not used, implementations
    MUST take care to limit network access appropriately for
    unauthenticated peers

    Q: Are these EAP server implementations? How does an EAP server limit network access for unauthenticated peers?

Joe: This should be address by PR #83 modifications for section 5.6.

John: Yes




    Section 5.7 says:

    There are a number of security issues related to resumption that are
    not described in [RFC5216]. The problems, guidelines, and
    requirements in this section therefore applies to all version of TLS.

    NIT: These requirements are for EAP-TLS, and not TLS. This document does not apply new security requirements to the TLS protocol

    Perhaps instead:

    There are a number of security issues related to resumption that are
    not described in [RFC5216]. The problems, guidelines, and
    requirements in this section therefore applies EAP-TLS when is used
    with any version of TLS.

Joe: This comment should already be addressed by PR #83 or draft 16 text.

John: Yes




    Section 5.7 says:

    If the EAP-TLS server or EAP client do not apply any authorization
    policies,

    NIT: EAP-TLS servers do not apply authorization policies. Perhaps explain that the EAP-TLS server is co-located with RADIUS / Diameter etc, and those apply policies.

    NIT2: It's not clear how an EAP client would apply authorization policies. Perhaps just remove the reference to the EAP client.

Joe: Authorization should be discussed in the authorization section. Perhaps reword paragraph to:

   "The EAP-TLS server or EAP client MUST cache data during the
   initial full handshake sufficient to allow authorization decisions to be made during resumption. If cached data cannot be retrieved in a secure way, resumption MUST NOT be done."

John: I made a commit based on Joes suggestion above.



Cheers,
John

From: Joseph Salowey <joe@salowey.net>
Date: Friday, 18 June 2021 at 22:30
To: Alan DeKok <aland@deployingradius.com>
Cc: John Mattsson <john.mattsson@ericsson.com>, Bernard Aboba <bernard.aboba@gmail.com>, Mohit Sethi M <mohit.m.sethi@ericsson.com>, EMU WG <emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt


On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>> wrote:
On Jun 17, 2021, at 12:04 PM, John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>> wrote:
> 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<https://protect2.fireeye.com/v1/url?k=8c954de0-d30e77f9-8c950d7b-8682aaa22bc0-57cef0b953c698ab&q=1&e=5f99d0b2-df4f-4e46-93ae-df1ccc285e5d&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fpull%2F83%2Ffiles>
>
> - Does PR #83 address the currently listed issues?

  I'll have to go through it and see.  It's normally traditional to respond to reviews.  And, to reply with proposed text for the document update.  That process allows reviewers to quickly see if their issues have been addressed.

  The current use of GitHub makes this process rather more opaque.  There are changes to the document pushed as commits, but it requires rooting through multiple commits and references in order to see which commit addresses which issue.  The many commits of "updated document" make it more difficult to see what is changed, and why.

[Joe]  The github PRs make it easier to view the changes in the context of the document.  I realize there may be a little bit of extra work to associate the changes to the issues, but this should be too difficult to do.

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

  My review of a few days ago had extensive comments.  It may be worth going through that and addressing each issue.  Some of the items have been addressed, which is positive.  However, it looks like all of my comments for Section 5 remain unaddressed.

[Joe] I opened issue 84 (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84<https://protect2.fireeye.com/v1/url?k=27d05bf2-784b61eb-27d01b69-8682aaa22bc0-e47af421c50a8144&q=1&e=5f99d0b2-df4f-4e46-93ae-df1ccc285e5d&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fissues%2F84>) to track this.

I think most of the section 5 issues have been addressed or can be addressed with simple changes.  It's not clear what you wanted to address in section 5.3.

  Alan DeKok.