Re: [Emu] Consensus call on EAP-TLS key derivation

[Joseph Salowey <[e-mail]>]

On Mon, May 10, 2021 at 10:53 AM John Mattsson <[e-mail]>
wrote:

> I don’t see any strong reasons to keep the -15 key derivation. I started
> to prepare a PR for the likely change back to -13.
>
>
>
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/68
>
>
>
> - Version 15 has the following wrong text that need to change.
> Key_Material can now be kept, but IV should be removed.
>
>
>
>   “the Key_Material, IV, and Method-Id SHALL be derived”
>
>   ”derivation of Key_Material, IV and Method-Id”
>
>
>
> - The IANA table need to change.
>
>
>
> - I would suggest to have the text agreed in -13 stating stating that the
> derivation from Key_Material is the same as in RFC 5216.
>
>
>
>        The MSK and EMSK are derived in the same manner as with EAP-TLS
> [RFC5216], Section 2.3. The definitions are repeated below for simplicity:
>
>
>
>        MSK = Key_Material(0, 63)
>
>        EMSK = Key_Material(64, 127)
>

[Joe] how about  "are derived from Key_Material in the same manner as with
EAP_TLS... "


>
>
> John
>
>
>
> *From: *Emu <[e-mail]> on behalf of Joseph Salowey <
> [e-mail]>
> *Date: *Sunday, 9 May 2021 at 19:54
> *To: *EMU WG <[e-mail]>
> *Subject: *[Emu] Consensus call on EAP-TLS key derivation
>
>
>
> 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.
>
>