Re: [Emu] RFC 7170 (TEAP) errata
On Jul 22, 2019, at 1:50 PM, Joseph Salowey wrote: > [Joe] I'd like to hear if anyone has an implementation, and how they > implemented on a cipher suite that is not SHA-1. TBH, I haven't seen an implementation. I suspect that the lack of implementations is why these questions are only coming up now. > My feeling is that it would be better to make the TLV length variable with > the hash length. However, I do not see why truncating would work as well. My $0.02 is to allow a variable TLV length. I think it's OK to leave these as errata now. I'm not sure that any existing EMU document would be appropriate for these changes. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170 (TEAP) errata
On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote: > > > (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive > both MSK and EMSK (or even more complicated, if there are multiple inner > EAP authentication methods that have difference in whether they derive MSK > or EMSK): > https://www.rfc-editor.org/errata/eid5770 > > [Joe] I'd like to hear from implementers on this one. I think the intent is that section 5.4 should say the S-IMCK is generated as specified as described in section 5.2. Section 5.2 does provide a mechanism to derive the S-IMCK at the end of the section. Each IMCK can be derived in one of 3 ways: - MSK - EMSK - 0s if the method is not key generating There is ambiguity on how to derive each IMSK in the case that both sides do not have the same capability to export the EMSK. I think the steps involving the compound MAC are meant to disambiguate this situation. Is the problem that the section does not explicitly say how to use the compound MAC sent to determine which IMCK derivation to use? > I'd hope to avoid having to guess or make my own specification of how this > is supposed to work before being able to implement this (and then have to > re-implement everything if others disagree with that interpretation/guess > on the design), so any feedback on these items would be very welcome so > that there would be a general agreement on how the protocol is supposed to > work to provide better chances for getting interoperable implementations. > > - Jouni > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170 (TEAP) errata
On Mon, Jul 1, 2019 at 4:11 PM Jouni Malinen wrote: > > > (1) Crypto-Binding TLV format for the cases where the negotiated TLS > cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and > I'd hope all deployments of TEAP would be recent enough to avoid use of > SHA-1..): > https://www.rfc-editor.org/errata/eid5768 > > > [Joe] I'd like to hear if anyone has an implementation, and how they implemented on a cipher suite that is not SHA-1. My feeling is that it would be better to make the TLV length variable with the hash length. However, I do not see why truncating would work as well. > > - Jouni > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
