On Mon, 28 Aug 2023 at 21:09, Alexander Clouter <alex+i...@coremem.com> wrote:
> On Mon, 28 Aug 2023, at 15:43, Heikki Vatiainen wrote: > > > >> If an inner method supports export of an Extended Master Session Key > >> (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in > >> [RFC5295]. > > > > Why the SHOULD? If something else is done, how could it work with other > > implementations? > > Not to suggest it as a good idea, but maybe someone wants a policy that > forces MSK only? > Hmm, I read it as the recommended way of how IMSK is derived from EMSK not as 'if you decide to use EMSK, then it must be done like this'. In other words, I thought it left door open for other ways to derive the IMSK. Now it makes sense. > So the EMSK is available and you SHOULD use it, but you administratively > have disabled it so both ends just use the MSK. > > No idea why you 'WOULD' do this though... > My colleague just pointed out that a lazy implementation can simply always ignore EMSK and still be compliant. Would being lazy be a good reason? -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
