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.
On Fri, Oct 23, 2020 at 9:58 AM Jouni Malinen <j...@w1.fi> wrote:
> 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, "teapbind...@ietf.org", 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
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
