# Minutes, 22 Avril 2016 interim, 6TiSCH WG # Note: timestamps in PST. Connection details ------------------ * Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2016-04-22&sln=14-15 * Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=md64a0958ae4154c0553f056bf42b756a * Webex recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=23d221459a7548dd9ae90f91a54a130f Recording password: tDm2jtS3 * Meeting Slides: https://bitbucket.org/6tisch/meetings/ * Wiki: https://bitbucket.org/6tisch/meetings/wiki/160422_webex * Slides: https://bitbucket.org/6tisch/meetings/src/master/160422_webex/slides_160422_webex.ppt Taking notes _(using Etherpad)_ ------------------------------- 1. Thomas Watteyne 1. Pascal Thubert 1. Diego Dujovne Present ------- 1. Thomas Watteyne 1. Pascal Thubert 1. Alex Pelov 1. Chonggang Wang 1. Diego Dujovne 1. John Mattson 1. Lohith Y S 1. Ludwig Seitz 1. Maria Rita Palattella 1. Michael Richardson 1. Nicola Accettura 1. Pat Kinney 1. Rashid Sangi 1. Qin Wang 1. Robert Cragie 1. S.V.R. Anand 1. Savio Sciancalepore 1. Sedat Gormus 1. Seema Kumar 1. Xavi Vilajosana 1. Zhuo Chen Action Items ------------ * Pascal to clean up the mailing list based on voluntary participation * Authors of 6P and SF0 drafts to publish 00 * Authors of OSCOAP to join the security DT ML Agenda ------ * Administrivia [2min] * Approval agenda * Approval minutes IETF 95 * Pending WG doc Adoptions * Security Bootstrap Michael Richardson [10mn] * OSCOAP Goran Selander [40mn] * AOB [1min] Minutes ------- * Administrivia _[2min]_ * Approval agenda * Approval minutes minutes IETF 95 > No issues raised. Agenda and Minutes Approved * Pending WG doc Adoptions * New draft close to adoption - address protection associate unique id on the 6lopwan registration * Call for adoption for SF0 and 6P nothing against them. * Pascal asks Raise hands? Against? * Michael Richardson: For the adoption. Afterwards, other SFs can be created. * Chonggang Wang: I sent comments on metadata on 6P, should be addressed. Section 6: TODO Metadata Definition. * Pascal Thubert: The working group must decide what to be done. * Opposition to adoption? No. Both drafts are adopted. * Republish on IETF with the ietf name change * Do not make any changes. * Security Bootstrap Michael Richardson [10mn] * we should restart with the security ML * Michael will indicate on the sec-ML who is on there * If people want to join the ML, let Michael know * Michael: to Alex Pelov: Send invitation to the ML. I will reach you. * OSCOAP Goran Selander [40mn] * John Mattson: Object Security solution not standardized yet in CoSe for CBOR. * Can be used between one or intermediate proxies. * COSE object to create a new COAP option called security. Independent from transport. Small footprint. * Small messages. End-to-End security, shared key, small number of exchanges. Current plan to ask for adoption in CORE WG in Berlin. * COSE is binary JSON. Add this object to the COAP header. Does not rely on any other identifiers to encrypt or decrypt. * Example (Slide 13) Both in the request and in the response. * Low footprint. Computing overhead low, message overhead low. * Alex Pelov: How to add support on COAP * Need base COAP plus this option. * IDENTIFIER (variable length) 1 byte sequence number (variable length) 2-3bytes COSE encoding 7-8 bytes message integrity CCM 8 bytes missing last item) * Ludwig Seitz from chat: Transaction identifier 5 bytes, AES-CCM-8 tag 8 bytes COSE overhead 9 bytes. * PT: integrity check allowed by 6lowpan. you can save two bytes on UDP. * CW: Comparison of this solution from DTLS? * John: Processing message size, number of round-trips, computational complexity. TODO. Will send it to the ML. * John Mattson: New Security requirements scenario 1 and 2. Scenario 2 node doing caching. * Ludwig Seitz: Master students working. California library C code for embedded still under work release May 10th. People to maintain this code. * Thomas Watteyne: Why not CCM-4? MAc layer CCM-4 tag. 8 bytes may be too much. Security risk? * Alex Pelov: Have the possibility to have a 4 byte tag? * The only difference is how many packets to brute force before obtaining access. CCM-8? 1 out of 4 billion * PT: Can we make the L2 security less expensive if we have this? * Thomas Watteyne: MIC: Auxiliary security DSN and MIC at the end. 4 to 10 bytes. * Robert Cragie: I think CCM_8 comes from TLS. We suggested use of 4 byte tags for CCM AEAD cipher suites but the authors did not want to use that. GCM AEAD cipher suites don't even specify the _8 option. Using a 4 byte MIC on a link layer in a confined network is a different use case to Application layer security. * Michael: Layer3 (meaning and above NOTNT) Only one per packet. Payload is already 1000 bytes layer 2 on every packet. not reduce layer 2 security, repeat it on every fragment. Cannot eliminate in that layer. * Michael Richardson: DTLS can set that up? * John Mattson Need to implement heavy DTLS, it would be better to define this preset key exchange * Thomas Watteyne: How to securely bootstrap a network without DTLS. * John Mattson: Slide 18, graph incomplete. * Robert Cragie: In answer to Michael's question whether you could use DTLS to establish security context for COSE - I guess you could. You would have to export the master key and then close the DTLS session. However, there is no obvious binding between the established key and its use in subsequent COSE-based security. * Michael Richardson: Simultaneously multiple transactions? * John Mattson: Can be (?) * Michael Richardson: 15.4 IE or on IP? * John Mattson: Can run on IEs, where COAP runs, it runs. * Robert Cragie: Only encryption: never. Only integrity check: Possibly * Thomas Watteyne: (Missed question) * Thomas Watteyne: Very good summary on Appendix A, examples. * John Mattson: This will help with my work on 6tisch ML # Thomas shares screen: * We discussed with Goran in Buenos Aires. The idea leverages a central Join coordination entity and PSK, each key associated to a node; a joining node talks to a Join Assistant and through it sends a POST, with an opaque that is sent to the JCE. The JCE validates the encrypted content and authorizes. * Thomas Watteyne: Now that JCE knows the device is there. Now there is a need for key K2 for data. THere may be a preprovision. But the JCE could also post K2 to the device using OSCOAP and the device is now operational for data. * Michael: Happy that the OSCOAP is that far along * Thomas Watteyne: authors please join 6TiSCH security design team. Note that there is not much 6TiSCH specific Apart from mentioning K2. * John Mattson: Very happy to hear feedback and hope this is adopted in 6tisch. We will join the security design team. * Robert Cragie: Re. OSCOAP on 6tisch slide: I think you would need at least a 3-way challenge-response handshake at the beginning. Request/response is not probably not enough * AOB [1min] * Thomas Watteyne: next call in 3 weeks. May 13th.