[6tisch-security] certificate cache discussion recap from 2014-06-16

[Michael Richardson <[e-mail]>]

Monday, on the call I asked the group a couple of questions relating to the
time sequence diagram from Jonathan.

1) given assymetric crypto is there any reason for the JOIN REQUEST from the
   joining node to the PCE (message 4) to be *encrypted* to the PCE?
   (Clearly, it needs to be signed by the joining node)

The conclusion was that there are things in WirelessHART which were decided
were sensitive, and thus the packet was encrypted.  It was concluded that if
there is anything left that is sensitive that it can probably be moved to
step 5/6.
Leaving out the asymmetric encryption likely saves around 300 bits in the
packet as well.

2) having gotten rid of the (assymetric) encryption, the question then
becomes: do we need to do a certificate request/response at all? (steps 2/3).

Some things that were said on the call:

  a) it has been suggested that the address of the PCE would be an attribute
     on the certificate that is returned.

  b) it has been suggested that the certificate (chain) that would permit the
     joining node to be able to validate the PCE's identity, and therefore
     determine if this network is worth joining.

  c) there are some significant concerns if (b) is the only way that the joining
     node can determine if this is the correct network, that this is putting
     far too much policy and intelligence in the joining node.

  d) there is concern that given the complexity; that consumer devices may
     well just join whatever network they see first.

  e) at the same time, there is concern that message 2/3 does not involve any
     opportunity for a trip to an online database for higher value joining
     nodes.

  f) it was suggested that a joining node should record PANIDs to which it
     has attempted to connect to, and failed, and therefore it would not
     continuously failing to connect.

  g) it was suggested (by me) that even a partical certificate chain could
     be useful in selected a network to join.

The question was asked, if the message 2/3 exchange can never provide enough
authorization for a joining node to determine which network to join, then an
alternate question was asked:
  - is there something which can be cached by the proxy, such as part of
    the PCE certificate chain, which would usefully reduce the number of
    messages that need to traverse the entire LLN for each joining node.

A number of people expressed an interest in keeping the message 2/3 exchange
as an optional part of the protocol.  I don't like optional pieces, and I
would want to signal if message 2/3 should occur in the EB, or to always do
the message 2 request, and permit empty replies.

If you go back to my email at:
   https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00

I had four links in the particular certificate chain that would permit the
joining node to authenticate the PCE.

   *1* Factory:       ACME
   *2* National-VAR:  Cadabra
   *3* Regional-Var:  Sesame
   *4* Plant:         Coyote

The factory certificate (1) would be built into the joining node as a trust
anchor.   If message (3) contained certificate *2*, perhaps also *3*, then that
would significant help the joining node to know that this might be the right
network to join, and it would reduce the number of bytes sent all the way.

Some problems/issues with this include:
    i. certificate *2* of the chain could be very specific to a particular
       device, so might be unsuitable for caching.
   ii. request (2) would have to include the DN of the trust anchor
       certificate *1* in order to indicate which vendor's certificate should
       be returned from the proxy.   Naturally, this opens things up to having
       as many certificates cached as there are factories X VARs.
  iii. at the DTLS stage, if additional parts of the trust path have been
       cached, then this needs to be indicated when the joining nodes issues
       it's CertificateRequest as part of it's ServerHello exchange, so
       that only part of the certificate chain is sent.
   iv. worse case, the entire certificate chain has to be sent at the DTLS
       stage.

If the PCE has a certificate chain which is not per-IDevID, and yet is
anchored at the factory installed trust anchor, then maybe this would have
higher utility.

While I can see the PCE having a certificate anchored in a local CA, and I
can see that as part of the join process, the joining node would have this
new trust anchor installed (along with a certificate of its own), I think it
is important to remember that this occurs *post* join.

In particular I want to make sure that everyone understands that the
(successful) join protocol occurs only once after the device has been turned
on (and/or factory defaulted in some OOB way).  It does not occur every time
the device powers up --- the join protocol would have installed the correct
PANID, L2-Key, etc. into the device.

So my conclusion is that there is little that we can cache on the proxy.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-