[6tisch-security] DRAFT minutes for 2014-06-09 6tisch security call

[Michael Richardson <[e-mail]>]

https://bitbucket.org/6tisch/meetings/wiki/140609_webex_security

Minutes Webex 09 June 2014, 6TiSCH Security Design Team
Note: timestamps in PDT.

Taking notes (using Etherpad)
  Thomas Watteyne
  Pascal Thubert
  Present (alphabetically)
  Jonathan Simon
  Paul Duffy
  Hank Mauldin
  Michael Richardson
  Nancy Cam-Winget
  Pascal Thubert
  Pat Kinney
  Rene Struik
  Subir Das
  Thomas Watteyne
  Max Pritikin
  Giuseppe Piro

Recording
Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=d930ac29930845ff8e56001fd280f44b
Action Items
  Rene to start a thread on the ML about list of outstanding items.

Agenda

We will continue with the slides that Jonathan Simon posted 10 days ago
slides at http://www.ietf.org/mail-archive/web/6tisch-security/current/pdfiZJLN6CKg0.pdf
Meeting through webex
Webex URL: https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908
we will use with Etherpad
Etherpad at https://etherpad.mozilla.org/ras5RGrQLA

Minutes
[08.04] recording starts
*[Michael]* Note Well applies
[Jonathan] presents slide 2
Feedback about slides about where arrow point
Join request encrypted end-to-end to PCE. Routed for joining node by proxy. Proxy does only routing.
Primary contents of join request is the list of neighbor.
PCE responds with an end-to-end session, a short address, a run-time link layer key, additional information (resources, etc)
question?
No questions.
[Jonathan] moves to slide 3
idea: keep brevity of WirelessHART flow, with ability to use public keys.
in the first step, joining node listens for EB for sync information. Discussion about what kind of key to authenticate that packet. Options:
Simplest is WKK, published in standard. Drawback: does not provide security, but allows to segregate from other protocols. No real authentication provide.
OOB keying. Provides security but not a touch-less operation which is a desired propriety.
Key derived from top-level domain certificate. Assumes that all devices have the same top-level certificate, and that is not sent over the air (presumption is certificate is not sent over the air prior to other key established to protect it). After that, other run-time key established.
joining node asks for the public key of the entity that it is joining.
we want to be able to accommodate centralized (PCE responsible), and distributed (peer responsible for this initial handshake). Depending on what's used, PCE or proxy answers with this key -> the key would be that of the PCE or that of the proxy itself.
idea: use a paired-down X.509 certificate. Probably easy to reduce to 2 packets
request for certificate is optional, and not used if PSK.
next step: send in join request. Envision something similar to WirelessHART: small amount of topology information included, also device's cert (optional if PSK)
join request encrypted end-to-end using certificate obtained in previous step. In centralized case, sent to PCE. In distributed case, sent to proxy node. That device sends back a response.
PCE does top-level domain check. If passes, sends response, similar to that in WirelessHART: assigns a node a short address (more questions in distributed system), run-time link key, and optionally a Diffie-Hellman (DH) handshake to establish an ephemeral key
as in WirelessHART, we now move ahead to establish security session with PCE, assign resources, etc.
[Rene] abbreviated? what do you mean by that?
[Jonathan] one of the things that a TLS session does is provide forward security using DH to establish ephemeral key. Takes more steps, possible to assign a key. We can decide if no-DH solution has the desired security property. Do we believe that we need DH? If no, we can save a couple of packets. Note that this is just for the control channel, the data channel will since DTLS.
[Rene] Do you want to do 2 protocols: one for management, one for data?
[Jonathan] that's the HART model: 2 independent security sessions: one from PCE to network for assigning slots and links, one for application-layer data. Proposes a similar model here.
[Rene] security overhead?
[Jonathan] yes, requires 2 sets of sec counters and keys, we would use same crypto suite, so not much overhead under the hood. We would use the same crypto suite for both.
[Rene] if application and control done by same entity, we could use the same secure session.
[Max] you can reuse the protocol, but we need more packets. Trade-off.
[Thomas] in centralized case with PCE, I'd say that the once the node as joined, data would go to some server in the Internet so that's a different security session. Alternative is the PCE receives the data and then establishes another session but that looks like a weak security.
[Jonathan] assumed 2 independent steps: management and second security
[Rene]: I do not agree that these are different things. Essentially the trust model does not have to be different if these are the same devices.
[Max] the PCE is not trusted for the data.
[Rene] in a simplest model the entity is also handling data the keys could be visible
[Michael] wrong assumption. Even if collocated say WIN95. There will be process separation.
[Rene] assumption: any other device cannot make any other assumption about the visibility
[Michael] don't understand
[Rene] side-tracking, want to understand.
[Pascal] backwards. we are not saying that we cannot enforce that the crypto domains are kept separate (in a device), just that it is not always possible to guarantee that they are not, in particular PCE and server may not be able to share keys.
[Jonathan] big different between I have a single space in my device for keying for memory constrain, different from "we want application and control to have different security constraints".
[Michael] 2 points:
observation: TLS allow you do a re-keying at any point, means that if one decides wants PSK, you can do that later on. If you don't do DH.
questions: about step 4, in the PSK case, it's necessary in step 4 for joining node to encrypt with PSK to prove to PCE possesses PSK, i.e. authenticates with it.
[Jonathan] yes
[Michael] in public key, would the joining node sign the join request?
[Jonathan] yes
[Michael] why encrypt then? what is thread?
[Jonathan] maybe little too literal on WirelessHART, but information sent includes information about the device. Not sure what we would be sending. In the WirelessHART case, you also add information about neighbors etc. The alternative is to just establish the security session, then send that information to the PCE through that session.
[Subir] what is PK? PKI?
[Jonathan] I would not say PKI which implies online systems but it is a PK mechanism assuming some flows like in Michael's B draft.
[Michael] if we do not encrypt to PCE in step 4, there is no need steps 2 and 3. No need to retrieve the certificate from the proxy.
[Thomas] advantage is also that the new device authenticates the network.
[Michael] that actually comes in step 5 when the PCE initiates a session. Before that it has not signed or encrypted anything.
[Jonathan] then when does the joining node need the crypto info from the PCE?
[Max] anytime before sending additional info to the PCE. Whether at step 3 or 5 does not really matter.
[Jonathan] in the flows, the proxy caches the certificate so we avoid end-to-end flows.
[Max] Yes, but then you do not bind the particular request with a domain. If we delay to step 5, we can bind that response to the particular joining node..
[Max] You might authenticate the PCE at step 5.
[Michael] device may join multiple networks, is that what you want? I can imagine a case where a joining mote receives multiple EBs from different networks, and want to be able to choose.
[Max] until you have a 'nonce' from the node, there is no binding and replay 1..3 would be trivial. It is not before you have a message with more detailed info that we can establish a binding.
[Jonathan] there is timing info so simple replay is not easy.
[Max] fake proxy could replay a different certificate
[Subir] is the PCE and proxy already part of the same domain when new mote joins?
[Jonathan] joining node checks that a cert in step 3 assuming that the domain level cert or something that allows to get it is already configured.
[Max] it doesn't know the domain certification
[Jonathan] assume domain level cert already pre-configured
[Max] touch-less?
[Michael] not per se the domain for this network, but some domain level cert
[Jonathan] touch less implies no step where we configure anything individual to that device
[Max] we have a trust anchor, but not per-se this particular domain. We have to do something to make that the case. Whatever that is, we want that to be bound to this particular joining node
[Michael] see end of Etherpad, let's create PRO/CON list for sending certificate in step 3.
PRO on sending certificate in response 3:
the joining node can evaluate whether or not this is a network it would be able to join
CON on sending certificate in step 3 vs step 5:
an attacker can get the joining node to encrypt to any provide PCE PK, its list of information. The joining node has to validate between steps 3/4, so the proxy can never reach out to the cloud. (echoes Max's point)
[Michael] thinking about joining node that is bombarded with EBs, some malicious, some correct. It can go through those nodes and validate them, so doesn't want to try them.
[Thomas] even if no attack but just multiple networks, this may save multiple packets if we can identify the right network early on.
[Michael] CON is that, in the case that a joining node has a party of a certificate chain, it could be convinced
[Michael] advantage about doing steps 2&3, even if many packets, only single hop, no extra BW in rest of network
[Subir] do we need to protect the proxy from proxying too many packets?
[Michael] proxy needs to rate limit itself and send beacons when it can not answer.
[Rene] please read discussion thread DICE: http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00253.html , this deals with DoS attacks
[Max] concern is that joining node is authenticating network in step 3
[Max] validating cert in step 3 but there is no opportunity to talk about that cert
[Subir] proxy will continue to respond, at no point can stop.
[Max] step 3 has no response from the cloud and we can fool the device. Move to steps 4 and 5 then we can have the authentication in step 5.
[Max] the proxy does not reach out to PCE, so response will not contain anything from the cloud. So no cloud binding, so you can have a downgrade attack. If you move authentication between steps 4&5, we can encode information for joining node. The cloud could authenticate.
[Subir] add a message between 2 and 3 where the proxy contacts the PCE/cloud?
[Max] that is one way
[Michael] only way if you want a idevid-like. comment about downgrade attack is interesting. Do you always want to do that? One of the advantages of having comm between 2 and 3 is to get additional information as which network to join. PCE may not respond immediately but one by one between queued requests to streamline
[Michael] PCE can be aware of network congestion due to traffic, go all traffic through one node first, rather than all nodes at the same time. Step 4&5, not clear that need retransmit. How does the node know join request was received?
[Jonathan] simple timeout?
[Michael] what about EB has list of "following join requests have been received", some sort of group ACK.
[Jonathan] sure
[Subir] many different mechanisms possible; mutually authenticate would be good to have
[Michael] 10min left
[Michael] add anything about notes (last slides)
[Jonathan] we need to have a serious discussion about what crypto suites are mandatory, and what we want in the certficate, including ephemeral key. Flow is designed to accommodate pre-shared key with minimal change
[Thomas] want to stress that we need to be able to support both centralized and distributed. The proposal seems to allow that. The other is to support both a PSK and PK model.
[Michael] Jonathan/Thomas/Michael put ideas in document, tried to get that detailed. Will need review.
[Michael] Is there a volunteer to put together a similar doc with ZigBeeIP with EAP-TLS? We agreed to have 2 separate documents. Need a volunteer for ZigBee IP similar process
[Pascal] Since work in Wi-Sun, we want this approach to be discussed.
[Michael] what is Wi-Sun?
[Pascal] alliance for smart grid, things going on there, not sure specs are public yet, but very soon. Aware these exist, good enough to have something. Would like to see this documented.
http://www.wi-sun.org/
[Subir] anyone in this call who has knowledge about Wi-Sun?
[Paul] yes, myself, Nancy have knowledge about this effort. Not documented publicly yet.
[Michael] mostly about metering?
[Paul] Wi-Sun Field Area Network, AMI infrastructure, street lighting, distribution automation.
[Subir] time frame? it is a membership organization correct?
[Paul] it is a membership organization. Tricky question to answer. Confidentiality issues. Working through security discussion. Unclear how to move into IETF/IEEE.
[Michael] suggestion: let's pick a liaison early.
[Michael] any other question?
[Rene] quick question: we discussed a list of outstanding items, put in a list. So far, I don't think we publicly looked at this, and tick them one by one.
[Pascal] Could you start a thread on ML?
[Rene] yes
Action item: Rene to start a thread on the ML about list of outstanding items.
[Rene] we seem to design a crypto protocol on-the-fly. We need to make this cryptographically sound. I can take a stab. We need to have something much more detailed than these flows.
[Pascal] are those two angles to get to the same place?
[Jonathan] goal is to focus on flow and get consensus, We were not deliberately doing something out of order. Get agreement on that, then dive into cryptographic details. First step is to write flow down in document.
[Max] we have the email threads and the bootstrapping documents -- not entirely "on the fly", just an ongoing conversation about the how this impacts the flow
[Pascal] we are progressing on our common understanding with this discussion.
[Michael] we should have something sooner than 7/4. We started in Friday but needs more work. we need review
[Michael] Thanks.
[09.00] Meeting ends

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