Re: [6tisch-security] EALS and how to go from 6tisch-minimal-security to zero-touch enrollment

[Mališa Vučinić <[e-mail]>]

> On 11 Mar 2017, at 22:39, Michael Richardson <[e-mail]> wrote:
> 
> Your description is too simple, and I don't think it makes any sense to put
> it here. I think it should simply refer to dtsecurity-secure-join.

I think that we definitely need to expand somewhere on the security handshake in minimal-security document, it is a matter of preference where the section should exactly go. The overview sections only show the security handshake as a single transaction between JRC and the pledge. I’ve put the expanded security handshake in the current place in order to precede the simple join protocol section that similarly expands on the join request/response exchange. What part do you find too simple? The paragraph on special certificate being issued to JRC? If so, what text do you propose to replace that?

> As for the Discovery Message, this seems reasonable.
> Is this process optional, or is it caused by the init bit in the EB being
> clear?

To my understanding, init bit is there to differentiate between the minimal-security and NS DAD dtsecurity-secure-join processes. Ideally, I think it would be great if we could converge on the initiation process between the two documents with the Discovery Message, therefore removing the need for the init bit. In minimal-security, Discovery Message is mandatory *when* performing the security handshake. The security handshake, however, is optional and is performed in case the pledge was provisioned with asymmetric keys. The decision what message to send first, i.e. the Discovery Message or the Join Request, is internal to the pledge and depends on the credential it has been provisioned with. 

> It needs to have a mandatory reply so that the pledge knows that it has
> succeeded in reaching the JRC.  

The reply to the Discovery Message is either an empty CoAP ACK signaling to the pledge it has reached the JRC but needs to wait, or an immediate response from JRC initiating the EDHOC handshake. Either way, pledge knows it has succeeded in reaching JRC. Which response JRC opts for could be dependent on how many pledges are currently enrolling.

> A reply from the JRC might also need to
> indicate that the pledge should proceed to initiate?

I don’t understand, could you elaborate?