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 <j...@salowey.net>
Sent: Wednesday, October 21, 2020 2:34 PM
To: EMU WG <emu@ietf.org>; Jouni Malinen <j...@w1.fi>; Jorge Vergara 
<jover...@microsoft.com>; Oleg Pekar (olpekar) <olpe...@cisco.com>
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

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)


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to