On Mon, May 10, 2021 at 10:53 AM John Mattsson <john.matts...@ericsson.com> 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 <emu-boun...@ietf.org> on behalf of Joseph Salowey < > j...@salowey.net> > *Date: *Sunday, 9 May 2021 at 19:54 > *To: *EMU WG <emu@ietf.org> > *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. > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
