Subject: [6tisch] Fwd: RE: (review draft-piro-6tisch-security-issues-01) Re: Minutes Webex 20th May 2014, 6TiSCH Security

From: Rene Struik <[email-masked]>
Date: Wed, 21 May 2014 08:57:16 -0400

FYI.

-------- Original Message --------
Subject: 	RE: (review draft-piro-6tisch-security-issues-01) Re: [6tisch] 
Minutes Webex 20th May 2014, 6TiSCH Security
Date: 	Wed, 21 May 2014 09:22:42 +0000
From: 	Pascal Thubert (pthubert) <[email-masked]>
To: 	Rene Struik <[email-masked]>, tisch-security 
<[email-masked]>

René,

Could you please copy the 6TISCH ML?

Cheers,

Pascal

*From:*Rene Struik [mailto:[email-masked]]
*Sent:* mardi 20 mai 2014 18:47
*To:* Pascal Thubert (pthubert); tisch-security
*Subject:* (review draft-piro-6tisch-security-issues-01) Re: [6tisch] 
Minutes Webex 20th May 2014, 6TiSCH Security

Dear colleagues:

As suggested by Michael Richardson, I briefly reviewed the 
draft-piro-6tisch-security-issues-01.

Some suggestions/feedback:
a) the draft relates to 802.15.4-2011. I would suggest making this 
relative to 802.15.4e-2012 (which describes the TSCH protocol and 
corresponding MAC extensions).
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.
c) the key negotiation protocol deals with authenticated key agreement 
and does not consider potential authorization steps.
d) it is assumed that each node is preconfigured with a master key M_k 
that is shared amongst all devices (Section 6.1.1), from which default 
keys D_k are derived using a publicly known function (with potentially 
other inputs, which are to be assumed publicly known). This seems to 
imply that all default keys can be considered as publicly known strings (!).
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 (Section 6.3.1, Step c1)) and where p has at least 
bit-size 128 (see Appendix A.1). The ordinary Diffie-Hellman problem in 
integer rings Zp of this order of magnitude sizes is efficiently 
computable, thereby rendering this scheme completely insecure (I already 
commented on this when reviewing draft r0 of which this draft is an 
update (see 
http://www.ietf.org/mail-archive/web/6tisch/current/msg01481.html))
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.

Best regards, Rene

On 5/20/2014 11:38 AM, Pascal Thubert (pthubert) wrote:

      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

    ======

    _______________________________________________

    6tisch mailing list

    [email-masked]  <mailto:[email-masked]>

    https://www.ietf.org/mailman/listinfo/6tisch

-- 

email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363