Re: [Reap] EAP - TLS 1.3

Bernard Aboba <bernard.aboba@gmail.com> Thu, 16 November 2017 14:15 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 D590F12954B; Thu, 16 Nov 2017 06:15:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 qsJp_NAnSlnx; Thu, 16 Nov 2017 06:15:15 -0800 (PST)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 413E01293FD; Thu, 16 Nov 2017 06:15:15 -0800 (PST)
Received: by mail-vk0-x233.google.com with SMTP id k82so8465268vkd.5; Thu, 16 Nov 2017 06:15:15 -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=h+gUjhU4N+7Z6jkhAAB97DijI2qcRD1D0kNoWJqJ+dk=; b=d+tWYc4XNWdQL4yn8ALhm4aLHw4rVULAeSMfty7dLNCSUF8PaSuaVfEk0quImhbDVT aenal7UzrIQCYdQB7Wpkjxj806dDZq/m+8mZP+sZTSPyhBRZv/liLgNZeBJYqUBz5SrT cdFnceMhFn5gEQ5XyWGRoOjCq+lvAGSWwjYociHQ3zXLAaX+UjFj0L63079XHKhR6e1B AY5kWvpL86xjzlNePRAnmx3NV/JfJjLLPWQ/dIoLVEwEjVR+e0K11hapWuIFYWsKw2Iv ZUnCiCsZnbTGBAmOAOawt4gAAwedLw9pyoh/KQp6AG0kJz/FDIOMpmh1n5hHhdbm58HX F8OQ==
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=h+gUjhU4N+7Z6jkhAAB97DijI2qcRD1D0kNoWJqJ+dk=; b=Keet7q4tLrJtKFmcfc39SuEJoPS60fxHwYTGIZNh+yhyAGtl9iw8oFTCRF2r+cgZnC 6d5YIL0rqAEjeHh2Bzm1LAw3fNzthsjZNTY2SYHLjO9r7Mfe8JgzREy52t2xPhb9CXb4 blPYDyiQfWhv31H+CBX/AtJXilkYi3ewUWSvD84ODXY2KjOB0KZFkwMDczk821n/gVUM khw6KUlaq71IkzmRtkRHosTnz8l0YWFevJrDXzXvyJwk8zKSGZHmRy7S+TSxHPUrRSS7 334r0SR5oeZbZS/SdQUXnrAomzZvaksmWEPIFol9w/WPlE3fcolx4y9uT4BG1Bh1CVde n20g==
X-Gm-Message-State: AJaThX5yb+VSb7t50xMGAZZaITGxgKYxqlQ1NcSk7kfXZ5vhASDVqpW8 5qO/xa6EmkON+UvVpaeGmGQeEAUSDck6rQ06rxE=
X-Google-Smtp-Source: AGs4zMYoAjhq9OFYkVIn+Yd/6Qu3gOuQHZSufxvG1v64trAya2o3Lh1IfkWIVu1Gu+t76OnE8KvMAQrspptYAndSd8s=
X-Received: by 10.31.13.14 with SMTP id 14mr1257644vkn.24.1510841713957; Thu, 16 Nov 2017 06:15:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.38.130 with HTTP; Thu, 16 Nov 2017 06:14:53 -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 06:14:53 -0800
Message-ID: <CAOW+2dt2FtJzDm3v-66Fkz0goa-Gb7JCw16yr5gwEeSE2+2wdw@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="001a1143835aac1fa5055e1a3fd2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/reap/aXUTS1jDX6DSIyopv6vIET2jzmo>
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 14:15:18 -0000

Alan said:

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

[BA] There are many organizations who have imposed cryptographic or version
policies on their EAP-TLS implementations.  For example, governments
requiring FIPS 140-3 compliance configure their AAA servers to impose that
requirement.  No change to the specification is required for members of
3GPP to configure such restrictions in their AAA servers.

Of course, imposing such a restriction is only practical if you're willing
to deny access to devices that don't implement TLS 1.3. That typically is
only workable in the case of a new service that can only be accessed with
new devices conforming to a new specification.

If that is the situation we're talking about, 3GPP can add TLS
cryptographic or version restrictions to their specifications.  That
wouldn't violate RFC 5216, and it would avoid imposing huge costs on
everyone else.

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