Subject: [6tisch] Minutes Webex 20th May 2014, 6TiSCH Security

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 20 May 2014 15:38:12 +0000

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<https://cisco.webex.com/ciscosales/lsr.php?RCID=cf234f58e8f94d2f86fbe15e7d6862df>
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.
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

======

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 May 2014 11:52:18 -0400

Hi Pascal:

I would like to suggest adding one more action item:
All to review email RS as of May 20, 2014, 9:45am EDT and give feedback 
re details identified outstanding issues.

Rene

==

On 5/20/2014 11:38 AM, Pascal Thubert (pthubert) wrote:
> ------------------------------------------------------------------------
>
>
>     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 
> <https://cisco.webex.com/ciscosales/lsr.php?RCID=cf234f58e8f94d2f86fbe15e7d6862df>
>
>
>     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.
>
>
>     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
>
> 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 Behringer: leverage secure relationship between vendor and 
> device to pass a signed message to the device
>
> 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: using RFC 3779 would address cert that had 1AR 
> IdevID in them. need a range in the certificate otherwise one 
> certificate per device
>
> 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: if name space is aggregatable could work. In early 
> approach, token is not a cert and stealing the token does not help.
>
> 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 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 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.
>
> ·/[08.06]/meeting ends
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 May 2014 08:23:14 -0400

Rene Struik <[email-masked]> wrote:

    > b) the draft introduces new 802.15.4-command frames to implement the key
    > negotiation phase (Section 6.3). As such, this would constitute a
    > change to the
    > 802.15.4-2011 and 802.15.4e-2012 specification. Besides, this also
    > implies that
    > the key negotiation phase can only deal with one-hop behavior.

It could be like, Zigbee with MLE, that one wants per-hop keys that are
unique across the network.  This has implications for broadcasts, of course.
If one looks at the M_k as not being pre-configured, but rather being
installed via the join process, then it isn't such an mismatch to what has
been proposed in the 6isch-security design team.
Otherwise, it wasn't so much the section on key derivation that I cared
about, as much as the rest of the document.

    > e) the key negotiation phase using the anonymous Diffie-Hellman scheme
    > (Section
    > 6.3.3) that uses ordinary Diffie-Hellman groups in the ring of integers
    > Zp, where p is a prime number that indexed by a publicly computable
    > integer

My opinion is that it is inappropriate to specify any crypto different from
what would already be there for (D)TLS.  Run it over PANA or MLE...

    > f) the 802.15.4-2011 specification mistakenly does not allow mixing of
    > secured
    > and unsecured traffic (see, e.g., my emails of end of January 2014 on
    > this). In
    > particular, the hybrid security network (as mentioned in Section 5) is
    > not
    > possible with 802.15.4-2011 or 802.15.4e-2012.

Agreed, and that's another reason to specify against 4e-2012.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 22 May 2014 17:42:44 -0700

Rene,
Minutes updated at
https://bitbucket.org/6tisch/meetings/wiki/140520_webex_security,
copy-pasted below.
Thomas

---

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<https://cisco.webex.com/ciscosales/lsr.php?RCID=cf234f58e8f94d2f86fbe15e7d6862df>

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

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 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 Richardson: anxious about spare parts that did not join, and go
unserviceable

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 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 Behringer: explained in message. We need to mail this down so
people understand.

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.

   - *[08.06]* meeting ends

======

On Tue, May 20, 2014 at 8:53 AM, Rene Struik <[email-masked]> wrote:

>  now also to the 6tisch-security list (rather than 6tisch list).
>
>
> On 5/20/2014 11:52 AM, Rene Struik wrote:
>
> Hi Pascal:
>
> All to review email RS as of May 20, 2014, 9:45am EDT and give feedback re
> details identified outstanding issues.
>
> Rene
>
> ==
> ------------------------------
>  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
>
> ·        *[07.10]* Meeting starts
>
> authorization of the network to the device, nor way for device to prove it
> is authorized apart from having the join key provisioned
>
> 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
>
> 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 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: using RFC 3779 would address cert that had 1AR IdevID
> in them. need a range in the certificate otherwise one certificate per
> device
>
> 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 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.
>
> 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 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.
>
> ·        *[08.06]* meeting ends
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> --
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>