On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara <jover...@microsoft.com>
wrote:
> Sorry for the last minute comment on this one before the meeting. I would
> like to mark this as a “discuss” - I have some compat concern about making
> the TLV length variable. Current implementations truncate the MAC field at
> 20 octets. Although I agree in spirit with the direction of this change, I
> think it would require changing the version of the Crypto-Binding TLV.
>
>
>
> I recognize that most probably won’t have time to review this concern
> before the meeting and so the discussion may not be able to occur there.
> Apologies again as I only realized this concern as I was giving everything
> a final pass-over.
>
>
>
[Joe] Thanks for catching this. If this is the case then we should have
the errata resolution reflect what implementations do and leave the rest of
the change for a document update.
For this I suggest that we leave section 4.2.13 unchanged and make changes
to 5.3.
Section 5.3 Says:
The Compound MAC computation is as follows:
CMK = CMK[j]
Compound-MAC = MAC( CMK, BUFFER )
where j is the number of the last successfully executed inner EAP
method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
BUFFER is created after concatenating these fields in the following
order:
1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK
Compound MAC fields zeroed out.
2 The EAP Type sent by the other party in the first TEAP message.
It Should say:
The Compound MAC computation is as follows:
CMK = CMK[j]
Compound-MAC = MAC( CMK, BUFFER )
where j is the number of the last successfully executed inner EAP
method, MAC is HMAC [RFC2104] using the hash function negotiated in
TLS [RFC5246]. If the output of the HMAC is greater than 20 bytes then
it is truncated to 20 bytes. The BUFFER is created after concatenating
these fields in the following order:
1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK
Compound MAC fields zeroed out.
2 The EAP Type sent by the other party in the first TEAP message. This
is a single octet encoded as (0x37)
> Jorge Vergara
>
>
>
> *From:* Oleg Pekar <oleg.pekar.2...@gmail.com>
> *Sent:* Saturday, October 24, 2020 4:30 PM
> *To:* Joseph Salowey <j...@salowey.net>
> *Cc:* EMU WG <emu@ietf.org>; Jouni Malinen <j...@w1.fi>; Jorge Vergara <
> jover...@microsoft.com>
> *Subject:* Re: Proposed Resolution for TEAP errata 5768
>
>
>
> > 2 The EAP Type sent by the other party in the first TEAP message. This
> is a single octet encoded as (0x37)
>
>
>
> Shouldn't we clarify the motivation for placing the octet with TEAP type
> 0x37 into the BUFFER? Joe, I remember you explained that it is for
> protection against cross protocol attacks if Crypto-Binding TLV was reused
> (e.g. from PEAP).
>
>
>
> On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey <j...@salowey.net> wrote:
>
> Errata 5768: https://www.rfc-editor.org/errata/eid5768
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5768&data=04%7C01%7Cjovergar%40microsoft.com%7C100b027d04c14dc5f59b08d87874b568%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391789943190120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jn7e%2FfR9O%2Fa%2B%2F1gPWuUcUaXKKyf%2F8cTAR0qTXXx6MRM%3D&reserved=0>
>
> Proposed State: Verified
>
> Revision:
>
>
>
> Section 4.2.13. Says:
>
>
>
> Length
>
>
>
> 76
>
>
>
> It should say:
>
>
>
> Length
>
>
>
> 36 plus the length of the 2 MAC fields
>
>
>
> Section 4.2.13. Says:
>
>
> EMSK Compound MAC
>
> The EMSK Compound MAC field is 20 octets. This can be the Server
> MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the
> MAC is described in Section 5.3.
>
> MSK Compound MAC
>
> The MSK Compound MAC field is 20 octets. This can be the Server
> MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the
> MAC is described in Section 5.3.
>
>
>
> It Should Say:
>
>
>
> EMSK Compound MAC
>
> The computation of the MAC is described in Section 5.3. This can be
>
> the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
> MSK Compound MAC
>
> The computation of the MAC is described in Section 5.3. This can be
>
> the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
>
>
> Section 5.3 Says:
>
>
>
> The Compound MAC computation is as follows:
>
> CMK = CMK[j]
> Compound-MAC = MAC( CMK, BUFFER )
>
> where j is the number of the last successfully executed inner EAP
> method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
> BUFFER is created after concatenating these fields in the following
> order:
>
> 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK
> Compound MAC fields zeroed out.
>
> 2 The EAP Type sent by the other party in the first TEAP message.
>
>
>
> It Should say:
>
>
>
> The Compound MAC computation is as follows:
>
> CMK = CMK[j]
> Compound-MAC = MAC( CMK, BUFFER )
>
> where j is the number of the last successfully executed inner EAP
> method, MAC is HMAC [RFC2104] using the hash function negotiated in
>
> TLS [RFC5246]. The output length is the length of the output of the
> HMAC
>
> function. The BUFFER is created after concatenating these fields in
>
> the following order:
>
>
> 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK
> Compound MAC fields zeroed out.
>
> 2 The EAP Type sent by the other party in the first TEAP message. This
>
> is a single octet encoded as (0x37)
>
>
>
> Notes:
>
>
>
> This corrects the problem that the MAC output will vary depending upon the
> TLS hash function. It clarifies that HMAC is used with the hash function
> negotiated in TLS. It also clarifies that the EAP Type used in the TLS
> message is the TEAP EAP type encoded as a single byte.
>
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
