Alan DeKok <al...@deployingradius.com> wrote:
> On Feb 14, 2025, at 4:23 PM, Michael Richardson <mcr+i...@sandelman.ca>
wrote:
>> This the second of two messages.
>> TL;DR> section 5.2 is much changed, but I think you'll have to start
again.
> I'll take a deeper look at your messages and respond next week.
> In short, if anyone is confused by the text, it needs updating.
I think that I can suggest a different way to explain this.
My understanding is that the difficulties arise because when inner methods
that did not derive MSK or EMSK that there were variations.
I thought that inner methods like that were supposed to be deprecating or
even invalid. I'm unclear now about that.
1. I suggest a diagram for paragram four, "For each inner method..."
2. I suggest a diagram for the overall process.
3. I suggest going top-down, rather the unclear mix, but which seems bottom
up to me.
5.2.1: when do we have EMSK's and not MSKs? Which inner methods?
} The above derivation is not a requirement, as some peer
} implementations of TEAP are also known to not derive IMSK from EMSK,
} and to only derive IMSK from MSK. In order to be compatible with
} those implementations, the use of EMSK here is not made mandatory.
I don't understand how there can be variability here.
} A better
} solution is to suggest that deployments of TEAP SHOULD avoid such
} methods.
I'd like it to say, "TEAP v2 compliant implementations do not use inner
methods X,Y,Z"
> There are multiple interoperable TEAP implementations in the wild. At
> this point, I think the document should reflect shipping code. If that
> means we later decide to change key derivations and issue TEAPv2, then
> we can do that. But the most important thing is to document
> functionality.
I think that there were exceptions/uncertainties
> The downside here is that I've spent significant efforts trying to
> understand existing deployed functionally. I still don't have a clear
> picture of what everyone does. The main unknown is the EMSK
> Compound-MAC.
> I suspect the answer is that everyone uses the MSK Compound-MAC, and
> ignores the EMSK Compound-MAC. If so, it needs to be documented.
I'd prefer that the section explain the goal/ideal, and then mentioned when
field experience differs. In particular, could implementations avoid all the
exceptions by avoiding certain inner methods?
I think the WG should seriously consider burning version 2 and say that it
applies to the key derviation with no exceptions.
As you said, this all needs feedback from implementers.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
