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

[Jorge Vergara]

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] WG Last Call for Using EAP-TLS with TLS 1.3

[John Mattsson]

Hi Meiling,

In version 15 the group decided to go back more or less to how things worked in 
version 13 where protected TLS application Data 0x00 is send instead of 
close_notify.  This is changed in a lot of places in the draft.

A big change from -13 is that where protected TLS application Data 0x00 is not 
a protected success indication as defined in RFC 3748. That the server only 
sends EAP-success after this follow from it being a protected success 
indication.

When reading through the document to write this answer I saw that there was 
some leftover from the commitment message still in the draft. I made a PR to 
address this.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/69

EAP-success is not encrytpted in any way. It is defined in RFC 3748.

Cheers,
John

From: Emu  on behalf of Meiling Chen 

Date: Saturday, 8 May 2021 at 10:25
To: Joseph Salowey , emu 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

I have noticed that there is one modification in the Figure 1 flow diagram of 
edition 15.
edition 14 has TLS close_notify message, but in edition 15 changed into TLS 
application Data 0x00.
in the section 2.1.1, it says" TLS application data 0x00 is therefore to

   be interpreted as success after the EAP-Request that contains TLS

   application data 0x00.  After the EAP-TLS server has received an

   empty EAP-Response to the EAP-Request containing the TLS application
   data 0x00, the EAP-TLS server sends EAP-Success."
is the data 0x00 that mean not send any more handshake messages?
another question: what's the format of the EAP-success measge, plaintext ot 
ciphertext?

Best Regards,
Meiling

From: Joseph Salowey
Date: 2021-05-05 23:33
To: EMU WG
Subject: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
This is the working group last-call for draft-ietf-emu-eap-tls13.  Please 
review the draft, focus on the recent changes and submit your comments to the 
list by May 20, 2021.

Thanks,

Joe

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-15
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-15
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

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