[Emu] EAP TLS 1.3 backward compatibility with RFC 5216

Bernard Aboba <bernard.aboba@gmail.com> Sun, 13 June 2021 22:44 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59573A12AD for <emu@ietfa.amsl.com>; Sun, 13 Jun 2021 15:44:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 kxrz1K3_LDoS for <emu@ietfa.amsl.com>; Sun, 13 Jun 2021 15:44:03 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 A0C1F3A12A9 for <emu@ietf.org>; Sun, 13 Jun 2021 15:44:03 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id q20so2997716lfo.2 for <emu@ietf.org>; Sun, 13 Jun 2021 15:44:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TOkgdZxtgtyPCeimlREx4LDcwjnnv1qxZNxqS3jYfWQ=; b=ktRcMZw+PvKfLIX/vEG/aB10BjBrA/N8RFe3PGisDfqRpf4RL78umkI7LQ9LVdxTZN gq37vqGuXXstXOXriVpjj5GKKg1okCnWKivaqyoqKCb1CMeLVwoEAPPE5foSjm9XjBip hUcb3wxLjT3Pn0I4OMuKNEHII01HP2XuFjrZ2GVR06eXLrmnHmPBDYY5TsAiDl3yqmtw x8VqhHOKgPWbe7DZViQMqnX+zWFZgunUMfGGkL2ltRKgyaNLk2GnT2ZogSgWScU8OIlp 5XY8nSNZ5rmYZPwjrhA/ZM/34iLNI9TNW0A1GFfQcQUTzT5w3m8srwbHm0jkZx51fvYa 4f0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TOkgdZxtgtyPCeimlREx4LDcwjnnv1qxZNxqS3jYfWQ=; b=qpuDLCcMV11MUDcg6pQ1pwqpfKS0D11v+s1CTis/SUbLFIwHCtMkhTZJztTcZUyxiR Ze8+edGk/290u2yqaoPkfCD2OXEWUwTXzGh9U8AeKg4NNz8eJ7RBlhbqHe9JnBiWgIEg IU2+wVGXslV3fmNFKwUez0+YRBxWIcI/IO0oxG5lZYxzTceNAuYPFQeWVoyv4IzDpjXu V4YNJjnxat0Bks3vIksPRlkBPHwMYYvrDJRNQ4LT6L5hMc2JUrDjAIgs09nidQSbguRK SeCDAmzVG9dCjFTwb3G8WvSS9DD0+PhNvDy4SRKKR0nEDAbaMaRdj/yTxSiH8t1p1UTT KzMQ==
X-Gm-Message-State: AOAM530VOUL82E7DJbZ8TmziXfXM1WMTNw7uLsT6msLGcaa0OhJAhTLn 150Prp6oY6owcz9oopo3c8U2YNOxvtX1a54Davm7gHX94OU=
X-Google-Smtp-Source: ABdhPJyabY40+zZ5w1c5pyN3sIH6RpQ0qHuRAt60YHF3fOhAzEozFvTMZE8pEcOpDAFfjcO+ryoOLO+vIg4vonYNML8=
X-Received: by 2002:ac2:5493:: with SMTP id t19mr10373098lfk.145.1623624240380; Sun, 13 Jun 2021 15:44:00 -0700 (PDT)
MIME-Version: 1.0
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 13 Jun 2021 15:43:49 -0700
Message-ID: <CAOW+2dv6MMwQHbZCDvEXG1o411KpP6LZ110bWF+s=Wiuw+MTNg@mail.gmail.com>
To: EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000018bf3d05c4ad7a1a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/48LctXlWUigrNVLwhffKMnqfBec>
Subject: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Jun 2021 22:44:06 -0000

draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:

   EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216]
. TLS version
   negotiation is handled by the TLS layer, and thus outside of the
   scope of EAP-TLS.  Therefore so long as the underlying TLS
   implementation correctly implements TLS version negotiation, EAP-TLS
   will automatically leverage that capability.


I am concerned that this statement is potentially misleading. An
implementation of RFC 5216 that negotiates TLS 1.2 and utilizes the key
hierarchy defined in RFC 5216 Section 2.3 will not interoperate with an
implementation of draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and
utilizes the key hierarchy defined in Section 2.3 of that document.

So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2?

The only way this makes sense to me is if it is stated that
draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that
if TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies.