Hi Peter, See inline.
Mališa > On 16 Dec 2016, at 09:17, peter van der Stok <stokc...@xs4all.nl> wrote: > > Hi Malisa, > > Just one point to understand the temporary secure link between JN and JA. > >>> Consequently, that means during the whole bootstrap process the link >>> between JA and JN is not secured by layer2 keys. >> This is still under discussion within the design team, but the >> conclusion is the same — we can’t provide any L2 security at that >> point because L2 keys are simply not known. One option is to use >> well-known K1 to provisionally protect the join packets at L2 but this >> of course does not provide any security other than helping to >> bootstrap L2. Another option is for JA to simply accept unsecured >> packets at L2, and make it an exception for join traffic, potentially >> only during the duration of the join process. > I like to state the objectives of the "temporary secure link" (TSL) between > JA and JN as I see them. > Sorry for stating the obvious. > > The security objectives for the TSL are: > (1) When the JN is correct, malicious nodes cannot decode the key exchange > between JN and JCA or replay them. > (2) When the JN is malicious, > (2.1) the TSL keys cannot be used to decode the key exchange over other TSL's > or replay them. > (2.2) the TSL MUST be restricted to a set of messages to prevent the > malicious node from misusing the network. > > Protocol choices are: > The selection and generation of TSL keys. > The selection and enforcement of message sets. > > Do you agree? Is there more? > I repeat these objectives because especially objective 2.2 seems to be > silently understood or ignored; although you seem to mention them in the text > above. We seem to diverge around the ‘security’ notion of the Temporary Secure Link (TSL) between JN and JA. Instead of TSL, I would rather call it Temporary Insecure Link (TIL), because that’s what it really is — insecure. JA is considered untrusted so it cannot authenticate or moreover authorize JN to join the network so that it must accept frames from any JN. Note that there is no PSK or RPK available on JA, and in case of certificates any node under a common CA would authenticate while in case of Phase 1, JN and JA wouldn’t even have a common CA. That said, in case JN is malicious, it can inject frames at will, being it the replay of another session or simply bogus traffic, the defense against which is to implement rate limiting at JA and detect it at JCE. Therefore, I question the need for (2.1). As per objective (1), this is met already as malicious nodes cannot decode the key exchange since it is protected end-to-end. They are able to record the exchange on TIL and replay it to another JA but this will be rejected by the JCE. > Selecting messages on destination address in JA, may allow setting up a path > between JN and JCA where JN uses a global address, provided by JA. The problem I see there is that we would need to provide a network prefix to JN before it has joined the network, which is a privacy threat. Right? > That will simplify the replacement of EST over CoAPs by your EDHOC, OSCOAP > protocol and vice versa. > > As expressed earlier, I like to define separate protocol parts which can be > changed during technology evolution. > Is that a design consideration you want to take into account? Definitely. It would be helpful if you could go through the draft and identify the points that you consider as problematic with respect to future evolution of TSCH/6TiSCH. > Peter _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
