Hi Alexander!
Zooming down:
On 02.01.23 12:10, Alexander Clouter wrote:
Fewer conditionals/branching points in implementations?
At the moment the rule is "start with S-IMCK[0]" and then both:
* mix in MSK goodness and track that progression
* mix in EMSK goodness and track that progression
If we ignore that the RFC should have stated MSK/EMSK needs to be
handled separately for IMSK/IMCK purposes, this is mostly straight
forward.
My use case is IOT. I'm interested in two states:
* Nominal: everything looks very similar to EAP-TLS.
* Exceptional: a new certificate or a new trust anchor or something
else is needed. In which case, I would expect the server to push a
“request action” TLV.
In either case, there is no inner method. So either the calculation
should not assume S-IMCK[0] exists, or we must define what that means.
Currently in our POC implementation we are following Jouni's example
that he used for basic auth. What I am concerned about is leading
implementors or their users to believe that an operation provides any
additional security when would does not. So at the very least, we
should be considering what to put in Security Considerations about this,
but i the op really provides not value, we should consider the resource
consumption of the operation against the code complexity.
Regards,
Eliot
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
