Internet DRAFT - draft-sarikaya-core-secure-bootsolution

draft-sarikaya-core-secure-bootsolution






Core                                                         B. Sarikaya
Internet-Draft                                                Huawei USA
Intended status: Standards Track                       February 18, 2013
Expires: August 22, 2013


    Security Bootstrapping Solution for Resource-Constrained Devices
               draft-sarikaya-core-secure-bootsolution-00

Abstract

   We present a solution to initially configure the network of resource
   constrained nodes securely, a.k.a., security bootstrapping.  The
   solution is based on EAP-TLS authentication with the use of raw
   public keys as certificates.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 22, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Sarikaya                 Expires August 22, 2013                [Page 1]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Secure Bootstrapping Architecture  . . . . . . . . . . . . . .  3
   3.  Secure Bootstrapping Solution using Raw Public Keys  . . . . .  4
   4.  Transporting EAP Messages  . . . . . . . . . . . . . . . . . .  6
   5.  Future Work  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1.  Normative References  . . . . . . . . . . . . . . . . . .  9
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12




































Sarikaya                 Expires August 22, 2013                [Page 2]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


1.  Introduction

   Bootstrapping is any processing required before the network can
   operate.  The bootstrapping problem is not specific to any MAC or
   PHY.  This problem exists across any two nodes which have no previous
   knowledge of each other.  In particular, this problem is complicated
   when the nodes are resource-constrained and may not have an advanced
   user interface.

   Bootstrapping needs to be secure to make sure that the network
   operation is secure and hence secure bootstrapping ensures that only
   the authorized nodes can get access to the network.  Because of this
   secure bootstrapping needs to preceed IP address configuration.

   [I-D.jennings-core-transitive-trust-enrollment] defines a protocol
   that enables sensors to securely connect into a system that uses
   them.  The protocol which is being defined is based on the Device
   using HTTP or COAP [I-D.ietf-core-coap] to communicate with the
   Controller.  This seems to assume that the device is already
   configured with an IP address.  Such an assumption violates the
   assumption we have in this document on secure bootstrapping.

   Transport Layer Security (TLS) is commonly used protocol to secure
   web browsing, emailing, or other client-server applications.  In TLS,
   the client and the server present their certificates and authenticate
   each other.  Recently, raw public key extension is defined to be used
   as certificates [I-D.ietf-tls-oob-pubkey].  In this document we use
   the raw public keys in EAP-TLS.

   The document continues in Section 2 on bootstrapping architecture, in
   Section 3 on secure bootstrapping solution, in Section 4 on
   transporting EAP messages, in Section 5 on future work.


2.  Secure Bootstrapping Architecture

   Security bootstrapping architecture is structured in a hierarchy of
   nodes going from the least resource constraint to the most resource
   constraint.  At the top there is a root node.  The root node is
   called Coordinator or Trust Center in Zigbee and 6LowPAN Border
   Router (6LBR) in 6LoWPAN ND.

   At the next level there are interior Routers.  Routers are able to
   run a routing protocol between other routers and the root.  Routers
   are called 6LowPAN Routers (6BR) in 6LoWPAN ND.

   At the lowest level there are the nodes.  The nodes do not run a
   routing protocol.  They can connect to the nearest router over a



Sarikaya                 Expires August 22, 2013                [Page 3]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


   single radio link.  The nodes are called End Devices in Zigbee and
   hosts in 6LoWPAN ND.

   Routers first join the network as a node and go through security
   bootstrapping operations in order to create a Master Session Key
   (MSK).  Next, routers execute routing protocol, e.g.  [RFC6550]
   specific steps to create session keys with their neighbors and to
   establish upstream and downstream next hop parents.

   At each node hierarachy level described above, there are lower-layer
   and higher-layer protocols to bootstrap their ciphering keys, where
   the lower-layer refers to layers below IP layer including IEEE
   802.15.4 MAC layer and LoWPAN adaptation layer and the higher-layer
   refers to IP layer and the above.  In general, required bootstrapping
   procedures depend on the bootstrapping protocols to use.  Section
   Section 3 describes the bootstrapping procedures where EAP
   (Extensible Authentication Protocol) [RFC3748] and other protocols
   are used as the bootstrapping protocols.


3.  Secure Bootstrapping Solution using Raw Public Keys

   When a new resource-constrained device is deployed, it configures its
   global unique IPv6 address first.  This is done by 6LoWPAN Neighbor
   Discovery (6LoWPAN-ND)'s Router Solicitation/Router Advertisement
   message exchange [RFC6775].  The newly generated IPv6 address can not
   be used until the joining device is authenticated and securely joins
   the network.  After the authentication, the joining device receives
   the current group key of the network, so that the IPv6 registration
   and further communication can be protected by the link layer
   ciphering e.g. 802.15.4, then it can start using its global unique
   IPv6 address for communication.

   For authentication, Extensible Authentication Protocol (EAP) MUST be
   used.  EAP authentication framework is explained in [RFC5247].

   The EAP method EAP-TLS [RFC5216] can be used for the resource-
   constrained device authentication.  Instead of X.509 certificates,
   raw public key of the device MUST be used.  EAP-TLS is executed
   between the joining device and the AAA server which acts as the
   Authentication Server (AS).  After a successful authentication, the
   device and the AAA server establish a Master Session Key (MSK), and
   then the AAA server exports the MSK to the authenticator.  Upon
   receipt of the MSK, the authenticator distributes the group key to
   the joining device within the authentication success message.  The
   group key is encrypted by a Key Encryption Key derived from the MSK.

   The resource-constrained device initiates the EAP authentication



Sarikaya                 Expires August 22, 2013                [Page 4]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


   process by sending a message of initiation to the authenticator, i.e.
   the root node or 6LBR.  The root node requests the identity from the
   device by sending an EAP-Request/Identity packet.  The device replies
   with an EAP-Response/Identity containing the device's ID.  The
   identity information includes the device's network access ID (NAI).
   When the root node receives NAI of the device, it sends the identity
   information to the AS.

   The AS starts the EAP-TLS authentication process by sending a EAP-
   TLS/Start packet which is an EAP-Request packet with EAP-Type=EAP-TLS
   to the device.  The device generates a client random number and
   responds with an EAP-Response/TLS-Client-Hello message which contains
   the TLS version, a client random number, a set of cipher suites.
   Only one cipher suite MUST be offered in Client-Hello message with
   RC4-SHA1.  EAP-Response packet MUST have the EAP-Type value set at
   EAP-TLS Figure 1.

   The device MUST add an extension of type client certificate type and
   server certificate type defined in [I-D.ietf-tls-oob-pubkey] to
   Client-Hello message.  Both of these types MUST be set to
   RawPublicKey.

   Upon receipt of Client Hello, if the AS supports raw public key
   extension, it generates a server random number, a new session ID,
   server certificate type set to RawPublicKey and includes only the
   SubjectPublicKeyInfo part of the certificate with its raw public key,
   rather than the whole certificate in the Certificate message and then
   sends them to the device with an EAP-Request/TLS-Server-Hello
   message.  Server-Key-Exchange message contains a temporary key for
   the client to encrypt Client Key Exchange message.  For the device,
   the server adds certificate request message to ask for the device's
   RawPublicKey using client certificate type message.

   Device receives AS's RawPublicKey.  Device SHOULD verify the key
   using out of band mechanisms.  Device sends Client Certificate
   message containing the device's RawPublicKey.  With the client and
   server random number, the device generates a pre_master_secret, then
   sends it in Client-Key-Exchange field of EAP-Response/
   TLS-Client-Finished message to the AS encrypting pre_master_secret
   with the temporary key in Server-Key-Exchange message.  Device
   includes Change Cypher Spec message to indicate that all messages
   that follow Client Finished message will be encrypted.

   The AS derives the Master Session Key (MSK) and replies with EAP-
   Request/TLS-Server-Finished message.  In this message, the server
   includes Change Cypher Spec message to indicate that the server will
   beging encrypting messages with the keys negotiated.  The device also
   derives the MSK after receiving the Server Finished and acknowledges



Sarikaya                 Expires August 22, 2013                [Page 5]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


   with EAP-Response/EAP-TLS message.

   The AS then exports the MSK to the authenticator in RADIUS Access-
   Accept message, the authenticator subsequently sends the EAP-Success
   message to the device.  The AS MUST send the group key in this
   message and the EAP-TLS ends.


     Device             Authenticator       Authentication
      |                                          Server
      Device connects to      |                       |
      Network                 |                       |
      |<----TLS-Start---------|<---EAP-Request--------|
      |-TLS-ClientHello------>|----EAP-Response------>|
      |client certificate type|                       |
      |server certificate type|                       |
      |<-TLS Server Hello-----|<----EAP-Request-------|
      |                       |server certificate type|
      |                       | Server Certificate    |
      |                       |client certificate type|
      |                       | Certificate Request   |
      |                       | Server Key Exchange   |
      |                       | Server Hello Done     |
      |TLS-ClientCertificate->|----EAP-Response------>|
      |Client Key Exchange    |                       |
      |Change Cipher Spec     |                       |
      |Client Finished        |                       |
      |<TLS Change Cipher Spec|<----EAP-Request-------|
      |                       | Server Finished       |
      |TLS null-------------->|----EAP-Response------>|
      |      EAP-Success      |<----EAP-Success-------|
      |Authentication finished|                       |


                    Figure 1: Authentication Call Flow


4.  Transporting EAP Messages

   EAP can be transported between the device and the authenticator
   either in Layer 3 using PANA [RFC5191] or in Layer 2 using IEEE
   802.1X [802.1x].

   EAP is transported using RADIUS [RFC2865] between the authenticator
   and authentication server.

   When a device is not a direct neighbor of the authenticator, its
   parent node MUST act as relay.  Different EAP encapsulation protocols



Sarikaya                 Expires August 22, 2013                [Page 6]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


   have different mechanisms for the relay function, such as the PANA
   Relay Element (PRE).

   After the keys are established from a successful EAP method (such as
   EAP-TLS), the device runs neighbor discovery protocol to get an IPv6
   address assigned [RFC6775].  Data transfer can be secured using DTLS
   or IPSec.  Keys derived from EAP TLS are used in either generating
   DTLS ciphering keys after a successful DTLS handshake or IPSec ESP
   ciphering keys after a successful IKEv2 handshake.


5.  Future Work

   The nodes in a constrained network called devices have wide range of
   capabilities and are used in diverse number of applications.
   Different secure bootstrapping solutions may apply to different
   applications and different types of nodes.  In all cases, it is
   assumed in this document that the devices are IPv6 enabled.

   The solution described in Section 3 has the most stringent
   requirements on the devices and therefore is not suitable on less
   constrained nodes.  It seems that the devices used in smart metering
   may have enough resources to run the bootstrapping protocol and they
   do not suffer from power constraints compared with most other devices
   such as light switches.

   One possible optimization in Figure 1 applies to the case where the
   device does not have a RawPublicKey.  In this case the device sends
   only server_certificate_type set to RawPublicKey in Client-Hello
   message.  In response, AS sends its RawPublicKey in Server Hello
   message.  As a result the messages are much simpler than in Figure 1.

   Further optimizations to the EAP-TLS call flow in Figure 1 are TBD.

   Simpler devices such as light switches, environmental sensors, etc.
   may have much less resources, much less constrained IPv6 stack and
   they may not stay on for long periods of times required from the
   execution of the secure bootstrapping protocol.

   Identification of a set of applications with similar device
   capabilities is TBD.

   Modification of the protocol defined in Section 3 to define a secure
   bootstrapping protocol for each set is TBD.







Sarikaya                 Expires August 22, 2013                [Page 7]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


6.  Security Considerations

   When security bootstrapping resource constraint nodes is undertaken,
   several attacks are possible and security bootstrapping methods
   described in this document do not protect the nodes against such
   attacks.  These attacks are similar to the ones described in
   [RFC3971] and mainly stem from unsecured link layer.  Link layer must
   be secured on each node before the node can begin security
   bootstrapping.

   If a bootstrapping protocol does not rely on a pre-shared key for
   peer authentication, it must rely on an online or offline third-party
   (e.g., an authentication server, a key distribution center in
   Kerberos, a certification authority in PKI, a private key generator
   in ID-based cryptography and so on) to prevent man-in-the-middle
   attacks during peer authentication.  Depending on use cases, a
   resource-constrained device may not always have access to an online
   third-party for peer authentication.

   Depending on use cases, a bootstrapping protocol may deal with
   authorization separately from authentication in terms of timing and
   signaling path.  For example, two resource-constrained devices A and
   B may perform mutual authentication using authentication credentials
   provided by an offline third-party X whereas resource-constrained
   device A obtains authorization for running a particular application
   with resource-constrained device B from an online third-party Y
   before or after the authentication.  In some use cases,
   authentication and authorization are tightly coupled, e.g.,
   successful authentication also means successful authorization.  A
   bootstrapping protocol supports various types of authentication and
   authorization or different bootstrapping protocols may be used for
   different types of authentication and authorization.

   If authorization information includes cryptographic keys, a special
   care must be taken for dealing with the keys, e.g., guidelines for
   AAA-based key management are described in [RFC4962].  A
   recommissioning use case may require revocation and re-installation
   of authentication credentials (i.e., a certificate or a shared secret
   and identity information, etc.) to a large number of resource-
   constrained devices that are already deployed.  Re-installation of
   authentication credentials must be as secure as the initial
   installation regardless of whether the re-installation is done
   manually or automatically.

   If resource-constrained devices use a multicast group key for peer
   authentication or message authentication or encryption, the group key
   must be securely distributed to the current members of the group for
   both initial key distribution and key update.  Protocols designed for



Sarikaya                 Expires August 22, 2013                [Page 8]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


   group key management such as GSAKMP [RFC4535], GDOI [RFC3547] and
   MIKEY [RFC3830] may be used for group key distribution.
   Alternatively, key wrap attributes for securely encapsulating group
   key may be defined in network access authentication protocols such as
   PANA [RFC5191] and EAP-TTLSv0 [RFC5281].  Those protocols use an end-
   to-end, point-to-point communication channel with a pair-wise
   security association between a key distribution center and each key
   recipient.  Further considerations may be needed for more efficient
   group key management to support a large number of resource-
   constrained devices.


7.  IANA Considerations

   This memo includes no request to IANA.


8.  Contributors

   TBD.


9.  Acknowledgements

   TBD.


10.  References

10.1.  Normative References

   [802.15.4]
              IEEE Std 802.15.4-2006, "Wireless Medium Access Control
              (MAC) and Physical Layer (PHY) Specifications for Low Rate
              Wireless Personal Area Networks (WPANs)", September 2006.

   [I-D.ietf-tls-oob-pubkey]
              Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
              T. Kivinen, "Out-of-Band Public Key Validation for
              Transport Layer Security (TLS)",
              draft-ietf-tls-oob-pubkey-07 (work in progress),
              February 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",



Sarikaya                 Expires August 22, 2013                [Page 9]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


              RFC 2865, June 2000.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, August 2007.

   [RFC5191]  Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
              Yegin, "Protocol for Carrying Authentication for Network
              Access (PANA)", RFC 5191, May 2008.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, March 2008.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

10.2.  Informative References

   [802.1x]   IEEE Std 802.1X-2010, "IEEE 802.1X Port-Based Network
              Access Control", February 2010.

   [C1222]    American National Standard, "Protocol Specification For
              Interfacing to Data Communication Networks", ANSI C12.22-
              2008, 2008.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-13 (work in progress), December 2012.

   [I-D.jennings-core-transitive-trust-enrollment]
              Jennings, C., "Transitive Trust Enrollment for Constrained
              Devices",
              draft-jennings-core-transitive-trust-enrollment-01 (work
              in progress), October 2012.

   [NISTIR7628VOL1]
              The Smart Grid Interoperability Panel -  Cyber Security



Sarikaya                 Expires August 22, 2013               [Page 10]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


              Working Group, "Guidelines for Smart Grid Cyber Security:
              Vol. 1,  Smart Grid Cyber Security Strategy, Architecture,
              and High-Level Requirements", NISTIR 7628, vol. 1, 2010.

   [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
              Group Domain of Interpretation", RFC 3547, July 2003.

   [RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
              for Transport Layer Security (TLS)", RFC 4279,
              December 2005.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC4535]  Harney, H., Meth, U., Colegrove, A., and G. Gross,
              "GSAKMP: Group Secure Association Key Management
              Protocol", RFC 4535, June 2006.

   [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
              Authorization, and Accounting (AAA) Key Management",
              BCP 132, RFC 4962, July 2007.

   [RFC5204]  Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", RFC 5204, April 2008.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, August 2008.

   [RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
              Protocol Tunneled Transport Layer Security Authenticated
              Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.

   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
              "Specification for the Derivation of Root Keys from an



Sarikaya                 Expires August 22, 2013               [Page 11]

Internet-Draft   draft-sarikaya-core-secure-bootsolution   February 2013


              Extended Master Session Key (EMSK)", RFC 5295,
              August 2008.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [RFC6550]  Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
              Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
              Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
              Lossy Networks", RFC 6550, March 2012.

   [RFC6775]  Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
              "Neighbor Discovery Optimization for IPv6 over Low-Power
              Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
              November 2012.

   [ROMER04]  Romer, K. and F. Mattern, "The design space of wireless
              sensor networks", IEEE Wireless Communications, vol. 11,
              no. 6, pp. 54-61, December 2004.

   [SE2.0]    ZigBee Alliance, "Smart Energy Profile 2.0 Technical
              Requirements Document", April 2010.


Author's Address

   Behcet Sarikaya
   Huawei USA
   5340 Legacy Dr.
   Plano, TX  75024

   Email: sarikaya@ieee.org


















Sarikaya                 Expires August 22, 2013               [Page 12]