Re: [Reap] [saag] PSA: New list for discussing EAP related methods

Bernard Aboba <> Fri, 27 October 2017 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F4FF13F415; Thu, 26 Oct 2017 18:03:12 -0700 (PDT)
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 LflqhgjX0K1x; Thu, 26 Oct 2017 18:03:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23EC613B1A9; Thu, 26 Oct 2017 18:03:09 -0700 (PDT)
Received: by with SMTP id k123so3274508vkb.3; Thu, 26 Oct 2017 18:03:09 -0700 (PDT)
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=QIBA5VZZfftWvy6UxNXhmEz4hpMXVzpnXEwl7PqYZ5c=; b=O50qrm3M671nBDu1sWaabCXg9aFDRspomQajOo8NPUjGjW2ydYqYDOM5jfXX9Ji1X4 qbAbDsMRKqNGG3IhOwtgpbKcN5jsXmhon6QOdzGsSykYUuTea4qxDBMqSWEUnS2AduVx SioKHIWMlLPBEZ7HVw5MNAX6vMRGVv9it1OPwtJI5RlyUOjGfihTop3T3q5P7ZjG8Aev 1Qu3PNZQpm7xSnRuR+0WB0C8SCxcRzQCojOus78TyJgvU/UcqsEaDelj/7q9reE5BtSP Gl4ok4Bu08Hj57eHD/QCfOWgG0xgFyBa+k7o9v/yvVfkmXF9UEHzBSNURASTDCnJLYpZ 2FXw==
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=QIBA5VZZfftWvy6UxNXhmEz4hpMXVzpnXEwl7PqYZ5c=; b=S2h8NGwhn2nCTzPLjAHKlSTtllk9ObQgIDte8RHphPN+DH5W3+paxkLz0anA589Van 3oHg5vB+LQ6cG9Xt77fYN4c9UOUqwm1LcLVKnrBzWa++rGXufMTqMSfVSTYEFhIdQxd6 q+nNAe8+QojumeMDBc0ztjtr+cu8+/meIOGXlLS+cgMkAkfZ3XLyhKt/7Wor6RXd/HlM lPdz2evUaSR2dzVCAKi4FwA8uD658E/O4cE8I3K+QAvUv4TnKeEsnq1IugVFaJ+K4rAk BKNDXl3S2MTcTlII1NT7VWJmSiLANvWWgrQe9ixqrGb6n/dLlYvSsnHcL4UP2hZuW4AE o4tw==
X-Gm-Message-State: AMCzsaU6PbO6CE9v6phBXaF/SPCUMz9fWJfTqvocU6bTbmLuw84idJVT kgMFYnpTnkwFdjA6IEJ+4QkCVvGZ4Kf1/gwtUjY=
X-Google-Smtp-Source: ABhQp+TmvnaGzP3t5oWz4Ksu/4/FEcOhaPP4OvfQSS2DoEwTuqQajkPoXfdnJ9hXVrX3bugO7I1pHUDavIFy+JqpXug=
X-Received: by with SMTP id n190mr4843573vka.26.1509066187988; Thu, 26 Oct 2017 18:03:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 26 Oct 2017 18:02:47 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Bernard Aboba <>
Date: Thu, 26 Oct 2017 18:02:47 -0700
Message-ID: <>
To: Mohit Sethi <>
Cc:, "" <>
Content-Type: multipart/alternative; boundary="001a1144737813e527055c7cdace"
Archived-At: <>
Subject: Re: [Reap] [saag] PSA: New list for discussing EAP related methods
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: Fri, 27 Oct 2017 01:03:12 -0000

I have nothing against TLS 1.3, but it was not necessary to obsolete RFC
5216 to support TLS 1.2 and there are a number of implementations of TLS
1.3 already in progress with no issues as far as I am aware. So I don't
understand why a new document is needed - and the downside is very

Given the prevalence of EAP-TLS in open source, there is great concern over
the introduction of encumbrance into a protocol that is widely required in
high security environments.  Were this to happen, it would in effect impose
a "tax" on each of the 2+ billion devices implementing EAP-TLS.

A cursory search of the IETF IPR database indicates that your draft could
potentially encumber EAP-TLS with a vast number of TLS-related IPR
declarations that would not necessarily apply to an RFC 5216
implementation. While there are  many installations that wish to take on
the costs (and benefits) of TLS 1.3 as well as support for additional
ciphersuites, there are also installations that would not be willing to pay
for the costs of a "forklift" upgrade for every device and server,
particularly if they were forced to migrate off of open-source due to IPR
encumbrance.  Such a migration should be up to the organization deploying
EAP-TLS, not imposed by the IETF without extra-ordinary justification (such
as an unpatcheable vulnerability found in previous versions of TLS).

In addition, the introduction of support for new authentication modes such
as PSK was explicitly rejected by for RFC 5216 in EMU because it
complicated the security analysis and would invalidate existing EAP-TLS
security proofs that were considered critical to deployment in the highest
security installations.  When an organization deploys EAP-TLS today they
know what they are getting - a protocol focused on certificate
authentication that does not attempt to be a "swiss army knife".  Such a
protocol isn't for everyone (indeed, only a small fraction of all EAP
deployments use EAP-TLS), but those that mandate its use have very specific

On Thu, Oct 26, 2017 at 10:16 AM, Mohit Sethi <>

> Hi Bernard,
> The EAP-TLS 1.3 document is a very rough drafty version that was submitted
> before the cut-off for the last IETF. As you rightly point out, it has the
> skeleton and a lot of material from RFC5216, and still many important
> details are missing.
> The purpose of this list is to exactly receive these kind of comments.
> Should RFC5216 be updated or obsoleted by this draft. And it would be great
> if we can have your contributions to the document. We will definitely add
> an acknowledgement section and contact the authors of RFC5216 to see if
> they can contribute and comment. We plan to have more EAP related
> contributions in the near future. We discussed this with the Security ADs
> and thought that a separate list would be appropriate to get
> feedback/criticism and contributions from the folks interested.
> --Mohit
> On 10/26/2017 06:51 PM, Bernard Aboba wrote:
> There are existing functioning IETF mailing lists relating to EAP.
> Why are you starting yet another one?
> From what I can tell, the EAP-TLS 1.3 draft is merely a copy of RFC 5216
> (with no acknowledgement to the original authors) stating that EAP-TLS
> implementations must support TLS 1.3.
> This is ridiculous because there are 1+ Billion existing implementations
> out there that
> On Thu, Oct 26, 2017 at 6:02 AM, Mohit Sethi <>
> wrote:
>> Dear all,
>> We have started a mailing list for discussing new EAP related work that
>> currently has no obvious home. The mailing list is called REAP (Renew EAP)
>> and you can subscribe here:
>> Recently several new EAP methods have been proposed. These include for
>> example:
>> EAP-TLS 1.3:
>> The list serves as a venue for discussion of these and other EAP related
>> drafts that will be submitted in the near future. As courtesy, we will post
>> any new draft to SAAG, but we plan to continue the discussion only on the
>> REAP mailing list. We have also asked for a short presentation slot during
>> SECDISPATCH at IETF 100 in Singapore.
>> Comments, early feedback, and discussion on existing or new work is more
>> than welcome.
>> --Mohit
>> _______________________________________________
>> saag mailing list
> _______________________________________________
> saag mailing listsaag@ietf.org