[Emu] TEAP errata 5770
Based on Jouni's analysis the derivation of the S-IMCKs is not well specified. To me it looks like the solution to handle an arbitrary number of methods that may or may not make an EMSK available would be fairly complex. I think the most straight forward solution is to either always assume that for an EMSK generating method the EMSK is either always available or always unavailable. It seems that it is safer to always assume that the EMSK is unavailable and will therefore never be used. I think this has the following implications: - The S-IMCK is always generated from the inner method MSK or the all-zero value if the method does not generate key material. - The EMSK compound MAC is not used - Implementations must have a policy that accepts MSK MACs It would appear that from a cryptographic analysis point of view the MSK and EMSK are equivalent since these keys will only be used in these TEAP calculations and not for other purposes. There are documented drawbacks of using the MSK described in RFC7029 ( https://tools.ietf.org/html/rfc7029#page-12). If the properties of the EMSK binding are needed in the use cases currently under consideration then I think we could redefine the way the EMSK MAC to be computed from the EMSK of the inner method changing the above to - The S-IMCK is always generated from the inner method MSK or the all-zero value if the method does not generate key material. - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK Compound-MAC = MAC( EMSK[J], BUFFER ) - Implementations have a policy that prevents EMSK downgrade to MSK Hopefully there is a more elegant solution. Any ideas? Joe ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] TEAP Errata 5768
On Oct 8, 2019, at 12:45 AM, Joseph Salowey wrote: > > We need to come to resolution on how to resolve these errata. I hope there > has been enough time for implementors to catch up with Jouni's > implementation. Me and my team have been busy, so no progress here. > The Crypto-Binding TLV is fixed at 20 octets and the draft does not say how > to handle longer MACs. > > The discussion seems to indicate that we should make the TLV variable length > to handle longer MACs. > > Is anyone else taking this approach with their implementation? I will, and I think it's a good idea. > Is there any objection to move forward with making the MAC variable length? No. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
