Re: [Reap] EAP - TLS 1.3

Bernard Aboba <bernard.aboba@gmail.com> Thu, 16 November 2017 06:12 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 E5A761294D8; Wed, 15 Nov 2017 22:12:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.493
X-Spam-Level:
X-Spam-Status: No, score=-0.493 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_NONE=-0.0001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no 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 HmVIdAPy1uI9; Wed, 15 Nov 2017 22:12:51 -0800 (PST)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 510BF129521; Wed, 15 Nov 2017 22:12:51 -0800 (PST)
Received: by mail-ua0-x22c.google.com with SMTP id f14so7877688uaa.5; Wed, 15 Nov 2017 22:12:51 -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=ShP3e3tUxe2Mt0Jg+VAaS8zAl4mfnisRhQqnBeYACMQ=; b=bC5Oj94BsIr/O8FKFDTWDis/8GWO4imDKzUvBnbEnbvSugHpxqe0Bhom7EpU5Ck8ne Em5npfOBvDOUTU6EbNYlgWnhkv5SqIl24g9EQQgaJ96b/HjDj379ffsuqwVac5fPWnoJ vwoTtAaOPK8YN5SVxhj1qi/wcpEYPcL93IBhK2oeDs+vPBDUDDEyQ9Edxn7SAY0XVdno on87CiGP6W8LyWZIjV5Ba2CGwcShg/wIJYxowChBqSs8JnZAcWl8YffxoOGDtKLpen+0 JN7RwwuSozmLCUKejLdpXwozirhreFcXwmj2d4OgEhu5vWqM8hVhwLQs+f+g7XCmnP60 JeGw==
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=ShP3e3tUxe2Mt0Jg+VAaS8zAl4mfnisRhQqnBeYACMQ=; b=PQrrgU6YOqQn+ZwMxpn7OJ/IkiAtHsrWFzjbC8Q2cSnuq0MvVgZJJklIXclBtDugcB kNr2mAqVNV7jlxHsDHI5nrHLQaAY2rwFMEDcD+fqqisDcuqsoDF7js7REMmbGpeU9hlv +AraxWhnsQZmM9eNG+DEg6L9eWQ03kSdzLFoGpDw1UVgJWoTdBLCH05VsiRbqC8O/sUe e0p3bnA1CjPA2BJldThWi74pATNQvlknCb6RoqQmzfi+jT22olxtselC0c/7Ad0vxiDu 18s+VPloWTUURkh4z9SoGsraSSmSc1Hp6INHlpV0PG476FLsdbwJnScogkf3Wf+VSv3K x9+g==
X-Gm-Message-State: AJaThX52qXTYEi+ln/AfqMCr7rk++1E0ncrgepsC/leTKVGL0vmsbcbm o/o0X+5JSE8IuUD3DPDKeZG3AjRG69/gK9YmMzo=
X-Google-Smtp-Source: AGs4zMbpS3Lszz06wLVp8a4NdSFeLak/EkMixO4Bs4Zd1CO9s2vaFDsiRMBTh6SKuWA5YCJU+eApQz/Ztc/wVXrQy4w=
X-Received: by 10.176.20.225 with SMTP id f30mr447813uae.66.1510812770197; Wed, 15 Nov 2017 22:12:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Wed, 15 Nov 2017 22:12:29 -0800 (PST)
In-Reply-To: <c740099f-4635-0853-5542-3d02eadf6ead@ericsson.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>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 15 Nov 2017 22:12:29 -0800
Message-ID: <CAOW+2ds2CwkogUJz-p8TRMdWs283BVhvrJWqFj1Upm9=8RboCg@mail.gmail.com>
To: Mohit Sethi <mohit.m.sethi@ericsson.com>
Cc: Jim Schaad <ietf@augustcellars.com>, Security Area Advisory Group <saag@ietf.org>, emu@ietf.org, reap@ietf.org
Content-Type: multipart/alternative; boundary="001a1145ab007d661f055e138206"
Archived-At: <https://mailarchive.ietf.org/arch/msg/reap/9Tfmk_8NlRBHHLJKVe1lfc_L7jA>
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 06:12:54 -0000

   - RFC5216 is very much tied to the message flows and message formats in
   TLS 1.0 - 1.2.

[BA] EAP-TLS encapsulates TLS within EAP so the basic protocol flow is not
version dependent.  The (non-normative) examples were designed to
illustrate the EAP-TLS protocol flow, so though they are based on TLS
1.0/1.1 (1.2 came later) that doesn't affect the protocol.

   -  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 and in the worst
   case, implementations would not even be compatible.

[BA] While the TLS protocol changes with version 1.3, the basic flow of the
EAP conversation (and EAP-TLS) does not change - it's just a tunneling
protocol that takes TLS blobs and encapsulates them in EAP.  As a result,
there are already experimental implementations of EAP-TLS based on version
1.3 that required minimal code changes in EAP-TLS. Do you have an
implementation of EAP-TLS that supported earlier versions?

   - 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.

TLS 1.3 Section 7.3 defines how the keys are calculated - and so the
TLS-Exporter changes should be straightforward.

   - RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0".

[BA] Support for TLS v1.0 is required for backward compatibility.  EAP-TLS
has been deployed on over 2+ billion systems and is supported by a hardware
ecosystem. Many of those existing implementations would be broken if the
requirement to support TLS v1.0 were to be removed.  So while any
organization can decide they only want to allow a given version of TLS, the
requirement to support 1.0 must remain.

   - 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).

Those ciphersuite choices were based on the need for backward
compatibility.  An organization mandating more advanced versions of TLS
will automatically inherit the mandatory ciphersuites of those versions.
So this doesn't preclude interoperability of EAP-TLS 1.1, 1.2, 1.3 or any
future version of TLS.

On Wed, Nov 15, 2017 at 9:16 PM, Mohit Sethi <mohit.m.sethi@ericsson.com>;
wrote:

> Hi Bernard,
>
> 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.
>
> 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 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.
>    - RFC5216 specifies that "EAP-TLS implementations MUST support TLS
>    v1.0".
>    - 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).
>
>  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.
>
> John and Mohit
>
>
>
> On 10/30/2017 10:37 AM, Bernard Aboba wrote:
>
> RFC 5216 only insists on support (not use) of TLS 1.0 and its mandatory
> ciphersuites in order to ensure interoperability with legacy
> implementations and avoid an Internet-wide “flag day” requiring millions of
> hardware devices to be replaced. But if a site wants to impose a TLS
> version (and ciphersuite) policy, it can.
>
> Mandatory to support algorithms apply to a TLS version, so EAP-TLS
> inherits them when that version is negotiated. Similarly, EAP-TLS inherits
> features of each TLS version - all it does is tunnel TLS.
>
> Given this, I am puzzled as to why it is being proposed that RFC 5216 be
> recycled at Proposed in a non-backward compatible manner with vast new IPR
> encumbrance, completely new authors, and nearly identical text, rather than
> being left alone or moving to the next standards level.
>
>
>
>
>
>
>
> On Oct 29, 2017, at 5:20 PM, Jim Schaad <ietf@augustcellars.com>; wrote:
>
> There is one advantage that can be obtained by using TLS 1.3, if you want
> to hide the client name then it is no longer necessary to do an anonymous
> connection followed immediately by a re-negotiation with the proper client
> certificate.  But that and perhaps mandatory algorithms is the only think I
> can think of right off the bat.
>
>
>
> Jim
>
>
>
>
>
> *From:* saag [mailto:saag-bounces@ietf.org <saag-bounces@ietf.org>] *On
> Behalf Of *Bernard Aboba
> *Sent:* Sunday, October 29, 2017 3:59 PM
> *To:* Randy Bush <randy@psg.com>;
> *Cc:* Mohit Sethi <mohit.m.sethi@ericsson.com>;; Security Area Advisory
> Group <saag@ietf.org>;
> *Subject:* Re: [saag] [Reap] PSA: New list for discussing EAP related
> methods
>
>
>
> Randy asked:
>
>
>
> "bernard, for the clueless here, what change is needed for tls 1.3?"
>
> and
>
>
>
> [BA] None as far as I know. EAP-TLS makes use of TLS version negotiation
> so it is both forward and backward compatible. So far, implementations of
> RFC 5216 based on TLS 1.3 have not demonstrated any EAP-related issues, as
> far as I am aware.
>
>
>
> In general, EAP-TLS can leverage TLS policies the administrator chooses to
> impose.  So  if the administrator wants to impose a version policy (e.g.
> TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4),  there
> are a number of EAP servers that can be configured to support this.
>
>
>
> So rather than attempting to impose an Internet-wide TLS version or
> ciphersuite policy (which would impose a huge cost on everyone, given that
> there are 2+ billion devices supporting EAP-TLS), it makes a lot more sense
> to let the administrators decide, possibly based on guidance from
> organizations they trust, such as NIST.  This is how things have been
> working for more than a decade.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush <randy@psg.com>; wrote:
>
> > Creating a separate list has real drawbacks and very little in the way of
> > benefits.
>
> bernard, for the clueless here, what change is needed for tls 1.3?
>
> randy
>
>
>
>
>
> _______________________________________________
> saag mailing listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag
>
>
>