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 protected]", 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
