Subject: [Emu] Proposed resolution for TEAP errata for 5128

From: Joseph Salowey <[email-masked]>
Date: Wed, 21 Oct 2020 14:34:29 -0700

Errata 5128: https://www.rfc-editor.org/errata/eid5128
Proposed State: Verified
Revision:

Section 5.2. says

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

It should say:

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

Note:
According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_<hash>(secret, label + seed)"

In terms of P_<hash> this would look like the following with the length
represented as a 2 byte value in network byte order:

IMCK[j] = P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] |
0x00 | 0x3C)

---

From: Jorge Vergara <[email-masked]>
Date: Wed, 21 Oct 2020 22:20:28 +0000

In theory I agree this is a possible resolution. However, this doesn’t match any of the current TEAP implementations that I am aware of. Perhaps Oleg can weigh in as well in terms of what he’s seen.

I believe all current implementations treat 60 as the desired output length without treating as a seed. In terms of P_<hash>, this means implementations are performing the calculation without a seed.

RFC 5246 defines the TLS 1.2 PRF as:
PRF(secret, label, seed) = P_<hash>(secret, label + seed)

So the calculation implementations are currently performing with an empty seed ends up as:
P_<hash>(secret, label)

Note that in RFC 5295, the length *is* explicitly mentioned as being concatenated with the label
USRK = KDF(EMSK, key label | "\0" | optional data | length)

RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by errata 5127. *However* it is not mentioned in this portion of the RFC. Since this calculation is not on an EMSK, I do not believe RFC 2395 applies and this is likely why implementations went with the seedless P_<hash>(secret, label) calculation instead.

Is there concern about updating the RFC in a way that breaks existing implementations?

Jorge Vergara

From: Joseph Salowey <[email-masked]>
Sent: Wednesday, October 21, 2020 2:34 PM
To: EMU WG <[email-masked]>; Jouni Malinen <[email-masked]>; Jorge Vergara <[email-masked]>; Oleg Pekar (olpekar) <[email-masked]>
Subject: Proposed resolution for TEAP errata for 5128

Errata 5128: https://www.rfc-editor.org/errata/eid5128<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128&data=04%7C01%7Cjovergar%40microsoft.com%7Ca85c718a3fd14ab5d88f08d87609209d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389128860921409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GXwU4tO1%2BlJg9aYY%2Bc%2BNKGdRAMlWy3I%2BqElyb%2BNd7ck%3D&reserved=0>
Proposed State: Verified
Revision:

Section 5.2. says

It should say:

Note:
According to

In terms of P_<hash> this would look like the following with the length represented as a 2 byte value in network byte order:

IMCK[j] = P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 | 0x3C)

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 21 Oct 2020 16:54:24 -0700

(I accidentally dropped this list from the conversation)

On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara <[email-masked]>
wrote:

> >[Joe] Yes this is a concern and I think your interpretation of the
> current document is also valid.  There may be more than one
> implementation.  So what you implemented was:
>
> >
>
> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
> P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>
>
>
> Yes, this is what I implemented. As you mentioned, there are multiple
> possible interpretations of this since the TEAP usage is incorrect.
> However, my implementation does interop with at least 2 large vendor
> implementations. If the implementations were using different calculations
> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
> since connections work, I can assume we are all using the same
> implementation and arriving at the same MSK. Cisco is one of the
> implementations that I have tested against which is why I was hoping Oleg
> may offer more context as to what he has seen.
>
>
>
[Joe] I can hope Jouni can chime in on this as well.  I think the original
intent was to not include the length as is your suggestion.

> >[Joe] Does the revision in 5167 match you implementation ( I don't think
> Jouni's comment changes the underly calculation, just its representation)?
>
>
>
> I have not implemented this portion of the RFC as I found it too unclear
> to work with. Thus I can’t comment on what implementations may be doing.
> However, I agree with the current revision in 5167 as the most natural
> interpretation. If others have implemented this portion of the RFC then
> certainly their comments would be welcome.
>
>
> By the way, we’ve dropped the EMU group on our replies here – not sure if
> intentional or not.
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey <[email-masked]>
> *Sent:* Wednesday, October 21, 2020 4:36 PM
> *To:* Jorge Vergara <[email-masked]>
> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>
>
>
>
>
>
>
> On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara <[email-masked]>
> wrote:
>
> In theory I agree this is a possible resolution. However, this doesn’t
> match any of the current TEAP implementations that I am aware of. Perhaps
> Oleg can weigh in as well in terms of what he’s seen.
>
>
>
> I believe all current implementations treat 60 as the desired output
> length without treating as a seed. In terms of P_<hash>, this means
> implementations are performing the calculation without a seed.
>
>
>
> RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by
> errata 5127. *However* it is not mentioned in this portion of the RFC.
> Since this calculation is not on an EMSK, I do not believe RFC 2395 applies
> and this is likely why implementations went with the seedless
> P_<hash>(secret, label) calculation instead.
>
>
>
> [Joe] Yes this is a concern and I think your interpretation of the current
> document is also valid.  There may be more than one implementation.  So
> what you implemented was:
>
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
> P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>
>
>
> taken out to 60 bytes.  The problem is that the TEAP spec references a
> TLS-PRF in a way that it does not define.  I think the errata points out
> the definition that should be used:
>
>
>
> That does not include length so the 60 in the original definition is
> ambiguous.   The new text would then be something like:
>
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
> to generate a length of 60 bytes
>
>
>
> Does the revision in 5167 match you implementation ( I don't think
> Jouni's comment changes the underly calculation, just its representation)?
>
>
>
>
>
>
>
>
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey <[email-masked]>
> *Sent:* Wednesday, October 21, 2020 2:34 PM
> *To:* EMU WG <[email-masked]>; Jouni Malinen <[email-masked]>; Jorge Vergara <
> [email-masked]>; Oleg Pekar (olpekar) <[email-masked]>
> *Subject:* Proposed resolution for TEAP errata for 5128
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128&data=04%7C01%7Cjovergar%40microsoft.com%7C38c27add2cb64a06310108d8761a22d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389201909062787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XudZt9FPh4jOBFQj01SQysnhX4p7G%2BflW2Pn2yIaJRM%3D&reserved=0>
>
> Proposed State: Verified
>
> Revision:
>
>
>
> Section 5.2. says
>
>

---

From: Oleg Pekar <[email-masked]>
Date: Thu, 22 Oct 2020 16:59:18 +0300

Hi all,
Speaking about both errata 5127 and 5128, I think we need to align all key
derivation calls in TEAP RFC with the same rule/format to make the RFC
easier to understand. This can be achieved by introducing a unified single
PRF function that will be called from all the relevant RFC locations. For
me it sounds better than if we align just part of KDF calls with RFC 5295
(where the output length is included into seed). Also: in some KDF calls we
do have optional data and in some no. This could be also unified.

So I would suggest introducing:
TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
label | 0x00 | optional data, length)
where a single byte 0x00 is used for no optional data, length is a 2-octet
unsigned integer in network byte order.

Then:
IMSK = First 32 octets of TEAP-PRF(EMSK, "[email-masked]", 64) =
TLS-PRF(EMSK, "[email-masked]" | 0x00 | 0x00 | 0x00 | 0x40)
IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
= TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
0x00 | 0x3C)
MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) =
TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 |
0x40)
EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64)
= TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 |
0x00 | 0x00 | 0x40)

This may change the existing implementation but will make it more clear -
need to create and call just one KDF function.

We can remove 0x00 that comes after the key label - while it is required
by RFC 5295. But there the key label is also ASCII printable string. Joe,
do you remember what was the motivation to put 0x00 after the key label
parameter?

Oleg

On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey <[email-masked]> wrote:

>> = P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>>
>>
>>
>> >[Joe] Does the revision in 5167 match you implementation ( I don't
>> think Jouni's comment changes the underly calculation, just its
>> representation)?
>>
>>
>>

---

From: Jorge Vergara <[email-masked]>
Date: Thu, 22 Oct 2020 14:12:59 +0000

My concern with this proposal of defining a new KDF is that it is a clear breaking change to any implementation that may exist.

In my opinion such a change would be fine if we want to bump some version numbers - maybe the TEAP version number has to be bumped, or maybe this can be achieved solely with the TLV version fields some of the TLVs contain. I haven’t thought about this aspect of too much. But redefining the KDF entirely with no version changes would be disruptive to multiple products.

This leads to a follow-up concern is - if an entirely new KDF were to be defined, I believe it should avoid using the TLS 1.2 PRF since it is already obsoleted in TLS 1.3.

Jorge Vergara

From: Oleg Pekar <[email-masked]>
Sent: Thursday, October 22, 2020 6:59 AM
To: Joseph Salowey <[email-masked]>
Cc: EMU WG <[email-masked]>; Jorge Vergara <[email-masked]>; Jouni Malinen <[email-masked]>
Subject: Re: Proposed resolution for TEAP errata for 5128

Hi all,
Speaking about both errata 5127 and 5128, I think we need to align all key derivation calls in TEAP RFC with the same rule/format to make the RFC easier to understand. This can be achieved by introducing a unified single PRF function that will be called from all the relevant RFC locations. For me it sounds better than if we align just part of KDF calls with RFC 5295 (where the output length is included into seed). Also: in some KDF calls we do have optional data and in some no. This could be also unified.

So I would suggest introducing:
TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label | 0x00 | optional data, length)
where a single byte 0x00 is used for no optional data, length is a 2-octet unsigned integer in network byte order.

Then:
IMSK = First 32 octets of TEAP-PRF(EMSK, "[email-masked]<mailto:[email-masked]>", 64) = TLS-PRF(EMSK, "[email-masked]<mailto:[email-masked]>" | 0x00 | 0x00 | 0x00 | 0x40)
IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] | 0x00 | 0x3C)
MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) = TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 | 0x40)
EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64) = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 | 0x00 | 0x00 | 0x40)

This may change the existing implementation but will make it more clear - need to create and call just one KDF function.

We can remove 0x00 that comes after the key label - while it is required by RFC 5295. But there the key label is also ASCII printable string. Joe, do you remember what was the motivation to put 0x00 after the key label parameter?

Oleg

On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:
(I accidentally dropped this list from the conversation)

On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara <[email-masked]<mailto:[email-masked]>> wrote:
>[Joe] Yes this is a concern and I think your interpretation of the current document is also valid.  There may be more than one implementation.  So what you implemented was:
>
>IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) = P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])

Yes, this is what I implemented. As you mentioned, there are multiple possible interpretations of this since the TEAP usage is incorrect. However, my implementation does interop with at least 2 large vendor implementations. If the implementations were using different calculations here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But since connections work, I can assume we are all using the same implementation and arriving at the same MSK. Cisco is one of the implementations that I have tested against which is why I was hoping Oleg may offer more context as to what he has seen.

[Joe] I can hope Jouni can chime in on this as well.  I think the original intent was to not include the length as is your suggestion.

>[Joe] Does the revision in 5167 match you implementation ( I don't think Jouni's comment changes the underly calculation, just its representation)?

I have not implemented this portion of the RFC as I found it too unclear to work with. Thus I can’t comment on what implementations may be doing. However, I agree with the current revision in 5167 as the most natural interpretation. If others have implemented this portion of the RFC then certainly their comments would be welcome.

By the way, we’ve dropped the EMU group on our replies here – not sure if intentional or not.

Jorge Vergara

From: Joseph Salowey <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 21, 2020 4:36 PM
To: Jorge Vergara <[email-masked]<mailto:[email-masked]>>
Subject: Re: Proposed resolution for TEAP errata for 5128

On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara <[email-masked]<mailto:[email-masked]>> wrote:
In theory I agree this is a possible resolution. However, this doesn’t match any of the current TEAP implementations that I am aware of. Perhaps Oleg can weigh in as well in terms of what he’s seen.

[Joe] Yes this is a concern and I think your interpretation of the current document is also valid.  There may be more than one implementation.  So what you implemented was:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) = P_<hash>(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])

taken out to 60 bytes.  The problem is that the TEAP spec references a TLS-PRF in a way that it does not define.  I think the errata points out the definition that should be used:

That does not include length so the 60 in the original definition is ambiguous.   The new text would then be something like:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])  to generate a length of 60 bytes

Does the revision in 5167 match you implementation ( I don't think Jouni's comment changes the underly calculation, just its representation)?

Jorge Vergara

From: Joseph Salowey <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, October 21, 2020 2:34 PM
To: EMU WG <[email-masked]<mailto:[email-masked]>>; Jouni Malinen <[email-masked]<mailto:[email-masked]>>; Jorge Vergara <[email-masked]<mailto:[email-masked]>>; Oleg Pekar (olpekar) <[email-masked]<mailto:[email-masked]>>
Subject: Proposed resolution for TEAP errata for 5128

Errata 5128: https://www.rfc-editor.org/errata/eid5128<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128&data=04%7C01%7Cjovergar%40microsoft.com%7C0c37db33d7a74c4fdfd108d87692b46f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389719762481075%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tm01%2FqLAGaQ9HxeyBeeU0yGPXVOPdWjIRDtPwW%2FRjGI%3D&reserved=0>
Proposed State: Verified
Revision:

Section 5.2. says

It should say:

Note:
According to

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Oct 2020 10:27:53 -0400

> My concern with this proposal of defining a new KDF is that it is a clear breaking change to any implementation that may exist.

  I am wary of breaking existing and deployed implementations.

> In my opinion such a change would be fine if we want to bump some version numbers - maybe the TEAP version number has to be bumped, or maybe this can be achieved solely with the TLV version fields…

  TBH, there isn't a lot of point.  We should just document what implementations do today.  Then, suggest that everyone move to TLS 1.3, and define entirely new derivations there.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 22 Oct 2020 08:55:08 -0700

On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar <[email-masked]>
wrote:

> [Joe] I don't think this was the original intent of the document.  The
IMSK derivation referenced 5295 while the others just reference the TLS
PRF.  I think to unify them would require a document update and I'm not
sure what we would gain especially if we have implementations that do
this.

> [Joe] I don't think that 5295 specifies that a 0x00 is used to represent
no optional data.  Did you see this in the spec? It may be ambiguous, but I
think the intent is that optional data is just omitted if it is not
provided.

> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j],
> 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
> 0x00 | 0x3C)

[Joe] the null after the key label is to provide a delimiter between the
key label and optional data.  Since the optional data can be arbitrary
content the null prevents two different lablels with specially crafted
optional data from deriving the same key.

>> [Joe] I can hope Jouni can chime in on this as well.  I think the
>> original intent was to not include the length as is your suggestion.
>>
>>
>>

---

From: Oleg Pekar <[email-masked]>
Date: Thu, 22 Oct 2020 19:29:17 +0300

I agree that changing the KDF is harmful to existing implementations.
However, if I understood correctly, Joe's suggestion for IMCK[j] also
breaks the existing implementation. I still see that we can define a
unified KDF by changing the API in the RFC but with the same harm to the
existing implementation in IMCK[j] as in both proposals:

TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
label | 0x00 | optional data, length)
Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is
used to represent no optional data, that was just my mistake.

IMSK:
Current Microsoft and Cisco implementation: P_hash(EMSK, "
[email-masked]" | 0x00 | 0x00 | 0x40)
Joe's proposal: P_hash(EMSK, "[email-masked]" | 0x00 | 0x00 | 0x40),
the same, just the API correction
Unified KDF proposal: TEAP-PRF(EMSK, "[email-masked]", <no optional
data>, 64) = P_hash(EMSK, "[email-masked]" | 0x00 | 0x00 | 0x40)
--- no implementation change

IMCK[j]:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner
Methods Compound Keys” | IMSK[j])
Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
| 0x00 | 0x3C)
Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
| 0x00 | 0x3C)
--- implementation change

MSK:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key
Generating Function” | 0x00 | 0x00 | 0x40)
Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating
Function”, <no optional data>, 64) = P_hash(S-IMCK[j], "Session Key
Generating Function” | 0x00 | 0x00 | 0x40)
--- no implementation change

Jorge, please correct me if I misinterpret the Microsoft implementation.

On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey <[email-masked]> wrote:

>> Speaking about both errata 5127 and 5128, I think we need to align all
>> key derivation calls in TEAP RFC with the same rule/format to make the RFC
>> where a single byte 0x00 is used for no optional data, length is a
>> 2-octet unsigned integer in network byte order.
>>
>> EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”,
>> 64) = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00
>> | 0x00 | 0x00 | 0x40)
>>
>>>> I have not implemented this portion of the RFC as I found it too
>>>> unclear to work with. Thus I can’t comment on what implementations may be
>>>> doing. However, I agree with the current revision in 5167 as the most
>>>> natural interpretation. If others have implemented this portion of the RFC
>>>> then certainly their comments would be welcome.
>>>>
>>>>
>>>> RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered
>>>> by errata 5127. *However* it is not mentioned in this portion of the RFC.

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 22 Oct 2020 09:53:13 -0700

On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar <[email-masked]>
wrote:

> Joe's proposal: P_hash(EMSK, "[email-masked]" | 0x00 | 0x00 |
> 0x40), the same, just the API correction
> Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" |
> IMSK[j] | 0x00 | 0x3C)

[Joe] That was my initial proposal, but based on Jorge's comment it is
modified to:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])  to
generate a length of 60 bytes
IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])

> [Joe] This is the one we have not discussed yet.  This derivation is also
ambiguous.  THis section does not reference 5295.  It's not clear if the
original intent was to include the length in the hash or not.  I think
there are a few interpretations:

1. TLS-PRF(S-IMCK[j], "Session Key Generating Function")  iterated to
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” |
0x00 | 0x40)
3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating
Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function”
| 0x00 | 0x00 | 0x40)

I think 1 or 2 is what was probably originally intended, however it seems
that 3 is what has been implemented.  Do we have agreement on this is what
current implementations do?

>>> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret,
>>> key label | 0x00 | optional data, length)
>>> This may change the existing implementation but will make it more clear
>>> - need to create and call just one KDF function.
>>>
>>>>> In terms of P_<hash> this would look like the following with the
>>>>> length represented as a 2 byte value in network byte order:
>>>>>
>>>>>
>>>>>

---

From: Jorge Vergara <[email-masked]>
Date: Thu, 22 Oct 2020 16:58:13 +0000

>[Joe] This is the one we have not discussed yet.  This derivation is also ambiguous.  THis section does not reference 5295.  It's not clear if the original intent was to include the length in the hash or not.  I think there are a few interpretations:
>
>1. TLS-PRF(S-IMCK[j], "Session Key Generating Function")  iterated to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
>2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x40)
>3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40)
>
>I think 1 or 2 is what was probably originally intended, however it seems that 3 is what has been implemented.  Do we have agreement on this is what current implementations do?

No, Microsoft implements number 1 of Joe’s presented options. That is - P_<hash>(S-IMCK[j], "Session Key Generating Function").

This follows the same pattern as the errata we are discussion. I am very surprised to hear that Cisco’s implementation may be different. Oleg, could you please double check? I have just double checked our implementation. Since our implementations interop, I assume we must have the same implementation.

Jorge Vergara

From: Joseph Salowey <[email-masked]>
Sent: Thursday, October 22, 2020 9:53 AM
To: Oleg Pekar <[email-masked]>
Cc: EMU WG <[email-masked]>; Jorge Vergara <[email-masked]>; Jouni Malinen <[email-masked]>
Subject: Re: Proposed resolution for TEAP errata for 5128

On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar <[email-masked]<mailto:[email-masked]>> wrote:
I agree that changing the KDF is harmful to existing implementations. However, if I understood correctly, Joe's suggestion for IMCK[j] also breaks the existing implementation. I still see that we can define a unified KDF by changing the API in the RFC but with the same harm to the existing implementation in IMCK[j] as in both proposals:

TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label | 0x00 | optional data, length)
Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is used to represent no optional data, that was just my mistake.

IMSK:
Current Microsoft and Cisco implementation: P_hash(EMSK, "[email-masked]<mailto:[email-masked]>" | 0x00 | 0x00 | 0x40)
Joe's proposal: P_hash(EMSK, "[email-masked]<mailto:[email-masked]>" | 0x00 | 0x00 | 0x40), the same, just the API correction
Unified KDF proposal: TEAP-PRF(EMSK, "[email-masked]<mailto:[email-masked]>", <no optional data>, 64) = P_hash(EMSK, "[email-masked]<mailto:[email-masked]>" | 0x00 | 0x00 | 0x40)
--- no implementation change

IMCK[j]:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])
Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 | 0x3C)
Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 | 0x3C)
--- implementation change

[Joe] That was my initial proposal, but based on Jorge's comment it is modified to:

MSK:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40)
Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, <no optional data>, 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40)
--- no implementation change

[Joe] This is the one we have not discussed yet.  This derivation is also ambiguous.  THis section does not reference 5295.  It's not clear if the original intent was to include the length in the hash or not.  I think there are a few interpretations:

1. TLS-PRF(S-IMCK[j], "Session Key Generating Function")  iterated to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x40)
3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 | 0x00 | 0x40)

I think 1 or 2 is what was probably originally intended, however it seems that 3 is what has been implemented.  Do we have agreement on this is what current implementations do?

On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
Speaking about both errata 5127 and 5128, I think we need to align all key derivation calls in TEAP RFC with the same rule/format to make the RFC easier to understand. This can be achieved by introducing a unified single PRF function that will be called from all the relevant RFC locations. For me it sounds better than if we align just part of KDF calls with RFC 5295 (where the output length is included into seed). Also: in some KDF calls we do have optional data and in some no. This could be also unified.

[Joe] I don't think this was the original intent of the document.  The IMSK derivation referenced 5295 while the others just reference the TLS PRF.  I think to unify them would require a document update and I'm not sure what we would gain especially if we have implementations that do this.

[Joe] I don't think that 5295 specifies that a 0x00 is used to represent no optional data.  Did you see this in the spec? It may be ambiguous, but I think the intent is that optional data is just omitted if it is not provided.

Then:

[Joe] the null after the key label is to provide a delimiter between the key label and optional data.  Since the optional data can be arbitrary content the null prevents two different lablels with specially crafted optional data from deriving the same key.

Oleg

Jorge Vergara

Jorge Vergara

Errata 5128: https://www.rfc-editor.org/errata/eid5128<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128&data=04%7C01%7Cjovergar%40microsoft.com%7C1607f5f05ab64c11228108d876ab0304%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389824150792537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FY77gd5%2BZnRPHT%2Bkq2KkTJPlkK2hIu%2FfFejHlj9e7CQ%3D&reserved=0>
Proposed State: Verified
Revision:

Section 5.2. says

It should say:

Note:
According to

---

From: Oleg Pekar <[email-masked]>
Date: Thu, 22 Oct 2020 20:50:18 +0300

>No, Microsoft implements number 1 of Joe’s presented options. That is -
P_<hash>(S-IMCK[j], "Session Key Generating Function").

>This follows the same pattern as the errata we are discussion. I am very
surprised to hear that Cisco’s implementation may be different. Oleg, could
you please double check? I have just double checked our

>implementation. Since our implementations interop, I assume we must have
the same implementation.

Jorge, thanks for pointing that out. Cisco also implements option number 1
from above. I referenced to EAP-FAST implementation by mistake, sorry.

So, not to harm at least two implementations, all we can do for errata
5127, 5128 - is just to change the wording to be more clear, removing
ambiguity.

On Thu, Oct 22, 2020 at 7:58 PM Jorge Vergara <[email-masked]>
wrote:

> >2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated
> to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”
> | 0x00 | 0x40)
>
> Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating
> Function” | 0x00 | 0x00 | 0x40)
>
> >
>
> No, Microsoft implements number 1 of Joe’s presented options. That is -
> P_<hash>(S-IMCK[j], "Session Key Generating Function").
>
>
>
> This follows the same pattern as the errata we are discussion. I am very
> surprised to hear that Cisco’s implementation may be different. Oleg, could
> you please double check? I have just double checked our implementation.
> Since our implementations interop, I assume we must have the same
> implementation.
>
>
>
> Jorge Vergara
>
>
>
>
>
> *Sent:* Thursday, October 22, 2020 9:53 AM
> *To:* Oleg Pekar <[email-masked]>
> *Cc:* EMU WG <[email-masked]>; Jorge Vergara <[email-masked]>;
> Jouni Malinen <[email-masked]>
> Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating
> Function” | 0x00 | 0x00 | 0x40)
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128&data=04%7C01%7Cjovergar%40microsoft.com%7C1607f5f05ab64c11228108d876ab0304%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389824150792537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FY77gd5%2BZnRPHT%2Bkq2KkTJPlkK2hIu%2FfFejHlj9e7CQ%3D&reserved=0>
>
> Proposed State: Verified
>
> Revision:
>
>
>
> Section 5.2. says
>
>

---

From: Jouni Malinen <[email-masked]>
Date: Fri, 23 Oct 2020 19:55:49 +0300

There were so many messages in this thread that I'm not going try to
address each point separately, but I think in general I do agree with
the comments and it looks like all the identified implementation are
doing the same thing here..

I don't see any strong need to encode the output length of the PRF into
the input data especially since we are using hardcoded output lengths in
these cases. That said, I'm not against keeping it there for the IMSK
derivation since that particular case seemed to be explicitly defined as
using a 2-octet field in network byte order (and all the known
implementations doing exactly that). IMHO, the other cases should not be
modified to try to be consistent with this.

While I do understand the benefits of having an explicit fixed delimiter
"\0" between the label and seed to enforce unique interpretation if two
labels were to have same prefix, I don't see that as a critical issue in
any of the instances used within TEAP due to no such common prefix case
exist nor do we even use TLS-PRF with the same secret/key. Furthermore,
RFC 5246 does not mandate or even discuss such delimiter.

There is no need to convert an empty seed to 0x00 or anything else.
TLS-PRF can be used with secret=something, label=ASCII string,
seed=0-length data) without issues.

If we want to define a new TEAP-PRF() function, I'd prefer it to be
using consistent terminology with TLS-PRF in RFC 5246 (and well, to
extend possible, also be as consistent as can be with the TLS-Exporter
use in RFC 8446). This would also mean not trying to enforce some 0x00
delimiter or length in context data. At its simplest and only with TLS
v1.2 in mind for clarity here, this could look something like

TEAP-PRF(secret, label, seed, output length) =
PRF(secret, label, seed) outputting "output length" octets

label = ASCII string, no "\x0" termination
seed = arbitrary binary data (including possibility of 0-length empty
case)

With this, we would have following:
IMSK = First 32 octets of TEAP-PRF(EMSK, "[email-masked]", 0x00 |
0x00 | 0x40, 64)
IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function", <empty>, 64)
EMSK = TEAP-PRF(S-IMCK[j], "Extended Session Key Generating Function",
<empty>, 64)

RFC 5295 rules about EMSK use for USRK/DSRK applies for the first one of
these and it does seem to give justification for the seed to have "\0"
and "length" (as 2-octet unsigned integer in network byte order). While
one could claim that the rules for DSUSRK derivation applies to those
other instances and as such, would require 0x00 and length to be added
around the seed shown above, I'd note that there does not seem to be any
MUST statement about that in RFC 5295 and as such, I think the versions
described above (and the ones used in known implementations today) seem
to be justifiable especially taken into account the unique label string
prefixes and fixed length of output data.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 23 Oct 2020 14:11:04 -0700

I think we have agreement on what the derivation would be now it's a matter
of clearly describing it. Here is a proposal:
IMCK[j] = the first 60 bytes of TLS-PRF(S-IMCK[j-1], "Inner Methods
Compound Keys", IMSK[j])

      where "|" denotes concatenation and the TLS-PRF is defined in
      [RFC5246] as

        PRF(secret, label, seed) = P_<hash>(secret, label | seed).

     the secret is S-IMCK[j-1],  the label is
     "Inner Methods Compound Keys" consisting of the ASCII value for the
     label "Inner Methods Compound Keys" (without quotes),  the seed
     consists IMSK[j].

MSK = the first 64 bytes of TLS-PRF(S-IMCK[j], "Session Key Generating
Function")
EMSK = the first 64 bytes of TLS-PRF(S-IMCK[j], "Extended Session Key
Generating Function")

      where "|" denotes concatenation and the TLS-PRF is defined in
      [RFC5246] as

        PRF(secret, label, seed) = P_<hash>(secret, label | seed).

     The secret is S-IMCK[j-1]  where j is the number of the last
successfully
     executed inner EAP method.  The label is is the ASCII value for the
     string without quotes.  The seed is empty (0 length) and omitted from
     the derivation.