A clarification question from an implementor (me) in the context of constrained BRSKI state machine.
The /att and /crts requests do not do anything to change the state of client or server. It would seem that it might be safe to permit clients which have not yet authenticated to do this operation. (/att gets CSR attributes, and /crts gets the list of trust anchors) When EST-COAPS is used on its own, there usually needs to be a manufacturer trust anchor installed on the Registrar before any connection will be permitted. When EST-COAPS is used as step 2 of constrained-BRSKI, whether or not the Registrar will accept any (and all) connections depends upon configuration of the operator. Some devices might not be doing BRSKI (not need to, they already trust the operator, but they might still have IDevID only. This might happen during a transition) If the Registrar is "open" to new manufacturers, should the Registrar permit /att and /crts actions to be done by clients that it does not recognize? The /att call on an ANIMA ACP network would reveal to the client the ULA that would be used for that client (and perhaps other interesting things), and the /crts would show the name of the operator. Note that the later info probably is revealed just by doing the TLS handshake. I think that they should be restricted in general, but I'm concerned that there might be some situation I've missed. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
