Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-12-10 Thread Jorge Vergara 
This change looks good to me. Would appreciate a sanity check of another 
implementation by Oleg to make sure I have my facts straight here.

From: Joseph Salowey 
Sent: Sunday, November 22, 2020 9:24 PM
To: Jorge Vergara 
Cc: Oleg Pekar ; EMU WG ; Jouni 
Malinen 
Subject: Re: Proposed Resolution for TEAP errata 5768



On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara 
mailto: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 mailto:oleg.pekar.2...@gmail.com>>
Sent: Saturday, October 24, 2020 4:30 PM
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: EMU WG mailto:emu@ietf.org>>; Jouni Malinen 
mailto:j...@w1.fi>>; Jorge Vergara 
mailto: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 
mailto:j...@salowey.net>> wrote:
Errata 5768:  
https://www.rfc-editor.org/errata/eid5768
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 entir

Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-11-22 Thread Joseph Salowey 
On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara 
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 
> *Sent:* Saturday, October 24, 2020 4:30 PM
> *To:* Joseph Salowey 
> *Cc:* EMU WG ; Jouni Malinen ; 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  wrote:
>
> Errata 5768:  https://www.rfc-editor.org/errata/eid5768
> 
>
> 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:
>

Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-11-19 Thread Jorge Vergara 
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.

Jorge Vergara

From: Oleg Pekar 
Sent: Saturday, October 24, 2020 4:30 PM
To: Joseph Salowey 
Cc: EMU WG ; Jouni Malinen ; Jorge Vergara 

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 
mailto:j...@salowey.net>> wrote:
Errata 5768:  
https://www.rfc-editor.org/errata/eid5768
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

Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-10-24 Thread Joseph Salowey 
On Sat, Oct 24, 2020 at 4:29 PM Oleg Pekar 
wrote:

> > 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).
>

[Joe]  That's more of an editorial comment that we would hold for a
document revision.  I think we should try to keep the revision text at a
minimum, but we certainly can include this information in the errata
notes.


> On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey  wrote:
>
>> Errata 5768:  https://www.rfc-editor.org/errata/eid5768
>> 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

Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-10-24 Thread Oleg Pekar 
> 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  wrote:

> Errata 5768:  https://www.rfc-editor.org/errata/eid5768
> 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

[Emu] Proposed Resolution for TEAP errata 5768

2020-10-24 Thread Joseph Salowey 
Errata 5768:  https://www.rfc-editor.org/errata/eid5768
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