Re: [Reap] [Emu] EAP - TLS 1.3

Bernard Aboba <> Sun, 19 November 2017 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 647E71200C1; Sun, 19 Nov 2017 15:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lRdfAJj2oGNW; Sun, 19 Nov 2017 15:20:37 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CA3312009C; Sun, 19 Nov 2017 15:20:37 -0800 (PST)
Received: by with SMTP id o145so4583719vkd.0; Sun, 19 Nov 2017 15:20:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uy6Aqva3JGxqjO/+FMOghJIh+UYx2DP6JK/A733C4XE=; b=KUmziprSGpqdmzACtInWbkgdLxxzlNjkMlzh7M/ssb81NBTsB2IPUdQ8qzrS+Q3BpD WW3j4v+xGsZ/GewiugDs1NSj9Zw/eSZ0FQfpSLP37MKuv+8w/TmYMYmOtS+lPQ/4QYUn qWaSwQMnZY0vS945W/dpM5jMZdHPrp64afvj8wJa9cD3sKt8OpHmBL7akupjyHPUfy5q SeVatxXHlwHhSkcYSHYZL5zpbg6/D5IjQLK6EBjLowj3fQZdwKIxL7JYC75/+IhXY5If WzTAsfEv5zUNLrKqeA7RIqmhdjbVdFxjvMLPnUVZ+LkDwfayfvPzFIWvzDgYe0BhZHgL 5ppw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uy6Aqva3JGxqjO/+FMOghJIh+UYx2DP6JK/A733C4XE=; b=C0t764zlQLP1rfZqxWQmg3HGgccKEZK6zGiykfkJ8oKseJG46jEihtFoT/t3IczXaV PMkbapEge38PC/c4t93XkcPjuZmOuCYeYQaGjtPb524/soviTP2JRhI2G2WqxAwNArCi fiiCFv1B9s8QQ/jl6+2BHyK8F4SS0OQu2i6VnmpPJNbDzk8FRYpEy22TKdWJj+sVzz+m UekIbnHCJjPfCbO6dLnqoeyTZWeYlfumg+H8F2fM4kWzJz6Zk7hIGzh4fJeSxbMdYLNR 432VzqeJS5q3xB5RUUH9ljtIIUcZoqEeLEMuFewv5eUIniTFwz/7SxRJmJOTg4aUd8Hz 2FwQ==
X-Gm-Message-State: AJaThX5o04XpzW9O6YIwIOYgVyUyxiXJcPC/DH3ej1LrriZVfbyvkFEB dGXNFvVw0xBhAw6T/4SBLzeU1FgnBuBZyFZVj0Q=
X-Google-Smtp-Source: AGs4zMYDN8CLqHBhN2b+jK77nZrQaVYp4Zr16ay6QCdtcJNEqq/V2aw5fFxGpKdtqddg47ntC7RH1B+qFdnuP26No8s=
X-Received: by with SMTP id b196mr5017052vkf.85.1511133635860; Sun, 19 Nov 2017 15:20:35 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 19 Nov 2017 15:20:15 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <00d401d35114$de589760$9b09c620$> <> <> <> <>
From: Bernard Aboba <>
Date: Sun, 19 Nov 2017 15:20:15 -0800
Message-ID: <>
To: Jari Arkko <>
Cc: Mohit Sethi <>,, Security Area Advisory Group <>,
Content-Type: multipart/alternative; boundary="001a11440b3492df7d055e5e37b5"
Archived-At: <>
Subject: Re: [Reap] [Emu] EAP - TLS 1.3
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "REAP \(RENEW\) EAP" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Nov 2017 23:20:39 -0000

The big question is "Why not create a new EAP method"?

The overall intent seems to be to create an pre-shared key EAP method
optimized for 5G, based on EAP-TLS v1.3.

Since the protocol described will not interoperate with any of the existing
2+ billion EAP-TLS devices, why reuse the EAP-TLS code point or EAP-TLS
name?   What has been described is an entirely distinct authentication
method, not a "clarification" to an existing specification.

In fact, from how it has been described, it would appear that the new
protocol is only for use with new devices supporting 5G and new 5G servers
supporting the new method.  In which case, if the new method is not for
general use on the Internet, why can't 3GPP just define the method
themselves and allocate their own private EAP type code?

On Thu, Nov 16, 2017 at 4:02 AM, Jari Arkko <> wrote:

> I don’t want to push the decision in either direction without looking into
> the details.
> But I wanted to point out that there’s usually a third alternative between
> “no need for new documents” and “need a new RFC to describe the new
> version”. Explaining that the old protocol can be used and what the
> implications are may by itself be a useful document. In the specific
> example, is not immediately obvious to me for instance if the security
> consideration would somehow change, or if 0-RTT can or can not be used, etc.
> Jari