Subject: Re: [Emu] Revised resolution for TEAP erratum 5127

From: Joseph Salowey <[email-masked]>
Date: Mon, 23 Nov 2020 21:21:04 -0800

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, "[email-masked]" |
 "\0" | 64)

 where "|" denotes concatenation, EMSK is the EMSK from the inner
 method, "[email-masked]" consists the ASCII value for the
 label "[email-masked]" (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, "[email-masked]",
 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
 "[email-masked]" consisting of the ASCII value for the
 label "[email-masked]" (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 <[email-masked]> 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, "[email-masked]" |
>  "\0" | 64)
>
>  where "|" denotes concatenation, EMSK is the EMSK from the inner
>  method, "[email-masked]" consists the ASCII value for the
>  label "[email-masked]" (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, "[email-masked]",
>  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
>  "[email-masked]" consisting of the ASCII value for the
>  label "[email-masked]" (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, "[email-masked]" | 0x00 | 0x00 | 0x40)
>