Minutes Webex 20th May 2014, 6TiSCH Security

Taking notes (using Etherpad)

1. Pascal Thubert

Present (alphabetically)

1. Hank Mauldin
2. Michael Behringer
3. Michael Richardson
4. Maik Seewald
5. René Struik
6. Tom Phinney
7. Yoshihiro Ohba

Recording

• Webex recording

Agenda

1. Look at Join Protocol

Action Items

1. Michael R. to suggest to the list a review of draft piro
2. Michael B. to check with Max Pritikin about format on authorization token.
3. All to review email RS as of May 20, 2014, 9:45am EDT and give feedback re details identified outstanding issues

   e-mail at: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html

Minutes

• [07.10] Meeting starts

Michael Richardson: network manager programs the device, no particular authorization of the network to the device, nor way for device to prove it is authorized apart from having the join key provisioned

René Struik: unless missing something, need size of configuration messages. How to get tag names in the device and map that into 802.15.4 MAC addresses. Details we do not really have. Unclear how device can discover the network. Ties in AR certificate issue

Michael Richardson: problem exists regardless of actual enrolment process.

René Struik: there is also a control element when certificate can be used

Michael Richardson: sent message on Wile coyote; is it realistic?

René Struik: quick feedback. say vendor generates cert for bunch of devices and it goes along a chain and then more attributes allow link back to factory. works, does not have to be AR certificate

Michael Richardson: I expected the kind of certificate I describe in AR but it is not the point of AR. They do not even specify the format of device ID. AR is really about an API not about content of certificate apart from signature algorithm for which they have requirements. They do not even define their own extensions. One extension with multiple values

Michael Richardson if you use secure enrolment, you can replace the cert but you still need to validate the device. Need Michael B. and Max to describe their token

Michael Behringer: AR or not AR? process is about an institution that owns a device and has a secured relationship based on a certificate that tit signed. Can be 1AR or anything, e.g. an institution which owned the device before. Need that cert from old organization to help bootstrap in new organization.

Michael Richardson: did you define how the authorization token can be passed in an interoperable fashion

Michael Behringer: leverage secure relationship between vendor and device to pass a signed message to the device

Michael Richardson: does it bind to the new owner? which way, not subject to standardization or is it?

Michael Behringer: May not need standard, but if multivendor network user would like a common format. between vendor and new device can be proprietary

Michael Richardson: need ot define when how the token is transported, and that is not end to end. reasons of trust, rate limit etc...

Michael Behringer: new device sends along a nonce and expect that nonce in response from vendor site; without nonce, token could come from the past. Both models are required in the market. Some want fresh, others e.g. military there cannot be comm at the deployment time.

Michael Richardson: content of token may or not be standard. transport of token must be standard.

Michael Richardson: using RFC 3779 would address cert that had 1AR IdevID in them. need a range in the certificate otherwise one certificate per device

Michael Behringer: token or certificate?

Michael Richardson if the token is a certificate need a way to delegate down the chain. But breach along the way breaches it all below. no good. Do you have to maintain a cert for every device?

Michael Behringer: that's the starting point. You assume that's a scalability issue at some point right

Michael Richardson: provisioning trouble is possible. Tracking by bulk could be more palatable

Michael Behringer: if name space is aggregatable could work. In early approach, token is not a cert and stealing the token does not help.

Michael Richardson: anxious about spare parts that did not join, and go unserviceable

Michael Behringer: yes, we can take the req in draft-pritikin

Michael Richardson proposing do something like RFC 3779. It as AS numbers to allow reg to delegate using cert; these are live devIDs from a pool. should look at that doc and we could change all AS to IdevID and we'd be done.

Michael Behringer: sounds like an idea we'll look at it

Michael Richardson: draft pritikin does not tell whether the enrolment allow transport of authorization token back and forth and then the cert for the TLS transport can be validated. Then you have a secure transport and can enrol replacing the vendor cert with a domain cert.

Michael Behringer: refer to a mail by Max Pritikin "[6tisch-security] a different explanation of autonomic" .

Michael Richardson: where is the process ?

Michael Behringer: explained in message. We need to mail this down so people understand.

Michael Richardson: non normative

Pascal Thubert: yes that is what we want in the security architecture

Michael Behringer I need to leave soon

Michael Richardson: I answered to draft piro descries low level stuff. I want to encourage people to read and suggest that this becomes WG doc in L2 layer 2 security. It is a very good draft. We may need to change the authorization but after that, great stuff can be found. Should be WG doc somewhere.

René Struik: thoughts appreciated on mail I sent today

Pascal: Next call on Tuesday next week same time

• [08.06] meeting ends

======