Internet DRAFT - draft-garcia-core-app-layer-sec-with-dtls-record

draft-garcia-core-app-layer-sec-with-dtls-record







CoRE Working Group                                             D. Garcia
Internet-Draft                                                 S. Matheu
Intended status: Experimental                                   R. Marin
Expires: June 9, 2017                               University of Murcia
                                                        December 6, 2016


   Application Layer Security for CoAP using the (D)TLS Record Layer
          draft-garcia-core-app-layer-sec-with-dtls-record-00

Abstract

   This document briefly describes an idea to provide Application-Layer
   Security for CoAP using (D)TLS Record Layer, assuming it is operative
   in two CoAP endpoints.

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 June 9, 2017.

Copyright Notice

   Copyright (c) 2016 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.




Garcia, et al.            Expires June 9, 2017                  [Page 1]

Internet-DraftApplication Layer Security for CoAP using (D)December 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Application Layer Security for CoAP with (D)TLS Record
       Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  CoAP Fields to protect  . . . . . . . . . . . . . . . . .   3
   3.  Processing a CoAP message with the (D)TLS Record  . . . . . .   3
   4.  Bootstrapping the (D)TLS Record Layer for Application
       Security  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Secure communications in constrained scenarios is subject of current
   interest since the restrictions in those kinds of networks motivates
   rethinking the solutions that up to now have been used in networks
   that do not suffer from very stringent requirements.  (D)TLS
   [RFC6347][RFC5246] is a standard proposed to secure the
   communications of CoAP and suitable for end-to-end communications
   unless a CoAP proxy participates in the communication.  To overcome
   this problem [I-D.ietf-core-object-security] propose Object Security
   for CoAP (OSCOAP) to allow end-to-end security between two CoAP
   endpoints in case of a CoAP proxy intermediating between them.

   In this document we explore that possibility of providing CoAP
   security at application layer, assuming a (D)TLS Record Layer is
   operative (i.e. have the required keys) in both CoAP endpoints.  One
   possibility to "activate" the (D)TLS Record Layer is running (D)TLS
   handshake over CoAP, as mentioned in CoDTLS
   [I-D.schmertmann-dice-codtls].  Other (more challenging) options are
   discussed in [I-D.bhattacharyya-dice-less-on-coap]

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Application Layer Security for CoAP with (D)TLS Record Protocol

   To achieve application layer security using the (D)TLS Record, we
   assume the (D)TLS [RFC6347] [RFC5246] Record layer is already
   activated, using a protocol such as CoDTLS
   [I-D.schmertmann-dice-codtls].  Once we have the (D)TLS Record Layer




Garcia, et al.            Expires June 9, 2017                  [Page 2]

Internet-DraftApplication Layer Security for CoAP using (D)December 2016


   active, the next step is to define how the CoAP message will be
   secured end-to-end using the (D)TLS Record Layer.

   The entire CoAP message generated by a CoAP sender will need to
   arrive to the CoAP recipient, achieving integrity and confidentiality
   for certain parts of the CoAP message (specific CoAP options and
   payload) excluding the options CoAP intermediaries (proxies) will
   need to understand to process the CoAP message correctly.  The CoAP
   header would need to arrive maintaining the semantics and version of
   the protocol.

2.1.  CoAP Fields to protect

   Here we discuss how the CoAP message is going to be processed to
   achieve application layer security.  How each part of the CoAP
   message (Header, Options and Payload) is treated and which options
   are protected an which ones are left unprotected using the (D)TLS
   Record Layer.  Following the procedure specified in OSCOAP
   [I-D.ietf-core-object-security], we protect all options that are
   intended to be read by the CoAP recipient.

   o  CoAP Header: version and code are protected.

   o  CoAP Options: All the options that can be modified by the proxy
      are left unprotected.  All options that are intended for the the
      CoAP recipient are protected.  There might be the case there an
      option is both left unprotected for the proxy to process and is
      also intended for the CoAP recipient to see.

   o  CoAP Payload: The payload is always protected.

   Similarly to OSCON [I-D.ietf-core-object-security], it would be
   possible to only encrypt the payload of the original CoAP message.

3.  Processing a CoAP message with the (D)TLS Record

   In this section we analyze how the CoAP message is processed and
   protected using the (D)TLS Record.  In Figure 1 we can see how from
   the Original CoAP Header we obtain the fields that have to be
   protected (Version and Code) in 2 bytes.  We get the Version and the
   Code.  We will have a padding of 6 bits, then the version and code
   all in 2 bytes.









Garcia, et al.            Expires June 9, 2017                  [Page 3]

Internet-DraftApplication Layer Security for CoAP using (D)December 2016


                                                   3
               0 ..................................1
   Original    +-----+---+-----+------+------------+
   CoAP        | Ver | T | TKL | Code | Message ID |
   Header      +-----+---+-----+------+------------+

                                    1 1 1 1 1 1
                0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   Protected    +-----------+---+-------------+
   CoAP Header  |0 0 0 0 0 0|Ver|    Code     |
   (P. Header)  +-----------+---+-------------+

                     Figure 1: Protected Header Fields

   This "denatured" CoAP header is concatenated with the CoAP options to
   be protected and the Payload (if any) of the Original CoAP message
   (see Figure 2).  This array of bytes is sent to the (D)TLS Record
   Layer to be processed.  The resulting information is a protected
   array of bytes with a (D)TLS Record Header which will process it
   generating the (D)TLS Record (adding the (D)TLS Record Header).
   After that, we add the (D)TLS record to the payload of the message to
   be sent, that will contain the original CoAP Header and only the
   options available for the proxies.  The Protected CoAP message is
   formed by the Original CoAP Message Header, the Options that are not
   considered to be protected with this mechanism, then the marker 0xFF
   and finally the Payload that contains the (D)TLS Record.

























Garcia, et al.            Expires June 9, 2017                  [Page 4]

Internet-DraftApplication Layer Security for CoAP using (D)December 2016


   Original CoAP Message

          +-----------------------------------------+
          |Header| Options |FF|      Payload        |
          +-----------------------------------------+
                           |
    CoAP Content           |
     to protect            v

          +--------------------+-----------------+
          | P.   |Options to be|  |              |
          |Header| Protected   |FF|  Payload     |
          +--------------------------------------+
                           |
                           v
                   ------------------------
                  (   (D)TLS Record Layer  )
                   ------------------------
                           |
                           v
     DTLS Record
          +-------------+--------------------------+
          |(D)TLS Record|    CoAP Content*         |
          |   Header    |     to protect           |
          +-------------+--------------------------+
                           |
                           |
      Protected            v
      CoAP Message

          +--------+-----------+----+-----------------+
          |        |Unprotected|    |                 |
          | Header |  Options  | FF |  (D)TLS Record  |
          +--------+-----------+----+-----------------+

   * (Ciphered and Integrity protected)

                     Figure 2: Processing CoAP message

   Upon reception, the CoAP recipient will get the CoAP Payload of the
   Protected Message and send it to the (D)TLS Record Layer to obtain
   the Protected Header and the list of options within the (D)TLS
   Record.  With this information, once it is verified correctly, the
   CoAP recipient constructs the Original CoAP Message.







Garcia, et al.            Expires June 9, 2017                  [Page 5]

Internet-DraftApplication Layer Security for CoAP using (D)December 2016


4.  Bootstrapping the (D)TLS Record Layer for Application Security

   To enable this solution, the (D)TLS Record Layer in both CoAP
   endpoints must have a connection to process this information.  One
   alternative is running (D)TLS over CoAP as specified in
   [I-D.schmertmann-dice-codtls].  However, we consider that it would be
   possible to define we define a separation between the (D)TLS
   Handshake and the (D)TLS Record Layer with an interface to be
   standarized.  The (D)TLS Handshake is used to negotiate the
   parameters to establish a Security Association (SA) in (D)TLS Record
   Layer.  With this interface, we argue that this SA can be set by the
   (D)TLS Handshake or any other Key Management Protocol (KMP), as we
   show in Figure 3.  This would be similar to the separation in the
   IPsec architecture [RFC4301], where IKEv2 [RFC7296]  is just one of
   the possible Key Management Protocol to establish IPsec SAs.  In
   fact, IPsec defines a standard API (PFKEY_v2 [RFC2367])) for this
   purpose.

   An example of this separation has been proposed in
   [I-D.bhattacharyya-dice-less-on-coap].  Another way to benefit from
   this separation could be that one of the CoAP endpoint has a token
   (e.g.  Kerberos ticket, and ACE token, etc...), with the key material
   and information (cryptographic keys, algorithms) to start the (D)TLS
   Record Layer, just presenting the ticket, without the need of running
   the (D)TLS handshake.

   +------------------+-------+-------+--------+
   |                  |       |       |        |
   | (D)TLS Handshake | KMP 1 | KMP 2 | KMP i  |
   |                  |       |       |        |
   +------------------+-------+-------+--------+
   |                                           |
   |       (D)TLS Record Layer Interface       |
   |                                           |
   +-------------------------------------------+
   |                                           |
   |                                           |
   |           (D)TLS Record Layer             |
   |                                           |
   |                                           |
   +-------------------------------------------+

                  Figure 3: (D)TLS Record Layer Interface








Garcia, et al.            Expires June 9, 2017                  [Page 6]

Internet-DraftApplication Layer Security for CoAP using (D)December 2016


5.  Acknowledgments

   This work has been possible partially by the ARMOUR project
   (FP7-ARMOUR-644852 EU Project) and the Spanish National Project CICYT
   EDISON (TIN2014-52099-R) granted by the Ministry of Economy and
   Competitiveness of Spain (including ERDF support).

6.  Normative References

   [I-D.bhattacharyya-dice-less-on-coap]
              Bhattacharyya, A., Bandyopadhyay, S., Ukil, A., Bose, T.,
              and A. Pal, "Lightweight Establishment of Secure Session
              (LESS) on CoAP", draft-bhattacharyya-dice-less-on-coap-00
              (work in progress), April 2015.

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security of CoAP (OSCOAP)", draft-ietf-core-
              object-security-00 (work in progress), October 2016.

   [I-D.schmertmann-dice-codtls]
              Schmertmann, L., Hartke, K., and C. Bormann, "CoDTLS: DTLS
              handshakes over CoAP", draft-schmertmann-dice-codtls-01
              (work in progress), August 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2367]  McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
              Management API, Version 2", RFC 2367,
              DOI 10.17487/RFC2367, July 1998,
              <http://www.rfc-editor.org/info/rfc2367>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <http://www.rfc-editor.org/info/rfc4301>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.




Garcia, et al.            Expires June 9, 2017                  [Page 7]

Internet-DraftApplication Layer Security for CoAP using (D)December 2016


   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <http://www.rfc-editor.org/info/rfc7296>.

Authors' Addresses

   Dan Garcia Carrillo
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 78 82
   Email: dan.garcia@um.es


   Sara Nieves Matheu Garcia
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 78 82
   Email: saranieves.matheu@um.es


   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 85 01
   Email: rafa@um.es











Garcia, et al.            Expires June 9, 2017                  [Page 8]