Re: [Reap] EAP - TLS 1.3

Bernard Aboba <bernard.aboba@gmail.com> Thu, 16 November 2017 13:56 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: reap@ietfa.amsl.com
Delivered-To: reap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736C51293F3; Thu, 16 Nov 2017 05:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nQPVxqFkSu6N; Thu, 16 Nov 2017 05:56:46 -0800 (PST)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC69126C2F; Thu, 16 Nov 2017 05:56:45 -0800 (PST)
Received: by mail-vk0-x22b.google.com with SMTP id b7so16556921vkh.12; Thu, 16 Nov 2017 05:56:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TABAMLXA0H2f2C+KvuNuE5eVolyDDQ7CPP/BB4YEd5A=; b=tHxD5iK1vIsKBq1UbVGm20nAGffTWgfuVJwZatt7SC1MtGTUlLmlsf7/ezpwLHfrKL 8mGdFKyyD0oivIREkIu4I6rhpWYDk2fqbrrDTnxKjIi8Ypb8zQZI/KhDBNm5mQu4whlt l8F6ptw6Hx1Frz+9pBTC7gIqVCZjf449nBC+G1bDeew69BfhGxAMpZ/y5C8b/Plfme7O rjJ4WhrzB7lwi0AHxQvyY0lps3ckNyJYccjdr7BigN09/eisPCbRSQ1nBN54HeWI/4Hk 4BWDwdYf6N+GW2NqfUqvvaHJkyjy0sxdp8LvlPiohUQBmwmRx8PMfRqO12ir8Nrv31ln Nmlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TABAMLXA0H2f2C+KvuNuE5eVolyDDQ7CPP/BB4YEd5A=; b=GrvpKoB2OsoU3SQWIluFmx+9f4IMrMcNvGE0BWVY5u4LSKcc11WsXs2sX/5hdsyyVC IN/GXTI0VbFEtYxVFTdAzJjBNbVqZd9Ga/Q009Kn/qZgHUF+/8Qwxy9OsILxc70mBf6D 6kMe0akEylJY3SUhewJvxSueSjCVeEmgTqM6M9r00NBUiYtGOuIAqx4xoSmU3qZQUbVE qKS2+ioUN2IxC1IGFxOpEngvWwll6Su1hYZUl22rULAfOjfyxI4PH4ktoHuux4RBZJzx OFgeEQ1sTLQA1SygA5KWIYPTBKWPl7zAckggRxZG/m42DZExB903gfl7Xe4Fa4QOTY+8 TLJQ==
X-Gm-Message-State: AJaThX6K9FqHRtdWT7yi6Db0GgcrSW6QrlP/gxl46fkoNEc0nqOlY4C0 0hNkLm03B5bbew8C4QIAl/hZgQhxP14leKy20pg=
X-Google-Smtp-Source: AGs4zMafyGUjUMVtGq2OBBrWFpwNj7q9a37xGDy5EhQsq1JbR13rfb4yx8/SjZh+z1xNoPk/fTT1sVTjemv3iugSM6I=
X-Received: by 10.31.13.14 with SMTP id 14mr1182174vkn.24.1510840604353; Thu, 16 Nov 2017 05:56:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Thu, 16 Nov 2017 05:56:23 -0800 (PST)
In-Reply-To: <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com>
References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <CAOW+2ds9Sez7otrs682hqzzXR8qbJYAdPwW8A8TEL+ms_a0=UA@mail.gmail.com> <ACE2CDE6-4D04-4049-BB15-1E82C214A553@gmail.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <CAOW+2dtzq4d5p3JxwbbdwHqrS+0TpRveJkGb3vYzmdmLVvdcFQ@mail.gmail.com> <m2d1558xyi.wl-randy@psg.com> <CAOW+2du+teg8nicw6eDoSCKx_ZfAAXKtpLb0ogPUTk1Bzr1n_A@mail.gmail.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <c740099f-4635-0853-5542-3d02eadf6ead@ericsson.com> <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 16 Nov 2017 05:56:23 -0800
Message-ID: <CAOW+2duO+NSqhHUmWHg1powzWg7LLxZaurTaVo98EF4ZW1TA_Q@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: Mohit Sethi <mohit.m.sethi@ericsson.com>, Jim Schaad <ietf@augustcellars.com>, reap@ietf.org, Security Area Advisory Group <saag@ietf.org>, emu@ietf.org
Content-Type: multipart/alternative; boundary="001a1143835a8905dc055e19fdb2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/reap/-hABbGm9ThMRBnCLo8wn5-ua3wE>
Subject: Re: [Reap] EAP - TLS 1.3
X-BeenThere: reap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "REAP \(RENEW\) EAP" <reap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/reap>, <mailto:reap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/reap/>
List-Post: <mailto:reap@ietf.org>
List-Help: <mailto:reap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/reap>, <mailto:reap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 13:56:49 -0000

Alan said:

"That's good.  But as Bernard points out, there's no need to change
EAP-TLS.  You can just use TLS 1.3."

[BA] Existing implementations enable organizations to impose TLS version
and ciphersuite requirements on *their* devices.  For example, I have
worked with organizations that require FIPS 140-3 support, who impose those
cryptographic requirements through policy. Of course, such a constraint may
bring with it the need to upgrade EAP-TLS clients and AAA servers - but
that cost is imposed *only* on the organization imposing the policy.

 "I think one of the concerns here is the procedural aspect.  Your proposal
was to forbid everyone *else* from using TLS 1.0 because your requirements
were for TLS 1.3.  That's not the way to gain support."

[BA] The proposal would force the replacement of 2+ billion EAP
implementations along with millions of smartcards and other hardware that
is incompatible with TLS 1.3.  It would also make every EAP-TLS
implementation subject to patent declarations on later TLS versions.  A
search through the IPR declaration database discloses a horrifying number
of declarations that would apply as a result.

A proposal imposing such extraordinary costs requires extraordinary
justification.  So far, I am not aware of a declaration from any standards
organization or authority that versions of TLS prior to 1.3 need to be
phased out.

"In addition, your other arguments are hand-waving, and don't provide
concrete details to back up your position.  Having concrete details would
help."

[BA] So far, I read the argument as "Someone implementing EAP-TLS from
scratch with TLS 1.3 might not get it right."  But given the *huge* number
of deployed devices out there, we need something much more concrete - like
test data demonstrating a real interoperability problem.

On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok <aland@deployingradius.com>;
wrote:

> On Nov 16, 2017, at 12:16 AM, Mohit Sethi <mohit.m.sethi@ericsson.com>;
> wrote:
> >
> > Coming back to our motivation for this draft. 3GPP has decided that
> authentication in 5G can be done with any type of credential that the
> operator accepts and that EAP will be used for authentication. The working
> assumption is that EAP-TLS will be used for mutual authentication with
> certificates. 3GPP would likely want to use TLS 1.3 as much as possible,
> especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in
> EAP-TLS as well as providing encryption of the handshake including the
> certificates.
>
>   That's good.  But as Bernard points out, there's no need to change
> EAP-TLS.  You can just use TLS 1.3.
>
>   I think one of the concerns here is the procedural aspect.  Your
> proposal was to forbid everyone *else* from using TLS 1.0 because your
> requirements were for TLS 1.3.  That's not the way to gain support.
>
>   In addition, your other arguments are hand-waving, and don't provide
> concrete details to back up your position.  Having concrete details would
> help.
>
> > If the EAP community decides that RFC5216 adequately describes how to
> use TLS 1.3 and does not need an update we can live with that. Our
> conclusion is however that an update of RFC2516 is needed for several
> reasons:
> >       • RFC5216 is very much tied to the message flows and message
> formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.3
> is very different. While a developer could theoretically figure out how to
> use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216
>
>   How so?  5216 says (essentially) "encapsulate TLS within EAP".  How,
> exactly, does this change with TLS 1.3?
>
> > and in the worst case, implementations would not even be compatible.
> >       • TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS
> 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update
> defining the Key Hierarchy in terms of the TLS-Exporter (similar to what is
> done in draft-ietf-quic-tls) is needed.
>
>   Implementations of EAP-TLS do need to change when the key derivation
> changes.  Such as for TLS 1.2.  However, those changes are largely limited
> to the TLS library, not the EAP-TLS code.
>
> >       • RFC5216 specifies that "EAP-TLS implementations MUST support TLS
> v1.0".
>
>   You're free to deprecate TLS 1.0 in documents which update RFC5216... if
> you have IETF consensus.
>
>   Further, you're free to mandate use of TLS 1.3 in 5G specifications.
> They're your specifications, and you're free to ignore IETF requirements if
> you so choose.
>
> >       • RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC,
> and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS
> version).
>
>   The same comment as above applies here.
>
> >  If IETF does not provide new message flow diagrams for EAP-TLS with TLS
> 1.3, it is likely that 3GPP will do that, we would much rather see an IETF
> RFC that 3GPP and other can refer to.
>
>   What, exactly is different with the message flows in EAP-TLS when TLS
> 1.3 is used?
>
>   Please be specific.
>
>   Alan DeKok.
>
>