At the IETF 109 EMU meeting Oleg suggest that we make it clear that if an MSK is generated it must be used. I suggest we do this by updating this revision as below:
Section 5.2 says IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | "\0" | 64) where "|" denotes concatenation, EMSK is the EMSK from the inner method, "teapbind...@ietf.org" consists the ASCII value for the label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL octet (0x00 in hex), length is the 2-octet unsigned integer in network byte order, and TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246]. If an inner method does not support export of an Extended Master Session Key (EMSK), then IMSK is the MSK of the inner method. The MSK is truncated at 32 octets if it is longer than 32 octets or padded to a length of 32 octets with zeros if it is less than 32 octets. It should say: IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", 0x00 | 0x00 | 0x40) where "|" denotes concatenation and the TLS-PRF is defined in [RFC5246] as PRF(secret, label, seed) = P_<hash>(secret, label | seed). the secret is the EMSK from the inner method, the label is "teapbind...@ietf.org" consisting of the ASCII value for the label "teapbind...@ietf.org" (without quotes), the seed consists of the "\0" null delimiter (0x00) and 2-octet unsigned integer length in network byte order (0x00 | 0x4) specified in [RFC5295]. If an inner method does not support export of an Extended Master Session Key (EMSK), then the IMSK MUST be derived from the MSK of the inner method. The MSK is truncated at 32 octets if it is longer than 32 octets or padded to a length of 32 octets with zeros if it is less than 32 octets. Cheers, Joe On Thu, Oct 29, 2020 at 10:05 PM Joseph Salowey <j...@salowey.net> wrote: > I think this erratum is done. I've also started a GH repo to track the > changes in the document which might help show them in context a bit better. > The PR for this issue is https://github.com/emu-wg/teap-errata/pull/2. > Please post here or comment on the PR if you think this needs any > additional work. > > Errata 5127: https://www.rfc-editor.org/errata/eid5127 > Proposed State: Verified > Revision: https://github.com/emu-wg/teap-errata/pull/2 > Section 5.2 says > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | > "\0" | 64) > > where "|" denotes concatenation, EMSK is the EMSK from the inner > method, "teapbind...@ietf.org" consists the ASCII value for the > label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL > octet (0x00 in hex), length is the 2-octet unsigned integer in > network byte order, and TLS-PRF is the PRF negotiated as part of > TLS handshake [RFC5246]. > > It should say: > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", > 0x00 | 0x00 | 0x40) > > where "|" denotes concatenation and the TLS-PRF is defined in > [RFC5246] as > > PRF(secret, label, seed) = P_<hash>(secret, label | seed). > > the secret is the EMSK from the inner method, the label is > "teapbind...@ietf.org" consisting of the ASCII value for the > label "teapbind...@ietf.org" (without quotes), the seed > consists of the "\0" null delimiter (0x00) and 2-octet unsigned > integer length in network byte order (0x00 | 0x4) specified > in [RFC5295]. > > Notes: > > 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 this case the seed is the 2-byte length of the output as defined by RFC > 5295. In terms of P_ the derivation would look like: > > IMSK = P_<hash>(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
