Re: [Emu] Consensus call on EAP-TLS key derivation
I am in favor of the switch back to draft-13 key derivations.
Jorge Vergara
From: Emu On Behalf Of Joseph Salowey
Sent: Sunday, May 9, 2021 10:54 AM
To: EMU WG
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
Re: [Emu] Consensus call on EAP-TLS key derivation
On Mon, May 10, 2021 at 10:53 AM John Mattsson
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 on behalf of Joseph Salowey <
> j...@salowey.net>
> *Date: *Sunday, 9 May 2021 at 19:54
> *To: *EMU WG
> *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
Re: [Emu] Consensus call on EAP-TLS key derivation
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)
John
From: Emu on behalf of Joseph Salowey
Date: Sunday, 9 May 2021 at 19:54
To: EMU WG
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
Re: [Emu] Consensus call on EAP-TLS key derivation
On May 9, 2021, at 1:54 PM, Joseph Salowey wrote: > > 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. We should revert to the -13 key derivations. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[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
