[Emu] Consensus call on EAP-TLS key derivation

Joseph Salowey <joe@salowey.net> Sun, 09 May 2021 17:54 UTC

Return-Path: <joe@salowey.net>
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 1F1CD3A1828 for <emu@ietfa.amsl.com>; Sun, 9 May 2021 10:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=salowey-net.20150623.gappssmtp.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 M8jnPCQvhFIo for <emu@ietfa.amsl.com>; Sun, 9 May 2021 10:54:25 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 665C23A1826 for <emu@ietf.org>; Sun, 9 May 2021 10:54:25 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id x2so19950882lff.10 for <emu@ietf.org>; Sun, 09 May 2021 10:54:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=O3qEr56ZPY6ARuDF7T6+9D8AdnexER5rMarO6ZFCzeQ=; b=Psg957ukUEZCqRfHhoI23HFAyM7zsjcUATJ2lYjsgBpYEeIZmWk7Au8RlO9HHXGPUn IDXoQYBUcTjHYX3Ff9JrTk9WFLpk/ll+k+inmfroLkrU7xQ550x2F1rh9dDcPA942z8V oKGx7vzf6fZYu5dtewfBOhnBlx9C1bVoEOzZGn15VKNNrI41el0DI8IP+IZ3U7Akd+lr JRsiv6rBHQmQX/T2qonXqJ0Qpj54Y9D8nnyRisD9NQj1dzS66nIv5d70+vTr4g1Wi18X LBXbngpgYMQJzXorHgo185bIB/ElsuwC7+D8QYpdfnLE0vtAU0XiL9hdHlrxSbnib0pl /Y1g==
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=O3qEr56ZPY6ARuDF7T6+9D8AdnexER5rMarO6ZFCzeQ=; b=ZvB26Dd7P+pgJWYW6folBRZGU56arZwjZXH4aQhUWHmJn4rxyDYuXL/pflVp96/bVb 5b9bpBQ2lzLzpNX0q/oIhbrnEsvnaevuIBleu0fxicwlC66wQrAVNae9kPNmPhr84VAK +svG/IIn8Qpi7MOJkIJ5EzXJz6ipp0YAsfWb1aWXfAHNTXmFzDBweHedgvax8wsoYLa5 dXfojyDc0ptd33HBYqcJXfBhw0IywwUeDBvn4+pQww5nbKINfDbJGnJefN6ar0Z5Oo3J 9QK9WDUlqF8bayD1wHA6xL1n/dDhZAZNoB8suRCUtApmT0pIpXl4qvdoAzka8IJhJyXg XzIg==
X-Gm-Message-State: AOAM530zNd12vtT3JYeAohAsxbqXv0FI9iACuXVy8tlfKmQfE93cRbrd nNd9LOduuBMbLXtgW50H9w9yJ7Vd9IRNvkwzWyf4AG82tCG0quNx
X-Google-Smtp-Source: ABdhPJws7X46kjXbCoG8sCg1dnFmq2G7OQ6F7Mk1Y1SHZhViO1H5qCYQMPgfriWx1sUKB6rHgreq5fDSNk23/TgUOg4=
X-Received: by 2002:ac2:4907:: with SMTP id n7mr14302059lfi.194.1620582858163; Sun, 09 May 2021 10:54:18 -0700 (PDT)
MIME-Version: 1.0
From: Joseph Salowey <joe@salowey.net>
Date: Sun, 09 May 2021 10:54:05 -0700
Message-ID: <CAOgPGoDtd2HAG8RrpLAZ8XQoiyXpJNz2k6+CAyxU2+gnbqEwjg@mail.gmail.com>
To: EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000971f0f05c1e9599e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/lYVuq_vXsY3C_5GkVyl2fvhwm8Q>
Subject: [Emu] Consensus call on EAP-TLS key derivation
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, 09 May 2021 17:54:28 -0000

We had discussion on the list on whether to include context in the key
derivation, but we never closed on the issue of separating out the MSK and
EMSK derivation.  As a result several implementers have gone down the path
of implementing what is in draft 13 and not separating out the derivation.
The main difference is that draft 15 separated out the EMSK and MSK
derivation using two different labels while draft 13 used a single label to
derive key material which is partitioned into two keys.   The reason for
the change was to enable different access control for these two different
quantities for different callers, however in practice it is EAP-TLS
application which needs access to both keys that is the caller of the TLS
library so this separation is not particularly useful.   Therefore the
recommendation is to align with implementation and derive the MSK and EMSK
by partitioning the key material from the key material produced by a single
label of the exporter function.

Please respond to the list if you support the change below or not to revert
some of the text in the key derivation section.  If you object to the
change please state why.  Please respond by May 20,2021.

Thanks,

Joe

The proposal is to use the following key derivation which is largely a
reversion to draft 13:

Draft-15 Text:

Type-Code = 0x0D

MSK        = TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
EMSK       = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
Session-Id = Type-Code || Method-Id


Proposed New Text:

Type-Code = 0x0D

Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
                               Type-Code, 128)

MSK          = Key_Material(0, 63)
EMSK         = Key_Material(64, 127)

Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Type-Code, 64)

Session-Id = Type-Code || Method-Id


The rest of the text of the section remains the same as draft-15.