Minutes Webex 20th May 2014, 6TiSCH Security
Taking notes (using Etherpad)
- Pascal Thubert
- Hank Mauldin
- Michael Behringer
- Michael Richardson
- Maik Seewald
- René Struik
- Tom Phinney
- Yoshihiro Ohba
- Look at Join Protocol
- Michael R. to suggest to the list a review of draft piro
- Michael B. to check with Max Pritikin about format on authorization token.
- All to review email RS as of May 20, 2014, 9:45am EDT and give feedback re details identified outstanding issues
- [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