Re: [Emu] draft-dekok-emu-tls-eap-types discussion

[Oleg Pekar]

>>Could this method work? Should we make it more clearly specified? Or
should we change the protocol to arrive explicitly to the understanding
which type (MSK/EMSK) of IMSK[j] to use?



>You clarification is what I understood the intention of the RFC to be as
well, and makes sense to me. I don’t think there needs to be a protocol
update if this clarification sounds good to all parties. I would welcome
Jouni’s thoughts as the filer of the errata.


Good! Then we can leave the protocol unchanged but re-write the
relevant sections 5.2, 5.3 and maybe 5.4 to define clearly the algorithm.
Right, it would be great to hear from Jouni whether this will satisfy the
Errata 5770.


Oleg

On Wed, Apr 15, 2020 at 9:31 PM Jorge Vergara 
wrote:

> > For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning
> to find the common method of TLS 1.3 support for all three or you just want
> to release TLS 1.3 support at the same time for all three?
>
>
>
> It’s not our intention to try to force the same solution for every method.
> We plan to update our implementations at the same time, since we anticipate
> the updates will be similar (though not necessarily identical).
>
>
>
> >Could this method work? Should we make it more clearly specified? Or
> should we change the protocol to arrive explicitly to the understanding
> which type (MSK/EMSK) of IMSK[j] to use?
>
>
>
> You clarification is what I understood the intention of the RFC to be as
> well, and makes sense to me. I don’t think there needs to be a protocol
> update if this clarification sounds good to all parties. I would welcome
> Jouni’s thoughts as the filer of the errata.
>
>
>
> Jorge
>
>
>
> *From:* Emu  *On Behalf Of * Oleg Pekar
> *Sent:* Wednesday, April 15, 2020 9:25 AM
> *To:* Jorge Vergara 
> *Cc:* EMU WG 
> *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
>
> Hi Jorge,
>
> For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning
> to find the common method of TLS 1.3 support for all three or you just want
> to release TLS 1.3 support at the same time for all three?
>
>
>
> For TEAP errata 5770:
>
> Technically TEAP RFC suggests the implicit method of taking the correct
> IMSK[j] and all the subsequent keys after each inner method via negotiation
> taking place in Crypto-Binding TLV exchange.
>
>
>
> Let's say we are on the inner method number j that supports both MSK and
> EMSK and we are server which implementation generates both MSK and EMSK for
> this inner method. We generated keys according to the rules below - two
> sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to
> inner method MSK. Because we don't know whether client implementation
> supports both MSK and EMSK.
>
>
>
> S-IMCK[0] = session_key_seed
>
>   For j = 1 to n-1 do
>
>IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
>
> IMSK[j], 60)
>
>S-IMCK[j] = first 40 octets of IMCK[j]
>
>CMK[j] = last 20 octets of IMCK[j]
>
>
>
> So we have two CMK[j] and we create Crypto-Binding TLV with both Compound
> MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response and
> we can understand from it whether it supports EMSK for this inner method or
> not. And here we can decide which version of IMCK[j] to take for this inner
> method - derived from EMSK or MSK. This is just not explicitly specified in
> the RFC.
>
>
>
> Could this method work? Should we make it more clearly specified? Or
> should we change the protocol to arrive explicitly to the understanding
> which type (MSK/EMSK) of IMSK[j] to use?
>
>
>
> Thanks
>
> Oleg
>
>
>
>
>
> On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara  40microsoft@dmarc.ietf.org> wrote:
>
> >Microsoft has already said that they won't rev their EAP-TLS
> implementation until they can also rev PEAP.
>
> PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the
> same time and will postpone TLS 1.3 support until such a time as we are
> able to make the updates together.
>
> >* should the document drop references to TEAP?
> > Given Jouni Malinen's comments on implementing TEAP, it may be worth
> simply noting that we're waiting for a TEAP update document
>
> I've reviewed the current errata, and acknowledge their validity, but am
> not sure that any of them would impact this document.
>
> The most relevant errata to this document seems to be
> https://www.rfc-editor.org/errata/eid5770
> .
> As noted in the errata, the calculation of keys becomes confusing when
> methods export both MSK and EMSK because it is not clearly specified which
> value IMCK[j] should take on during the calculation of S-IMCK[j]. The
> a

Re: [Emu] draft-dekok-emu-tls-eap-types discussion

[Jorge Vergara]

> For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to 
> find the common method of TLS 1.3 support for all three or you just want to 
> release TLS 1.3 support at the same time for all three?

It’s not our intention to try to force the same solution for every method. We 
plan to update our implementations at the same time, since we anticipate the 
updates will be similar (though not necessarily identical).

>Could this method work? Should we make it more clearly specified? Or should we 
>change the protocol to arrive explicitly to the understanding which type 
>(MSK/EMSK) of IMSK[j] to use?

You clarification is what I understood the intention of the RFC to be as well, 
and makes sense to me. I don’t think there needs to be a protocol update if 
this clarification sounds good to all parties. I would welcome Jouni’s thoughts 
as the filer of the errata.

Jorge

From: Emu  On Behalf Of Oleg Pekar
Sent: Wednesday, April 15, 2020 9:25 AM
To: Jorge Vergara 
Cc: EMU WG 
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

Hi Jorge,
For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to 
find the common method of TLS 1.3 support for all three or you just want to 
release TLS 1.3 support at the same time for all three?

For TEAP errata 5770:
Technically TEAP RFC suggests the implicit method of taking the correct IMSK[j] 
and all the subsequent keys after each inner method via negotiation taking 
place in Crypto-Binding TLV exchange.

Let's say we are on the inner method number j that supports both MSK and EMSK 
and we are server which implementation generates both MSK and EMSK for this 
inner method. We generated keys according to the rules below - two sets, for 
IMSK[j] derived from inner method EMSK and for IMSK[j] equal to inner method 
MSK. Because we don't know whether client implementation supports both MSK and 
EMSK.


S-IMCK[0] = session_key_seed

  For j = 1 to n-1 do

   IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",

IMSK[j], 60)

   S-IMCK[j] = first 40 octets of IMCK[j]

   CMK[j] = last 20 octets of IMCK[j]

So we have two CMK[j] and we create Crypto-Binding TLV with both Compound MAC 
for MSK and EMSK. The client sends Crypto-Binding TLV in response and we can 
understand from it whether it supports EMSK for this inner method or not. And 
here we can decide which version of IMCK[j] to take for this inner method - 
derived from EMSK or MSK. This is just not explicitly specified in the RFC.

Could this method work? Should we make it more clearly specified? Or should we 
change the protocol to arrive explicitly to the understanding which type 
(MSK/EMSK) of IMSK[j] to use?

Thanks
Oleg


On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
>Microsoft has already said that they won't rev their EAP-TLS implementation 
>until they can also rev PEAP.

PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same 
time and will postpone TLS 1.3 support until such a time as we are able to make 
the updates together.

>* should the document drop references to TEAP?
> Given Jouni Malinen's comments on implementing TEAP, it may be worth simply 
> noting that we're waiting for a TEAP update document

I've reviewed the current errata, and acknowledge their validity, but am not 
sure that any of them would impact this document.

The most relevant errata to this document seems to be 
https://www.rfc-editor.org/errata/eid5770.
 As noted in the errata, the calculation of keys becomes confusing when methods 
export both MSK and EMSK because it is not clearly specified which value 
IMCK[j] should take on during the calculation of S-IMCK[j]. The addition of 
clarifying information is welcome, but I don't believe this ambiguity currently 
prevents a compliant implementation - for example, an implementation could 
avoid this ambiguity by choosing to use either the MSK/EMSK exclusively, and 
communicating that to the server via the Compound MAC TLV. The server can then 
make a policy decision on whether it is accepting of this decision by the 
client and follow suit, or reject the client.

The specifics of resolving this particular errata is a digression from my main 
point - I believe a clarification can be added to the main TEAP document at a 
future time without impacting the contents of this document. Ambiguity about 
which IMCK to use in S-IMCK calculation should not impact the definition of the 
cryptographic calculations.

On the document contents themselves, I have this review: The key derivation 
proposed for TEAP/FAST uses the definition from FAS

Re: [Emu] draft-dekok-emu-tls-eap-types discussion

[Oleg Pekar]

Hi Jorge,
For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to
find the common method of TLS 1.3 support for all three or you just want to
release TLS 1.3 support at the same time for all three?

For TEAP errata 5770:
Technically TEAP RFC suggests the implicit method of taking the correct
IMSK[j] and all the subsequent keys after each inner method via negotiation
taking place in Crypto-Binding TLV exchange.

Let's say we are on the inner method number j that supports both MSK and
EMSK and we are server which implementation generates both MSK and EMSK for
this inner method. We generated keys according to the rules below - two
sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to
inner method MSK. Because we don't know whether client implementation
supports both MSK and EMSK.

S-IMCK[0] = session_key_seed
  For j = 1 to n-1 do
   IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)
   S-IMCK[j] = first 40 octets of IMCK[j]
   CMK[j] = last 20 octets of IMCK[j]


So we have two CMK[j] and we create Crypto-Binding TLV with both Compound
MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response and
we can understand from it whether it supports EMSK for this inner method or
not. And here we can decide which version of IMCK[j] to take for this inner
method - derived from EMSK or MSK. This is just not explicitly specified in
the RFC.

Could this method work? Should we make it more clearly specified? Or should
we change the protocol to arrive explicitly to the understanding which type
(MSK/EMSK) of IMSK[j] to use?

Thanks
Oleg


On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara  wrote:

> >Microsoft has already said that they won't rev their EAP-TLS
> implementation until they can also rev PEAP.
>
> PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the
> same time and will postpone TLS 1.3 support until such a time as we are
> able to make the updates together.
>
> >* should the document drop references to TEAP?
> > Given Jouni Malinen's comments on implementing TEAP, it may be worth
> simply noting that we're waiting for a TEAP update document
>
> I've reviewed the current errata, and acknowledge their validity, but am
> not sure that any of them would impact this document.
>
> The most relevant errata to this document seems to be
> https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the
> calculation of keys becomes confusing when methods export both MSK and EMSK
> because it is not clearly specified which value IMCK[j] should take on
> during the calculation of S-IMCK[j]. The addition of clarifying information
> is welcome, but I don't believe this ambiguity currently prevents a
> compliant implementation - for example, an implementation could avoid this
> ambiguity by choosing to use either the MSK/EMSK exclusively, and
> communicating that to the server via the Compound MAC TLV. The server can
> then make a policy decision on whether it is accepting of this decision by
> the client and follow suit, or reject the client.
>
> The specifics of resolving this particular errata is a digression from my
> main point - I believe a clarification can be added to the main TEAP
> document at a future time without impacting the contents of this document..
> Ambiguity about which IMCK to use in S-IMCK calculation should not impact
> the definition of the cryptographic calculations.
>
> On the document contents themselves, I have this review: The key
> derivation proposed for TEAP/FAST uses the definition from FAST, which is
> not identical to the TEAP derivation. Namely, FAST used MSK[j] in the
> derivation, but TEAP uses IMSK[j], which may be equivalent in some cases,
> but may not in others where the inner method exports an EMSK.
>
> Specifically, I believe this line of section 2.2 should change from
>   IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | MSK[j], 60)
> To
>   IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | IMSK[j], 60)
> For TEAP.
>
> Jorge
>
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Friday, April 3, 2020 1:48 PM
> To: EMU WG 
> Subject: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01&data=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711&sdata=ndLp%2FSzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3D&reserved=0
>
>   I haven't seen much discussion on the document.  There are still some
> open questions:
>
> * should it be published simultaneously with draft-ietf-emu-eap-tls13?
>If so, we need some consensus on this document, and quick.
>
>If not, when do we publish this draft?  Microsoft has already said that
> they won't rev their EAP-TLS im