One document matched: draft-richardson-smartobject-security-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY I-D.phinney-roll-rpl-industrial-applicability SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.phinney-roll-rpl-industrial-applicability.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-richardson-smartobject-security-00"
     ipr="trust200902">
  <front>
    <title abbrev="Abbreviated Title">Challenges in Smart Object Security: too
    many layers, not enough ram</title>

    <author fullname="Michael C. Richardson" initials="M."
            surname="Richardson">
      <organization abbrev="SSW">Sandelman Software Works</organization>

      <address>
        <postal>
          <street>470 Dawson Avenue</street>

          <city>Ottawa</city>

          <region>ON</region>

          <code>K1Z 5V7</code>

          <country>CA</country>
        </postal>

        <email>mcr@sandelman.ca</email>

        <uri>http://www.sandelman.ca/mcr/</uri>
      </address>
    </author>

    <date year="2012"/>

    <!-- Meta-data Declarations -->

    <area>Security</area>

    <workgroup>Smart Object Security Workshop</workgroup>

    <keyword>workshop</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This is a position paper for the pre-IETF83 Workshop on Smart Object
      Security. The author contends that layer-2 security solutions are not
      only in-adequate, but may in fact be harmful when deployed into smart
      object systems. While layer-2 security services may be valuable, they
      must be channel bound up to the layer-7 application layer.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The ROLL RPL specification provides an optional layer-3 security
      mechanism. The WG did not focus very much on making this security system
      useable, as most WG participants assumed that layer-2 would provide all
      the security that most deployments would want.</t>

      <t>While the ZigBee 2007 is provides a stack up to the application, and
      clearly articulates the role of the application in the security system,
      if ROLL RPL applicability statements specify Zigbee at all (XXX), from
      Zigbee's point of view the "application" is IPv6. The security provided
      by Zigbee 2007 does not get translated up to the IPv6 application, and
      certainly is not leveraged for end-to-end security.</t>

      <t>Other specifications, including 6LowPAN (mesh-over) and ISA100 use a
      network key essentially identical to the 802.11 WEP. While many of these
      specifications propose to upgrade their mechanisms to include WPA-like
      usage of EAP, this does not solve the fundamental security problem of
      *authorization*. Except for auditing purposes, the network does not care
      who the nodes are, but rather, are they authorized to perform a
      particular function. In the context of RPL, one of these key functions
      is routing of packets.</t>

      <t>A good example of the lack of security feature is that it is
      impossible in RPL to create a network where some nodes are authorized to
      route packets, while other nodes are not. While the specification
      supports this when doing layer-3 security, it only supports it for
      asymmetric security methods, widely regarded as too expensive for small
      devices. If the security is provided by a layer-2, then even if
      asymmetric methods are used in that layer, they are not available to the
      RPL (or higher) layers.</t>
    </section>

    <?rfc needLines="8" ?>

    <section title="What we need">
      <t>What we need is a security service implemented in layer-2 or layer-3,
      which not only provides for the privacy and integrity that is typically
      sought, but also can be leveraged by upper layers (including the layer-3
      routing layer), to make authorization decisions.</t>

      <t>Layer 2 alliances have created detailed and complex security
      specifications for wireless connectivity of smart objects. The
      requirements seems to have driven by existing early adopters of building
      and industrial automation. For many of the participants, security has
      become magic pixie dust provided by the vendor of the layer 2
      MAC/radio.</t>

      <t>I had believed that layer 3 security was more appropriate and easier
      to deploy/update. While requiring possibly more software code space, it
      might have a lower transitor count as flash is sometimes cheaper than
      complex logic in a MAC.  But, I wondered who would need such flexibility
      among current industrial and smartgrid users of ROLL? Maybe it just
      my desire to do ubiquitous l3 networking with strangers on the bus,
      and I should shut up and believe that l2 security is enough.</t>

      <t>Then the ROLL WG came to applicability statements, and it has obvious to 
      me that people installing industrial equipement have much more complex
      requirements than I could even imagine on the bus.  On the bus, I most
      trust everyone exactly the same: if they get my cryptographically 
      signed packets to my intended destination, then I'm happy.  I have really
      only one level of authorization: I either let you route my packets,
      or I do not.  If I do not trust you to route, I might still trust you
      to have a cached copy of some data I want, and I have a way to 
      authenticate the data itself.
      </t>

      <t>
      The home automation users of ROLL was where I figured the most 
      complexity would occur, and this relates mostly to how guests and 
      children in the home will interact with the home system(s). While the 
      lighting and appliance control network in the home looks very much like
      an commercial building system, how the occupants of the home interact
      with this system is not well defined as yet.  It is likely that 
      initially all interaction will be via hard controls ("light switches"), 
      or via a gateway system that not only connected the 802.11 and 802.15.4
      networks, but also provided an authentication and authorization system
      between the two networks.  The ROLL provided security need concern itself      only with whether or not a device was part of the home network or not,
      something that layer-2 security can do.
      </t>
      <t>
      However, smart phones and personal area networks will begin to get 
      802.15.4 interfaces, and in some cases home automation is escrewing 
      802.15.4, claiming that 802.11 is now so cheap (power and 
      bill-of-material) that it makes no sense to assume/require a gateway 
      device.  This is where, I thought, the multi-level authorization security
      would be required, and this would be subject to much innovation, with
      a number of home automation systems proving inadequate and being upgraded
      or replaced over time.
      </t>
      <t>
      I thought that only when we have house guests (consider a teenage child
      to be an extended stay house guest) that we would run into troubles: we
      definitely want to authorize our guests to do many things in our homes,
      but there are many things we do not want them to do.
      </t>

      <t>
      What I did I not expect was that industrial users would in fact require 
      a multi-level authorization system, and have rekeying and trust issues
      more complex than that of the home.  It was once explained that the
      militaries aren't into authorization: they care about authentication
      and auditing.  A soldier must always have the ability to exceed their
      authority, because sometimes it's the right thing to do, and if they did
      the wrong thing, they have the court martial to solve this problem.
      </t>
      <t>  
      The court martial is not a solution for the industrial ROLL user. 
      The various modes of operation described in 
      <xref target="I-D.phinney-roll-rpl-industrial-applicability" />
      require several levels of trust.  While layer-2 security has a place,
      it seems that the installers of the devices (who would have to 
      configure the layer-2 security) are not to be trusted in the long term,
      and therefore some way to change layer-2 keying material needs to be
      standardized.
      </t>

      <t>
      If during any unplanned (i.e. emergency) situation new equipment
      will be brought 
      into the plant to aid in recovery, that this equipment either
      will need to be configured (by regular plant personal) with the
      right security, or it will be necessary to either turn off or revert
      security to some other more minimal configuration, such that 
      the equipment can be used.
      </t>

      <t>It appears that not only is LAYER 2 security is not only
      inadequate, but may be actually too  
      difficult to configure, simply because devices can not configure once
      installed. I am concerned that without a better answer, every
      building and plant will -- like most BlueTooth heads -- have PIN 
      0000!
      </t>

      <t>
      We need something more sophisticated: sophisticated enough to be
      simple.
      </t>


      <t><!-- XXX The nintendo 3D DS and a few other devices do streetpass: these are
    certainly smart objects. --></t>
    </section>

    <section title="Security Considerations">
      <t>This document does not propose any changes to existing or new
      systems, but rather details limitations of a current security model</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml" ?>
      <?rfc include="reference.I-D.phinney-roll-rpl-industrial-applicability.xml" ?>
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &RFC2629;

      <!-- A reference written by by an organization not a person. -->
    </references>

    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>
  </back>
</rfc>