>
> Sorry, did not read this email before sending the previous one.
>
> I don’t understand what do you consider as a start state of JN here, when it
> first tries to join. Is it a certificate or a PSK?
>
> I think we agree that with PSKs, JA cannot help much?
>
> With certificates, I agree with you that *if* JA could authenticate the JN
> before forwarding the message, it would reduce the risk but still wouldn’t
> completely eliminate it, as JN needs to be authorized by JCE to join. The
> details would depend on the exact forwarding mechanism and if/how we decide
> to use COSE…
>

With PSK, JA cannot help. I believe this is true.  I also agree that
JCE may authorize JN.

I'm just thinking to a mechanism that may help JA to authenticate
locally JN. I've called this mechanism "pre-join" scheme. The name
could be not correct at all, let's just try to understand if it could
be useful or not :-)

JN sends its certificate to JA ... and other fields that demonstrates
the posses of the private key associate to the certificate, like the
sign of the (ASN + Mac address).. or something like that.

If JA knows the CA, it is simple to find the end of the story. If
not... we can define multiple behaviors:
- accept anyway the initialization of the join process and give the
change to authorize JN to the JCE
- discard the message (this cannot be acceptable for networks made up
by nodes provided by different vendors, as you said in your mail)
- retrieve the CA's public key elsewhere and then come back to JN

What do you think ?

Giuseppe







-- 
Giuseppe Piro, PhD
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email protected]
phone: +39 080 5963301
web: telematics.poliba.it/piro

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to