[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 draft-ietf-core-object-security

ACE Working Group                                            G. Selander
Internet-Draft                                               J. Mattsson
Intended Status: Standards Track                                Ericsson
Expires: September 10, 2015                                     L. Seitz
                                                        SICS Swedish ICT

                                                           March 9, 2015


                        Object Security for CoAP
                 draft-selander-ace-object-security-01
Abstract

   This memo presents a scheme for data object security applicable to
   protection of payload of generic message formats as well as request
   and response messages of the Constrained Application Protocol (CoAP).

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   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".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

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



Selander, et al.       Expires September 10, 2015               [Page 1]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   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.



Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Background  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3. End-to-end Security in Presence of Intermediary Nodes . . . . .  6
   4. Secure Message  . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1 Secure Message format  . . . . . . . . . . . . . . . . . . .  8
       4.1.1 Secure Message Header  . . . . . . . . . . . . . . . . .  8
       4.1.2 Secure Message Body  . . . . . . . . . . . . . . . . . .  9
         4.1.2.1 Secure Signed Message Body . . . . . . . . . . . . .  9
         4.1.2.2 Secure Encrypted Message Body  . . . . . . . . . . .  9
       4.1.3 Secure Message Tag . . . . . . . . . . . . . . . . . . .  9
   5. Message Protection  . . . . . . . . . . . . . . . . . . . . . .  9
     5.1 CoAP Message Protection  . . . . . . . . . . . . . . . . . . 10
       5.1.1 The Sig Option . . . . . . . . . . . . . . . . . . . . . 10
         5.1.1.1 Option Structure . . . . . . . . . . . . . . . . . . 10
         5.1.1.2 Integrity Protection and Verification  . . . . . . . 11
         5.1.1.3 SSM Body . . . . . . . . . . . . . . . . . . . . . . 11
       5.1.2 The Enc Option . . . . . . . . . . . . . . . . . . . . . 12
         5.1.2.1 Option Structure . . . . . . . . . . . . . . . . . . 12
         5.1.2.2 Encryption and Decryption  . . . . . . . . . . . . . 12
         5.1.2.3 SEM Body . . . . . . . . . . . . . . . . . . . . . . 13
         5.1.2.4 CoAP Message with Enc Option . . . . . . . . . . . . 13
       5.1.3 SM Tag . . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.2 Application Layer Protection . . . . . . . . . . . . . . . . 14
     5.3 Replay Protection and Freshness  . . . . . . . . . . . . . . 15
       5.3.1 Replay Protection  . . . . . . . . . . . . . . . . . . . 15
       5.3.2 Freshness  . . . . . . . . . . . . . . . . . . . . . . . 15
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 16
   7. Privacy Considerations  . . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 19
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 19
     10.2  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A. Which CoAP Header Fields and Options to Protect  . . . 20
     A.1 CoAP Header Fields . . . . . . . . . . . . . . . . . . . . . 20
     A.2 CoAP Options . . . . . . . . . . . . . . . . . . . . . . . . 20
       A.2.1 Integrity Protection . . . . . . . . . . . . . . . . . . 21



Selander, et al.       Expires September 10, 2015               [Page 2]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


       A.2.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . 22
       A.2.3 Summary  . . . . . . . . . . . . . . . . . . . . . . . . 22
   Appendix B.  JOSE Objects as Secure Messages . . . . . . . . . . . 23
     B.1  JWS as Secure Signed Message  . . . . . . . . . . . . . . . 23
     B.2  JWE as Secure Encrypted Message . . . . . . . . . . . . . . 23
     B.3 "seq" (Sequence Number) Header Parameter . . . . . . . . . . 24
     B.4 "mod" (Mode) Header Parameter  . . . . . . . . . . . . . . . 24
     B.4  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   Appendix C.  Compact Secure Message  . . . . . . . . . . . . . . . 25
     C.1 CSM Format . . . . . . . . . . . . . . . . . . . . . . . . . 25
     C.2 Comparison of Secure Message sizes . . . . . . . . . . . . . 27
   Appendix D.  Examples  . . . . . . . . . . . . . . . . . . . . . . 29
     D.1 CoAP Message Protection  . . . . . . . . . . . . . . . . . . 29
       D.1.1 Integrity protection of CoAP Message . . . . . . . . . . 29
       D.1.2 Encryption of CoAP Message . . . . . . . . . . . . . . . 30
     D.2 Application Layer Protection . . . . . . . . . . . . . . . . 32
       D.2.1 Proxy Caching  . . . . . . . . . . . . . . . . . . . . . 32
       D.2.2 Publish-Subscribe  . . . . . . . . . . . . . . . . . . . 33
       D.2.3 Transporting Authorization Information . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35































Selander, et al.       Expires September 10, 2015               [Page 3]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


1.  Introduction

   The Constrained Application Protocol CoAP [RFC7252] was designed with
   a constrained RESTful environment in mind.  CoAP references DTLS
   [RFC6347] for securing the message exchanges.  Two commonly used
   features of CoAP are store-and-forward and publish-subscribe
   exchanges, which are problematic to secure with DTLS and transport
   layer security.  As DTLS offers hop-by-hop security, in case of
   store-and-forward exchanges it necessitates a trusted intermediary.
   On the other hand, securing publish-subscribe CoAP exchanges with
   DTLS requires the use of the keep-alive mechanism which incurs
   additional overhead and actually takes away most of the benefits of
   asynchronous communication.

   The pervasive monitoring debate has illustrated the need to protect
   data also from trustworthy intermediary nodes as they can be
   compromised.  The community has reacted strongly to the revelations,
   and new solutions must consider this attack [RFC7258] and include
   encryption by default.

   This memo presents an object security approach for secure messaging
   in constrained environments that may be used as a complement to DTLS
   for store-and-forward and publish-subscribe CoAP exchanges.  Note
   that the solution sketched in this memo can be combined with DTLS
   thus enabling, for example, end-to-end security of CoAP payload in
   combination with hop-by-hop protection of the entire CoAP messages
   during transport between end-point and intermediary node.

   This version of the draft focuses on symmetric key based algorithms.
   Public key based algorithms will be addressed in the next version.

1.1  Terminology

   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 [RFC2119].  These
   words may also appear in this document in lowercase, absent their
   normative meanings.

   Certain security-related terms are to be understood in the sense
   defined in RFC 4949 [RFC4949].  These terms include, but are not
   limited to, "authentication", "authorization", "confidentiality",
   "(data) integrity", "message authentication code", "signature", and
   "verify".

   RESTful terms, such as "resource" or "representation", are to be
   understood as used in HTTP [RFC7231] and CoAP.




Selander, et al.       Expires September 10, 2015               [Page 4]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   Terminology for constrained environments, such as "constrained
   device", "constrained-node network", is defined in [RFC7228].

   Client, Resource Server, and Authorization Server are defined in [I-
   D.seitz-ace-problem-description].  The terms "server" and "Resource
   Server" are used interchangeably.

   JSON Web Signature (JWS), JOSE Header, JWS Payload, and JWS Signature
   are defined in [I-D.ietf-jose-json-web-signature].

   JSON Web Encryption (JWE), JWE AAD, JWE Ciphertext, and JWE
   Authentication Tag are defined in [I-D.ietf-jose-json-web-
   encryption].

   Secure Message (SM), Secure Signed Message (SSM), and Secure
   Encrypted Message (SEM) are message formats defined in this memo.
   The Compact Secure Message (CSM) format is defined in Appendix C.
   The Sig and Enc options are CoAP options defined in this memo.

   Excluded Authenticated Data (EAD) is defined in this memo (see
   Sections 4.1.2).  Transaction Identifier (TID) is defined in this
   memo (see Section 4.1.1).

2. Background

   The background for this work is provided by the use cases and problem
   description in [I-D.ietf-ace-usecases] and [I-D.seitz-ace-problem-
   description].  The overall objective is that (a) only authorized
   requests are granted, and (b) messages between client and server are
   protected (according to requirements of the particular use case).
   The focus of this memo is on end-to-end security in constrained
   environments in the presence of intermediary nodes, which corresponds
   to point (b).

   For constrained-node networks there may be several reasons for
   messages to be cached or stored in one node and later forwarded.  For
   example, connectivity between the nodes may be intermittent, or some
   node may be sleeping at the time when the message should have been
   forwarded (see e.g. [I-D.ietf-ace-usecases] sections 2.1.1,  and
   2.5.1).  Also, the architectural model or protocol applied may
   require an intermediary node which breaks security on transport layer
   (see e.g. [I-D.ietf-ace-usecases] sections 2.1.1, and 2.5.2).
   Examples of intermediary nodes include forward proxies, reverse
   proxies, pub-sub brokers, HTTP-CoAP cross-proxies, and SMS servers.

   On a high level, end-to-end security in this setting encompasses:

      1. Protection against eavesdropping and manipulation of resource



Selander, et al.       Expires September 10, 2015               [Page 5]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


         representations in intermediary nodes;

      2. Protection against message replay;

      3. Protection of authorization information ("access tokens") in
         transport from an Authorization Server to a Resource Server via
         a Client, or other intermediary nodes which could gain from
         changing the information;

      4. Allowing a client to verify that a response comes from a
         certain server and is the response to a particular request;

      5. Protection of the RESTful method used by the client, or the
         response code used by the server. For example if a malicious
         proxy replaces the client requested GET with a DELETE this must
         be detected by the server;

      6. Protection against eavesdropping of meta-data of the request or
         response, including CoAP options such as for example Uri-Path
         and Uri-Query, which may reveal some information on what is
         requested.

   From the listed examples, there are two main categories of security
   requirements and corresponding solutions.  The first category deals
   essentially with application layer protection, i.e. protecting the
   payload of the RESTful protocol (1-3).  The second category deals
   with protecting an entire CoAP message, targeting also CoAP options
   and header fields (4-6).  The next section formulates security
   requirements for the two categories, which are denoted Mode:APPL and
   Mode:COAP, respectively.

3. End-to-end Security in Presence of Intermediary Nodes

   For high-level security requirements related to resource access, see
   section 4.6 of [I-D.seitz-ace-problem-description].  This section
   defines the specific requirements that address the two categories of
   examples identified in the previous section, taking into account
   potential intermediary nodes.

   In the case of application layer protection (Mode:APPL), the end-to-
   end security requirements apply to the RESTful protocol payload data,
   such as Resource Representations:

      a. The payload shall be integrity protected and should be
         encrypted end-to-end from sender to receiver.

      b. It shall be possible for an intended receiver to detect if it
         has received this message previously, i.e. replay protection.



Selander, et al.       Expires September 10, 2015               [Page 6]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   In this case there may be multiple receivers of a given message, for
   example in the case of a proxy that is caching responses used to
   serve multiple clients, or in a publish-subscribe setting with
   multiple subscribers to a given publication.

   In the case of protecting specific Client-Server CoAP message
   exchanges (Mode:COAP), potentially passing via intermediary nodes,
   there are additional end-to-end security requirements:

      c. The CoAP options which are not intended to be changed by an
         intermediary node shall be integrity protected between Client
         and Server.

      d. The CoAP options which are not intended to be read by an
         intermediary node shall be encrypted between Client and Server.

      e. The CoAP header field "Code" shall be integrity protected
         between Client and Server.

      f. A Client shall be able to verify that a message is the response
         to a particular request the Client made.

   The requirements listed above can be met by encryption, integrity
   protection and replay protection.  What differs is the actual data
   that is protected, i.e. application layer data or CoAP message data.
   This memo specifies a common "Secure Message" format that can be used
   to wrap either payload only or also additional selected CoAP message
   fields, and be sent as part of the message.


4. Secure Message

   There exist already standardized and draft content formats for
   cryptographically protected data such as CMS [RFC5652], JWS, JWE, and
   COSE [I-D.bormann-jose-cose].  None of the listed formats provide
   support for replay protection, but it is noted in section 10.10 of
   [I-D.ietf-jose-json-web-signature]) that one way to thwart replay
   attacks is to include a unique transaction identifier and have the
   recipient verify that the message has not been previously received or
   acted upon.

   The term Secure Message (SM) format refers to a content format for
   cryptographically protected data which includes a unique transaction
   identifier and allows customization to support different variants of
   format and message processing (Modes).

   This memo uses JOSE content formats as a model to specify format and
   processing of messages.  The terms Secure Signed Message (SSM) format



Selander, et al.       Expires September 10, 2015               [Page 7]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   and Secure Encrypted Message (SEM) format to refer to Secure Message
   formats supporting integrity protection only and additional
   encryption, analogous to JWS and JWE, respectively.  Appendix B shows
   how JWS and JWE could be extended to become Secure Message formats.

   It should be noted that the current JOSE objects are undesirably
   large for very constrained devices.  In their current size they can
   lead to packet fragmentation in constrained-node networks due to
   limited frame sizes, and to problems with limited storage capacity on
   constrained devices due to limited RAM.  COSE renders more compact
   objects, and further optimizations are considered.  See Appendix C
   for a discussion of minimum message expansion and message format
   overhead.

4.1 Secure Message format

   A Secure Message (SM) SHALL consist of Header, Body and Tag.

4.1.1 Secure Message Header

   The following parameters SHALL be included in the SM Header:

      o Algorithm.  This parameter allows the receiver to identify the
        cryptographic algorithm(s) used to protect the Secure Message.
        In case of SSM it has the same syntax as the JOSE Header
        Parameter "alg" defined in Section 4.1.1 of [I-D.ietf-jose-json-
        web-signature].  In case of SEM, it has the same syntax as the
        JOSE Header Parameter "enc" defined in Section 4.1.2 of [I-
        D.ietf-jose-json-web-encryption]. (Assuming direct key
        agreement, corresponding to the JWE "alg" = "dir" setting.)

      o Key Identifier.  This parameter allows the receiver to uniquely
        identify the sender and the security context/key(s) used with
        the Algorithm.  It has the same syntax as the JOSE Header
        Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose-json-
        web-signature].

      o Sequence Number.  The Sequence Number parameter enumerates the
        Secure Messages protected using the key(s) identified by the Key
        Identifier, and is used for replay protection and uniqueness of
        nonce.  The start sequence number SHALL be 0.  For a given key,
        any Sequence Number MUST NOT be used more than once.

      o Mode.  The Mode parameter defines application specific message
        format, content and processing.  This parameter provides means
        for customization of the Secure Message format, in particular to
        distinguish between Secure Messages containing application layer
        data only or CoAP message data.



Selander, et al.       Expires September 10, 2015               [Page 8]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   The ordered sequence (Sequence Number, Key Identifier) is called
   Transaction Identifier (TID), and SHALL be unique for each SM.

4.1.2 Secure Message Body

   Analogously to JWS and JWE, the SM Body contains what is being
   protected.  The SM Body is different for SSM and SEM.

   In order to obtain a compact representation, certain data is
   integrity protected but excluded from the Secure Message.  Such data
   is referred to as Excluded Authenticated Data (EAD).  To further
   reduce message size, the unencrypted part of the SM Body may be
   "detached" from the Secure Message, see sections 4.1.2.1 and 4.1.2.2.

   The assumption behind excluding integrity protected data from the SM,
   or detaching integrity protected but not encrypted parts of the SM
   during transport, is that the data in question is known to the
   receiver, e.g. because it is exchanged beforehand or because it is
   transported as part of the CoAP message carrying the Secure Message.


4.1.2.1 Secure Signed Message Body

   For SSM, the Body consists of the payload data which is integrity
   protected, analogously to the JWS Payload.  Detached Content is
   defined to mean that the Body is removed from the Secure Message,
   analogously to Appendix F of [I-D.ietf-jose-json-web-signature].
   Hence a SSM with Detached Content consists of Header and Tag.

4.1.2.2 Secure Encrypted Message Body

   Analogously to JWE, the terms Plaintext, Ciphertext and Additional
   Authenticated Data (AAD) are used for the SEM.  The Body of a SEM
   consists of Ciphertext and Additional Authenticated Data (AAD).  For
   SEM Detached Content is defined to mean that the AAD is removed from
   the Secure Message.  Hence a SEM with Detached Content consists of
   the Header, Ciphertext and Tag.

4.1.3 Secure Message Tag

   The SM Tag consists of the Signature / Authentication Tag value as
   defined by the Algorithm, calculated over the SM Header, SM Body and
   EAD (if present).  The content of EAD depends on the Mode, see 5.1.3
   and 5.2


5. Message Protection




Selander, et al.       Expires September 10, 2015               [Page 9]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   This section describes what is protected in a Secure Message and how
   it depends on the defined Modes ("CoAP Message Protection" and
   "Application Layer Protection").  Both formats SSM and SEM defined in
   the previous section are applicable to both Modes.  For examples, see
   Appendix D.

   For any Secure Message Mode, the SEM format SHALL be used by default.

   The SM Header is defined in 4.1.1, indicates the Mode, but is in all
   other respects handled similarly in both Modes.  This section also
   describes the differences in SM Body and SM Tag.

5.1 CoAP Message Protection

   Referring to examples 4-6 in Section 2 and requirements a-f in
   Section 3, this section presents how to protect individual CoAP
   messages including options and header fields, as well as request-
   response message exchanges, using the Secure Message format.  This is
   called Secure Message Mode:COAP.  An endpoint receiving a CoAP
   request containing a Secure Message with Mode:COAP MUST respond with
   a CoAP message containing a Secure Message with Mode:COAP.

   Since slightly different message formats are used for integrity
   protection only (SSM), and additional encryption (SEM), these cases
   are treated separately.  Two new CoAP security options are
   introduced: the Enc option and the Sig option.  A CoAP message SHALL
   NOT include both Enc and Sig options.

5.1.1 The Sig Option

   In order to integrity protect CoAP message exchanges, a new CoAP
   option is introduced: the Sig option, containing a SSM Mode:COAP
   object.   Endpoints supporting this scheme MUST check for the
   presence of a Sig option, and verify the SSM as described in Section
   5.1.1.2 before accepting a message as valid.

5.1.1.1 Option Structure

   The Sig option indicates that certain CoAP Header Fields, Options,
   and Payload (if present) are integrity and replay protected using a
   Secure Signed Message (SSM).  The Sig option SHALL contain a SSM with
   Detached Content (see Section 4.1.2.1).

   This option is critical, safe to forward, it is not part of a cache
   key, and it is not repeatable.  Table 1 illustrates the structure of
   this option.





Selander, et al.       Expires September 10, 2015              [Page 10]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   +-----+---+---+---+---+---------+--------+-----------+
   | No. | C | U | N | R | Name    | Format | Length *) |
   +-----+---+---+---+---+---------+--------+-----------+
   | TBD | x |   | x |   | Sig     | opaque |  12-TBD   |
   +-----+---+---+---+---+---------+--------+-----------+

         C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

                       Table 1: The Sig Option


    *) Length is essentially Length(SSM Header) + Length(SSM Tag).  The
   minimum length is estimated in Appendix C.  The maximum length
   depends on actual message format selected and is TBD.


5.1.1.2 Integrity Protection and Verification

   A CoAP endpoint composing a message with the Sig option SHALL process
   the SSM and produce the SSM Tag, as defined in 5.1.1.3 and 5.1.3,
   analogously to the specification for producing a JWS object as
   described in Section 5.1 of [I-D.ietf-jose-json-web-signature] (cf.
   Appendix B).  In addition, the sending endpoint SHALL process the
   Sequence Number as described in Section 5.3.

   A CoAP endpoint receiving a message containing the Sig option SHALL
   first recreate the SSM Body as described in Section 5.1.1.3, and then
   verify the SSM Tag as described in Section 5.1.3, analogously to the
   specification for verifying a JWS object as described in Section 5.2
   of [I-D.ietf-jose-json-web-signature] (cf. Appendix B).  In addition,
   the receiving endpoint SHALL process the Sequence Number as described
   in Section 5.3.

   NOTE: The explicit steps of the protection and verification procedure
   will be included in a future version of this draft.

5.1.1.3 SSM Body

   The SSM Body SHALL consist of the following data, in this order:

      o the 8-bit CoAP header field Code;

      o all CoAP options present which are marked as IP in Table 3
        (Appendix A), in the order as given by the option number (each
        Option with Option Header including delta to previous IP-marked
        Option which is present); and

      o the CoAP Payload (if any).



Selander, et al.       Expires September 10, 2015              [Page 11]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


5.1.2 The Enc Option

   In order to encrypt and integrity protect CoAP messages, a new CoAP
   option is introduced: the Enc option, indicating the presence of a
   SEM Mode:COAP object in the CoAP message, containing the encrypted
   part of the CoAP message.  Endpoints supporting this scheme MUST
   check for the presence of an Enc option, and verify the SEM as
   described in 5.1.2.2 before accepting a message as valid.

   NOTE: This version of the draft is only considering AEAD algorithms.

5.1.2.1 Option Structure

   The Enc option indicates that certain CoAP Options and Payload (if
   present) are encrypted, integrity and replay protected using a Secure
   Encrypted Message (SEM) with Detached Content (see Section 4.1.2.2).
   The structure of a CoAP message with an Enc option is described in
   Section 5.1.2.4.

   This option is critical, safe to forward, it is not part of a cache
   key, and it is not repeatable.  Table 2 illustrates the structure of
   this option.


   +-----+---+---+---+---+---------+--------+-------------+
   | No. | C | U | N | R | Name    | Format | Length *)   |
   +-----+---+---+---+---+---------+--------+-------------+
   | TBD | x |   | x |   | Enc     | opaque | 0 or 12-TBD |
   +-----+---+---+---+---+---------+--------+-------------+

         C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

                       Table 2: The Enc Option


    *) Length indicates in this case the additional length added to the
   total length of all CoAP options.  If the CoAP message has Payload,
   then the Enc option is empty, otherwise it contains the SEM (see
   Section 5.1.2.4).  In the latter case, the SEM Ciphertext contains
   the encrypted CoAP Options (see Section 5.1.2.3), which are thus
   excluded from plaintext part of the message.  Hence the additional
   length is essentially Length(SEM Header) + Length(SEM Tag).  The
   minimum length is estimated in Appendix C.  The maximum length
   depends on actual message format selected and is TBD.

5.1.2.2 Encryption and Decryption

   A CoAP endpoint composing a message with the Enc option SHALL process



Selander, et al.       Expires September 10, 2015              [Page 12]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   the SEM and produce the SEM Ciphertext and SEM Tag, as defined in
   5.1.2.3 and 5.1.3, analogously to the specification for producing a
   JWE object as described in Section 5.1 of [I-D.ietf-jose-json-web-
   encryption] (cf. Appendix B).  In addition, the sending endpoint
   SHALL process the Sequence Number as described in Section 5.3.

   A CoAP endpoint receiving a message containing the Enc option SHALL
   first recreate the SEM Body as described in Section 5.1.2.3, and then
   decrypt and verify the SEM analogously to the specification for
   verifying a JWE object as describe in Section 5.2 of [I-D.ietf-jose-
   json-web-encryption] (cf. Appendix B).  In addition, the receiving
   endpoint SHALL process the Sequence Number as described in Section
   5.3.

   NOTE: The explicit steps of the protection and verification procedure
   will be included in a future version of this draft.

5.1.2.3 SEM Body

   The SEM Plaintext SHALL consist of the following data, formatted as a
   CoAP message without Header consisting of:

      o all CoAP Options present which are marked as E in Table 3 (see
        Appendix A), in the order as given by the Option number (each
        Option with Option Header including delta to previous E-marked
        Option); and

      o the CoAP Payload, if present, and in that case prefixed by the
        one-byte Payload Marker (0xFF).


   The SEM Additional Authenticated Data SHALL consist of the following
   data, in this order:

      o the 8-bit CoAP header field Code;

      o all CoAP options present which are marked as IP and not marked
        as E in Table 2 (see Appendix A), in the order as given by the
        Option number (each Option with Option Header including delta to
        previous such Option).

5.1.2.4 CoAP Message with Enc Option

   An unprotected CoAP message is encrypted and integrity protected by
   means of an Enc option and a SEM.  The structure and format of the
   protected CoAP message being sent instead of the unprotected CoAP
   message is now described.




Selander, et al.       Expires September 10, 2015              [Page 13]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   The protected CoAP message is formatted as an ordinary CoAP message,
   with the following Header, Options and Payload:

      o The CoAP header SHALL be the same as the unprotected CoAP
        message

      o The CoAP options SHALL consist of the unencrypted options of the
        unprotected CoAP message, and the Enc option.  The options SHALL
        be formatted as in a CoAP message (each Option with Options
        Header including delta to previous unencrypted Option).

      o If the unprotected CoAP message has no Payload then the Enc
        option SHALL contain the SEM with Detached Content.  If the
        unprotected CoAP message has Payload, then the SEM option SHALL
        be empty and the Payload of the CoAP message SHALL be the SEM
        with Detached Content.  The Payload is prefixed by the one-byte
        Payload Marker (0xFF).


5.1.3 SM Tag

        This section describes the SM Tag for Mode:COAP, which applies
        both to SEM and SSM.  The SM Tag is defined in 4.1.3.  If the
        message is a CoAP Request, then EAD SHALL be empty.  If the
        message is a CoAP Response, then EAD SHALL consist of the TID of
        the associated CoAP Request.


5.2 Application Layer Protection

        Referring to examples 1-3 in Section 2 and requirements a and b
        in Section 3, the case of only protecting Payload sent in a
        RESTful protocol using the Secure Message format is now
        discussed.  This is called Secure Message Mode:APPL.

        The sending endpoint SHALL wrap the Payload, and the receiving
        endpoint unwrap the Payload in the relevant SM format (SSM or
        SEM) Mode:APPL.  The SSM (SEM) SHALL be protected (encrypted)
        and verified (decrypted) as described in 5.1.1.2 (5.1.2.2),
        including replay protection as described in section 5.3.

        NOTE: The explicit steps of the protection and verification
        procedure will be included in a future version of this draft.

        For Mode:APPL, the EAD SHALL be empty.  Hence, the SM Tag is
        calculated over the SM Header and SM Body.

        A CoAP message where the Payload is wrapped as a Secure Message



Selander, et al.       Expires September 10, 2015              [Page 14]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


        Mode:APPL object is indicated by setting the option Content-
        Format to application/sm.  A CoAP client may request a response
        containing such a payload wrapping by setting the option Accept
        to application/sm.  (See Section 8.)


5.3 Replay Protection and Freshness

        In order to protect from replay of messages and verify freshness
        of responses, a CoAP endpoint SHALL maintain Transaction
        Identifiers (TIDs) of sent and received Secure Messages (see
        section 4.1.1).

5.3.1 Replay Protection

        An endpoint supporting Secure Message SHALL maintain two TIDs
        and associated security context/key(s) for each other endpoint
        it communicates with, one TID for protecting sent messages, and
        one TID for verifying the received messages.  Depending on use
        case, an endpoint MAY maintain a sliding receive window for
        Sequence Numbers associated to TIDs in received messages,
        equivalent to the functionality described in section 4.1.2.6 of
        [RFC6347].

        Before composing a new message a sending endpoint supporting
        Secure Message SHALL step the Sequence Number of the associated
        send TID and SHALL include it in the SM Header parameter
        Sequence Number as defined in section 4.1.1.  However, if the
        Sequence Number counter wraps, the client must first acquire a
        new TID and associated security context/key(s).  The latter is
        out of scope of this memo.

        A receiving endpoint supporting Secure Message SHALL verify that
        the Sequence Number received in the SM Header is greater than
        the Sequence Number in the TID for received messages (or within
        the sliding window and not previously received) and update the
        TID (window) accordingly.

5.3.2 Freshness

        If a CoAP server receives a valid Secure Message request in
        Mode:COAP, then the response SHALL include the TID of the
        request as EAD, as defined in section 5.1.3.  If the CoAP client
        receives a Secure Message response in Mode:COAP, then the client
        SHALL verify the signature by reconstructing SM Body and using
        the TID of its own associated request as EAD, as defined in
        section 5.1.3.




Selander, et al.       Expires September 10, 2015              [Page 15]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


6. Security Considerations

        In scenarios with proxies, gateways, or caching, DTLS only
        protects data hop-by-hop meaning that all intermediary nodes can
        read and modify information.  The trust model where all
        participating nodes are considered trustworthy is problematic
        not only from a privacy perspective but also from a security
        perspective as the intermediaries are free to delete resources
        on sensors and falsify commands to actuators (such as "unlock
        door", "start fire alarm", "raise bridge").  Even in the rare
        cases where all the owners of the intermediary nodes are fully
        trusted, attacks and data breaches make such an architecture
        weak.

        DTLS protects the entire CoAP message including Header, Options
        and Payload, whereas this proposal only protects selected
        message fields.  DTLS, however, also incurs a large overhead
        cost, e.g. due to the handshake procedure.  While that cost can
        be amortized in scenarios with long lived connections, in cases
        where a device will have connections with varying clients, using
        secured objects instead of session security can provide a
        significant performance gain.

        Secure Message Mode:COAP addresses point to point encryption,
        integrity and replay protection, and freshness of response.
        Payload as well as relevant options and header field Code are
        protected.  It is possible to define unique session keys to
        enable perfect forward secrecy.

        Secure Message Mode:APPL only protects payload and only gives
        replay protection (not freshness), but this allows more use
        cases such as point to multi-point including publish-subscribe,
        reverse proxies and proxy caching of responses.  In case of
        symmetric keys the receiver does not get data origin
        authentication, which requires a digital signature using a
        private asymmetric key.

        Using blockwise transfer [I-D.ietf-core-coap-block], the
        integrity protection as provided by the method described here
        only covers the individual blocks, not the entire request or
        response.  One way to handle this would to allow the Sig or Enc
        option to be repeatable, and in one or several of the block
        transfer carry a MAC or signature that covers the entire request
        or response.

        The Version header field is not integrity protected to allow
        backwards compatibility with future versions of CoAP.
        Considering this, it may in theory be possible to launch a



Selander, et al.       Expires September 10, 2015              [Page 16]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


        cross-version attack, e.g. something analogously to a bidding
        down attack.  Future updates of CoAP would need to take this
        into account.

        The use of sequence numbers for replay protection introduces the
        problem related to wrapping of the counter.  The alternatives
        also have issues: very constrained devices may not be able to
        support accurate time or generate and store large numbers of
        random nonces.  The requirement to change key at counter wrap is
        a complication, but it also forces the user of this
        specification to think about implementing key renewal.

        Independently of message format, and whether the target is
        application layer protection or CoAP message protection, this
        specification needs to be complemented with a procedure whereby
        the client and the server establish the keys used for wrapping
        and unwrapping the Secure Message.  One way to address key
        establishment is to assume that there is a trusted third party
        which can support client and server, such as the Authorization
        Server in [I-D.seitz-ace-problem-description].  The
        Authorization Server may, for example, authenticate the client
        on behalf of the server, or provide cryptographic keys or
        credentials to the client and/or server which can be used in the
        Secure Message exchange.

        The security contexts required for SSM and SEM are different.
        For a SSM, the security context is essentially Algorithm, Key
        Identifier, Sequence Number and Key.  For a SEM it is also
        required to have a unique AEAD Initialization Vector for each
        message.  The AEAD Initialization Vector SHALL be the
        concatenation of a Salt (8 bytes unsigned integer) and the
        Sequence Number.  The Salt SHOULD be established between sender
        and receiver before the message is sent, to avoid the overhead
        of sending it.  For example, the Salt may be established by the
        same means as the keys used to secure the protocol between the
        sender and receiver.  For a SEM, the security context is
        essentially Algorithm, Key Identifier, Salt, Sequence Number and
        Key.

        NOTE: This last paragraph will be moved into the main document
        in a future version of this draft.

7. Privacy Considerations

        End-to-end integrity protection provides certain privacy
        properties, e.g. protection of communication with sensor and
        actuator from manipulation which may affect the personal sphere.
         End-to-end encryption of payload and certain options provides



Selander, et al.       Expires September 10, 2015              [Page 17]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


        additional protection as to the content and nature of the
        message exchange.

        The headers sent in plaintext allows for example matching of CON
        and ACK (CoAP Message Identifier), matching of request and
        response (Token).  Plaintext options could also reveal
        information, e.g. lifetime of measurement (Max-age), or that
        this message contains one data point in a sequence (Observe).


8.  IANA Considerations

        Note to RFC Editor: Please replace all occurrences of "[this
        document]"  with the RFC number of this specification.

        The following entry is added to the CoAP Option Numbers
        registry:

                             +--------+---------+-------------------+
                             | Number | Name    |     Reference     |
                             +--------+---------+-------------------+
                             |  TBD   | Sig     | [[this document]] |
                             +--------+---------+-------------------+
                             |  TBD   | Enc     | [[this document]] |
                             +--------+---------+-------------------+


        NOTE: IANA considerations for Mode is TBD


        This document registers the following value in the CoAP Content
        Format registry established by [RFC7252].


           Media Type: application/sm

           Encoding: -

           Id: 70

           Reference: [this document]


9.  Acknowledgements

        Klaus Hartke has independently been working on the same problem
        and a similar solution: establishing end-to-end security across
        proxies by adding a CoAP option.  The authors would like to



Selander, et al.       Expires September 10, 2015              [Page 18]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


        thank Francesca Palombini for contributing to the discussion and
        giving helpful implementation input to the specification.  We
        are grateful to Malisa Vucinic for providing many helpful
        comments.


10.  References

10.1  Normative References

   [I-D.ietf-jose-json-web-signature]
        Jones, M., Bradley, J., and N. Sakimura,  "JSON Web Signature
        (JWS)", draft-ietf-jose-json-web-signature-41 (work in
        progress), January 2015.

   [I-D.ietf-jose-json-web-encryption]
        Jones, M., and J. Hildebrand, "JSON Web Encryption (JWE)",
        draft-ietf-jose-json-web-encryption-40 (work in progress),
        January 2015.


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

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

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


10.2  Informative References

   [I-D.seitz-ace-problem-description]
              Seitz, L., and G. Selander, "Problem Description for
              Authorization in Constrained Environments", draft-seitz-
              ace-problem-description-02 (work in progress), May 2015.

   [I-D.ietf-ace-usecases]
              Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
              Kumar, "ACE use cases", draft-ietf-ace-usecases-02 (work
              in progress), February 2015.

              [I-D.bormann-jose-cose]
              Bormann, C., "Constrained Object Signing and Encryption



Selander, et al.       Expires September 10, 2015              [Page 19]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


              (COSE)", draft-bormann-jose-cose-00 (work in progress,
              October 2014

   [I-D.ietf-core-coap-block]
              Bormann, C., and Z. Shelby, "Blockwise transfers in CoAP",
              draft-ietf-core-block-17 (work in progress), March 2015.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", FYI
              36, RFC 4949, August 2007, <http://www.rfc-
              editor.org/info/rfc4949>.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009, <http://www.rfc-
              editor.org/info/rfc5652>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.

   [RFC7231]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Semantics and Content",
              RFC 7231, June 2014, <http://www.rfc-
              editor.org/info/rfc7231>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, May 2014, <http://www.rfc-
              editor.org/info/rfc7258>.



Appendix A. Which CoAP Header Fields and Options to Protect

   In the case of CoAP Message Protection (Mode:COAP) as much as
   possible of the CoAP message is protected.  However, not all CoAP
   header fields or options can be encrypted and integrity protected,
   because some are intended to be read or changed by an intermediary
   node.

A.1 CoAP Header Fields

   The CoAP Message Layer parameters, Type and Message ID, as well as
   Token and Token Length may be changed by a proxy and thus SHALL
   neither be integrity protected nor encrypted.  Example 5 in Section 2
   shows that the Code SHALL be integrity protected.  The Version
   parameter SHALL neither be integrity protected nor encrypted (see
   Section 6).

A.2 CoAP Options



Selander, et al.       Expires September 10, 2015              [Page 20]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   This section describes what options need to be integrity protected
   and encrypted.  On a high level, all CoAP options must be encrypted
   by default, unless intended to be read by an intermediate node; and
   integrity protected, unless intended to be changed by an intermediate
   node.

   However, some special considerations are necessary because CoAP
   defines certain legitimate proxy operations, because the security
   information itself may be transported as an option, and because
   different processing is performed for SSM and SEM.

A.2.1 Integrity Protection

   As a general rule, CoAP options which are Safe-to-Forward SHALL be
   integrity protected, with the only exception being Enc and Sig, which
   are the security-providing options.

   The Unsafe options are divided in two categories, those that are
   intended to change in a way that can be reconstructed by the server,
   and those which are not.  The following options are of the latter
   kind and SHALL NOT be integrity protected: Max-Age, Observe, Proxy-
   Scheme.  These options are intended to be changed by a proxy.

   For options related to URI of resource (Uri-Host, Uri-Port, Uri-Path,
   Uri-Query, Proxy-Uri) a Forward Proxy is intended to replace the Uri-
   * options with the content of the Proxy-Uri option.  These options
   are Unsafe, but the Forward Proxy is intended to perform this precise
   operation and we can use this predictability to integrity protect the
   destination endpoint URI, even if the options where the information
   elements of the URI is located is changed by the Proxy.

   This memo makes the full URI located in option 35 (Proxy-Uri) into a
   common denominator for the URI integrity, as described in the
   following.  The following processing applies to a SSM, for SEM see
   next section:

      o If there is a Proxy-Uri present, then the client MUST integrity
        protect the Proxy-Uri option and the Uri-* options MUST NOT be
        integrity protected.

      o If there is no Proxy-Uri option present, then the client SHALL
        compose the full URI from Uri-* options according to the method
        described in section 6.5 of [RFC7252].  The SM Tag is calculated
        on the following message, modified compared to what is sent:

         o All Uri-* options removed

         o A Proxy-Uri option with the full URI included



Selander, et al.       Expires September 10, 2015              [Page 21]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   The server SHALL compose the URI from the Uri-* options according to
   the method described in section 6.5 of [RFC7252].  The so obtained
   URI is placed into a Proxy-Uri option (no. 35), which is included in
   the integrity verification.

A.2.2 Encryption

   All CoAP options MUST be encrypted, except the options below which
   MUST NOT be encrypted:

      o Max-Age, Observe:  This information is intended to be read by a
        proxy.

      o Enc, Sig: These are the security-providing options.

      o Uri-Host, Uri-Port:  This information can be inferred from
        destination IP address and port.

      o Proxy-Uri, Proxy-Scheme:  This information is intended to be
        read by a proxy.

   In the case of a SEM, the Proxy-Uri MUST only contain Uri-Host and
   Uri-Port and MUST NOT contain Uri-Path and Uri-Query because the
   latter options are not intended to be revealed to a Forward Proxy.

A.2.3 Summary

   Table 3 summarizes which options are encrypted and integrity
   protected, if present.

   In a SSM, options marked with "a" and "b" are composed into a URI as
   described above and included as the Proxy-Uri option which is part of
   the SSM Body.  In a SEM, options marked "a" are composed into a URI
   as described above and included as the Proxy-Uri option in the SEM
   Additional Authenticated Data.





   +-----+---+---+---+---+----------------+--------+--------+--------+
   | No. | C | U | N | R | Name           | Format | Length | E | IP |
   +-----+---+---+---+---+----------------+--------+--------+--------+
   |   1 | x |   |   | x | If-Match       | opaque | 0-8    | x | x  |
   |   3 | x | x | - |   | Uri-Host       | string | 1-255  |   | a  |
   |   4 |   |   |   | x | ETag           | opaque | 1-8    | x | x  |
   |   5 | x |   |   |   | If-None-Match  | empty  | 0      | x | x  |
   |   6 |   | x | - |   | Observe        | uint   | 0-3    |   |    |



Selander, et al.       Expires September 10, 2015              [Page 22]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   |   7 | x | x | - |   | Uri-Port       | uint   | 0-2    |   | a  |
   |   8 |   |   |   | x | Location-Path  | string | 0-255  | x | x  |
   |  11 | x | x | - | x | Uri-Path       | string | 0-255  | x | b  |
   |  12 |   |   |   |   | Content-Format | uint   | 0-2    | x | x  |
   |  14 |   | x | - |   | Max-Age        | uint   | 0-4    |   |    |
   |  15 | x | x | - | x | Uri-Query      | string | 0-255  | x | b  |
   |  17 | x |   |   |   | Accept         | uint   | 0-2    | x | x  |
   |  20 |   |   |   | x | Location-Query | string | 0-255  | x | x  |
   |  35 | x | x | - |   | Proxy-Uri      | string | 1-1034 |   | x  |
   |  39 | x | x | - |   | Proxy-Scheme   | string | 1-255  |   |    |
   |  60 |   |   | x |   | Size1          | uint   | 0-4    | x | x  |
   +-----+---+---+---+---+----------------+--------+--------+--------+

         C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable,
         E=Encrypt, IP=Integrity Protect.

         Table 3: Protected CoAP options in Mode=COAP.


Appendix B.  JOSE Objects as Secure Messages

   This section shows how to extend JWS and JWE to Secure Message
   formats (see Section 4.1).  The use of compact serialization is
   assumed.

B.1  JWS as Secure Signed Message

   The JOSE Header of JWS contains the mandatory parameter "alg",
   defined in Section 4.1.1 of [I-D.ietf-jose-json-web-signature], which
   corresponds to the parameter Algorithm of the Secure Message.

   A JWS is a Secure Message if the JOSE Header includes

      o the Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose-
        json-web-signature];

      o the new Parameter "seq" defined in B.3; and

      o the new Parameter "mod" defined in B.4.

   In case of JWS, a SSM with Detached Content consists of the JOSE
   Header and JWS Signature; i.e. no JWS Payload.

B.2  JWE as Secure Encrypted Message

   In case of JWE, the SM Header parameters of a JWE consists of the
   JOSE Header Parameters and JWE Initialization Vector (IV).




Selander, et al.       Expires September 10, 2015              [Page 23]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   The JOSE Header of JWE contains the mandatory parameter "enc",
   defined in Section 4.1.2 of [I-D.ietf-jose-json-web-encryption],
   which corresponds to the parameter Algorithm of the Secure Message.
   The JOSE Header also contains the mandatory parameter "alg", the key
   encryption algorithm, which in the current version of the draft is
   assumed to be equal to "dir" (constant).  It is also assumed that
   plaintext compression (zip) is not used.

   A JWE is a Secure Message if the IV contains the SM Sequence Number,
   and the JOSE Header includes

      o the Parameter "kid" defined in Section 4.1.4 of [I-D.ietf-jose-
        json-web-signature]; and

      o the new Parameter "mod" defined in B.4.

   The IV also contain a Salt (see Section 6).  For JWE it is mandatory
   to include the IV and hence the Salt is sent in each message.

   In case of JWE, a SEM with Detached Content consists of JOSE Header,
   JWE Initialization Vector, JWE Ciphertext and JWE Authentication Tag;
   i.e. no JWE AAD.


B.3 "seq" (Sequence Number) Header Parameter

   The Sequence Number SHALL be a 64-bit unsigned integer in hexadecimal
   representation.  Only the significant bytes are sent (initial bytes
   with zeros are removed).  The start sequence number SHALL be 0.  For
   a given key, any Sequence Number MUST NOT be used more than once.

   The parameter "seq" SHALL be marked as critical using the "crit"
   header parameter (see section 4.1.11 of  [I-D.ietf-jose-json-web-
   signature]), meaning that if a receiver does not understand this
   parameter it must reject the message.

B.4 "mod" (Mode) Header Parameter

   The Mode parameter SHALL be an 8-byte unsigned integer defining
   application specific message format, content and processing.  The
   parameter "mod" SHALL be marked as critical. "mod":"0" indicates
   Mode:APPL which is defined in Section 5.2. "mod":"1" indicates
   Mode:COAP which is defined in Section 5.1.

B.4 The TID consists of the concatenation of SEQ and KID, in that order,
   formatted as in the JOSE.  For "seq" the initial bytes with zeros are
   removed.




Selander, et al.       Expires September 10, 2015              [Page 24]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


Appendix C.  Compact Secure Message

   For constrained environments it is important that the message
   expansion due to security overhead is kept at a minimum.  As an
   attempt to assess what this minimum expansion could be, an optimized
   Secure Message format is defined, tailor-made for this setting.  This
   is intended as a benchmark for generic content formats, to allow an
   informed decision about which Secure Message format to mandate in a
   future version of this draft.

C.1 CSM Format

   This section defines a compact Secure Message format (see Section
   4.1) called the Compact Secure Message (CSM) format, see Figure 4.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | M |    ALG    |   KL    |  SL |             KID               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                            SEQ                                ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                            Body                               ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                            Tag                                ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: Compact Secure Message format

   The CSM Header (see Section 4.1.1.) consists of 2 bytes of fixed
   length parameters and two variable length parameters, Key Identifier
   (KID) and Sequence Number (SEQ).  The Header parameters are (compare
   Table 5):

      o Mode (M).  M=0 indicates Mode:APPL as defined in Section 5.2.
        M=1 indicates Mode:COAP as defined in Section 5.1.  M=2 and M=3
        are reserved for future use.

      o Algorithm (ALG).  This parameter consists of an encoding of the
        ciphersuite used in the Secure Message.  The encoding is TBD.

      o KID Length (KL).  This parameter consist of a length indication
        of the header parameter Key Identifier.  The actual length of
        KID is KL + 1 bytes.

      o SEQ Length (SL).  This parameter consist of a length indication
        of the header parameter Sequence Number.  The actual length of



Selander, et al.       Expires September 10, 2015              [Page 25]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


        SEQ is SL + 1 bytes.

      o Key Identifier (KID).  This parameter identifies the key(s) used
        to protect the Secure Message.  Only the significant bytes are
        sent (initial bytes with zeros are removed).

      o Sequence Number (SEQ).  This parameter consists of the sequence
        number used by the sender of the Secure Message.  Only the
        significant bytes are sent (initial bytes with zeros are
        removed).


           +------+-------------------------+--------------------+
           | Name | Parameter               | Length             |
           +------+-------------------------+--------------------+
           |    M | Mode                    | 2 bits             |
           +------+-------------------------+--------------------+
           |  ALG | Algorithm               | 6 bits             |
           +------+-------------------------+--------------------+
           |   KL | Key Identifier Length   | 5 bits             |
           +------+-------------------------+--------------------+
           |   SL | Sequence Number Length  | 3 bits             |
           +------+-------------------------+--------------------+
           |  KID | Key Identifier          | KL + 1: 1-32 bytes |
           +------+-------------------------+--------------------+
           |  SEQ | Sequence Number         | SL + 1: 1-8 bytes  |
           +------+-------------------------+--------------------+

                  Table 5: CSM Header Parameters.
                  The minimum CSM Header is 4 bytes.

   The TID consists of the concatenation of SEQ and KID, in that order,
   formatted as in the CSM format (initial bytes with zeros are
   removed).

   The content of CSM Body depends on whether it is a SSM or a SEM (see
   Section 4.1.2) which is determined by the Algorithm.  This version of
   the draft focuses on Secure Message with Detached Content.  Hence,
   the SSM Body is empty and the SEM Body consists of the Ciphertext.
   In the former case, the length of the CSM Body is 0.  In the latter
   case, the length of the CSM Body equals the sum of the lengths of the
   present CoAP options marked encrypted in Table 3 and the length of
   the payload of the unprotected CoAP message.

   The CSM Tag contains the MAC/Signature as determined from the
   Algorithm.  The length is determined by ALG.





Selander, et al.       Expires September 10, 2015              [Page 26]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


C.2 Comparison of Secure Message sizes

   This section gives some examples of overhead incurred with JOSE, the
   current proposal for COSE at the time of writing (00-draft), and CSM.
    The goal is not to give exact measurements, but to help the reader
   appreciate the rough order of magnitude of the overhead involved.
   COSE seems to be the most promising approach and CSM should be viewed
   as an attempt to define a lower bound for COSE.

   The comparison is complicated further by the fact that algorithms
   suitable for constrained environments are not supported by JOSE, and
   thereby not by COSE.  This comparison does not consider the
   ciphertext or signed payload expansion due to Base64url encoding in
   JWS/JWE.  This would increase the overhead of JWS and JWE even more.

   The size of the header is shown separately from the size of the
   authentication tag, since JWS/JWE has no provisions for truncating
   it, a feature that could easily be added to the JOSE specifications.
   For CSM the encoding of certain additional algorithms is assumed and
   this could also easily be added to COSE.  An 8-byte kid is used
   throughout all examples.  Finally compact serialization for both JWS
   and JWE is assumed.

   SSM uses HMAC-SHA256, with truncation to 16 bytes.

   For JWS the following header is used:

   {"alg":"HS256", "kid":"a1534e3c5fdc09bd", "seq":"00000142",
   "mod":"0"}

   which encodes to a size of 90 bytes in Base64url, and the 32 bytes of
   HS256 MAC encode to 43 bytes.  The concatenation marks add 2 bytes to
   that in the total overhead.

   The same header in COSE, representing the "kid" as bytes (not as
   string) and the "seq" as positive integer encodes to a size of 35
   bytes, and the MAC would add to 32 bytes to that.  Note that encoding
   the header and the MAC together incurs an additional overhead of 3
   bytes.

   For CSM the same header is represented by 12 bytes.  The MAC could in
   this case safely be truncated to 16 bytes, and a corresponding
   algorithm identifier would need to be defined in the list of
   supported algorithms.

   Table 6 summarizes these results.





Selander, et al.       Expires September 10, 2015              [Page 27]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


               +--------+----------------+----------------+
               | Scheme | Header  | MAC  | Total Overhead |
               +--------+----------------+----------------+
               |   JWS  |  90 B   | 43 B |    135 bytes   |
               +--------+---------+------+----------------+
               |  COSE  |  35 B   | 32 B |     70 bytes   |
               +--------+---------------------------------+
               |   CSM  |  12 B   | 16 B |     28 bytes   |
               +--------+---------------------------------+

               Table 6: Comparison of JWS, COSE, and CSM


   For SEM the use of AES-128-CCM-8 would be ideal, but since this is
   not supported by JOSE, AES-128-GCM is used there instead.

   For JWE it is assumed that the IV is generated from the sequence
   number and some previously agreed upon Salt.  This means it is not
   required to explicitly send the IV in the CSM format, but also that
   the JWE and COSE formats can omit the sequence number.

   The JWE header

   {"alg":"dir", "kid":"a1534e3c5fdc09bd", "enc":"A128GCM", "mod":"0"}

   encodes to a size of 86 bytes in Base64url, while the necessary 12
   byte IV for GCM mode is expanded to 16 bytes by encoding.  The 16
   bytes of the authentication tag expand to 22 bytes.  The
   concatenation marks add 3 bytes to the total overhead.

   In COSE the same header encodes to 40 bytes and the IV and
   authentication tag could be represented as 12 and 16 bytes
   respectively.  Note that encoding the header, the IV and the
   authentication tag together incurs an additional overhead of 2 bytes.

   For CSM this tests uses CCM mode instead of GCM. CCM requires a 16
   byte IV, but is better suited for constrained devices, and for CSM
   there is no impact since the IV can be deduced from the sequence
   number and a previously agreed upon Salt.  The corresponding header
   for AES-128-CCM-8, including the 8 byte sequence number, is
   represented by 12 bytes.

   Table 7 summarizes these results.


            +--------+----------------+-------+----------------+
            | Scheme | Header  | IV   |  Tag  | Total Overhead |
            +--------+----------------+-------+----------------+



Selander, et al.       Expires September 10, 2015              [Page 28]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


            |   JWE  |  86 B   | 16 B |  22 B |    127 bytes   |
            +--------+---------+------+-------+----------------+
            |  COSE  |  40 B   | 12 B |  16 B |     70 bytes   |
            +--------+------------------------+----------------+
            |   CSM  |  12 B   |  0 B |   8 B |     20 bytes   |
            +--------+------------------------+----------------+

               Table 7: Comparison of JWE, COSE, and CSM


Appendix D.  Examples

   This section gives examples of how to use the new options and message
   formats defined in this memo.

D.1 CoAP Message Protection

   This section illustrates the Secure Message Mode:COAP.  The message
   exchange assumes there is a security context established between
   client and server.   One key is used for each direction of the
   message transfer.  The intermediate node detects that the CoAP
   message contains a SM Mode:COAP object (Sig or Enc option is set) and
   thus forwards the message as it cannot serve a cached response.


D.1.1 Integrity protection of CoAP Message

   Here is an example of a PUT request/response message exchange passing
   an intermediate node protected with the Sig option.  The example
   illustrates a client opening a lock and getting a confirmation that
   the lock is opened.  Code, Uri-Path and Payload are integrity
   protected (see Appendix A).

    Client  Proxy  Server
       |      |      |
       |      |      |
       |      |      |
       +----->|      |      Code: 0.03 (PUT)
       | PUT  |      |     Token: 0x8c
       |      |      |  Uri-Path: lock
       |      |      |       Sig: SSM {"mod"="1","seq":"00000142",
       |      |      |            "kid":"a1534e3c5fdc09bd", ...}
       |      |      |   Payload: 1
       |      |      |
       |      +----->|      Code: 0.03 (PUT)
       |      | PUT  |    Token: 0x7b
       |      |      |  Uri-Path: lock
       |      |      |       Sig: SSM {"mod"="1","seq":"00000142",



Selander, et al.       Expires September 10, 2015              [Page 29]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


       |      |      |            "kid":"a1534e3c5fdc09bd", ...}
       |      |      |   Payload: 1
       |      |      |
       |      |      |
       |      |<-----+      Code: 2.04 (Changed)
       |      | 2.04 |     Token: 0x7b
       |      |      |       Sig: SSM {"mod"="1","seq":"000000a6",
       |      |      |            "kid":"5fdc09bda1534e3c", ...}
       |      |      |
       |<-----+      |      Code: 2.04 (Changed)
       | 2.04 |      |     Token: 0x8c
       |      |      |       Sig: SSM {"mod"="1","seq":"000000a6",
       |      |      |            "kid":"5fdc09bda1534e3c", ...}
       |      |      |

            Figure 8: CoAP PUT protected with Sig/SSM (Mode:COAP)

   The Key Identifier is a hint to the receiver indicating which
   security context was used to integrity protect the message, and may
   be used as an identifier for a secret key or a public key.  (It may
   e.g. be the hash of a public key.)

   The server and client can verify that the Sequence Number has not
   been received and used with this key before, and since Mode is COAP,
   the client can additionally verify the freshness of the response,
   i.e. that the response message is generated as an answer to the
   received request message (see Section 5.3).

   The SSM also contains the Tag as specified in the Algorithm (not
   shown).

   This example deviates from encryption (SEM) by default (see Section
   6) just to illustrate the Sig option.  If there is no compelling
   reason why the CoAP message should be in plaintext, then the Enc
   option must be used.

D.1.2 Encryption of CoAP Message

   Here is an example of a GET request/response message exchange passing
   an intermediate node protected with the Enc option.  The example
   illustrates a client requesting a blood sugar measurement resource
   (GET /glucose) and receiving the value 220 mg/dl.  Uri-Path and
   Payload are encrypted and integrity protected.  Code is integrity
   protected only (see Appendix A).

    Client  Proxy  Server
       |      |      |
       |      |      |



Selander, et al.       Expires September 10, 2015              [Page 30]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


       |      |      |
       +----->|      |      Code: 0.01 (GET)
       | GET  |      |     Token: 0x83
       |      |      |       Enc: SEM {"mod"="1","seq":"000015b7",
       |      |      |            "kid":"34e3c5fdca1509bd",
       |      |      |            ["glucose" ... ], ...}
       |      |      |
       |      +----->|      Code: 0.01 (GET)
       |      | GET  |     Token: 0xbe
       |      |      |       Enc: SEM {"mod"="1","seq":"000015b7",
       |      |      |            "kid":"34e3c5fdca1509bd",
       |      |      |            ["glucose" ... ], ...}
       |      |      |
       |      |      |
       |      |<-----+      Code: 2.05 (Content)
       |      | 2.05 |     Token: 0xbe
       |      |      |       Enc:
       |      |      |   Payload: SEM {"mod"="1","seq":"000015b7",
       |      |      |            "kid":"c09bda155fd34e3c",
       |      |      |            [... 220], ...}
       |      |      |
       |<-----+      |      Code: 2.05 (Content)
       | 2.05 |      |     Token: 0x83
       |      |      |       Enc:
       |      |      |   Payload: SEM {"mod"="1","seq":"000015b7",
       |      |      |            "kid":"c09bda155fd34e3c",
       |      |      |            [... 220], ...}
       |      |      |

            Figure 9: CoAP GET protected with Enc/SEM (Mode:COAP).
            The bracket [ ... ] indicates encrypted data.

   Since the request message (GET) does not support payload, the SEM is
   carried in the Enc option.  Since the response message (Content)
   supports payload, the Enc option is empty and the SEM is carried in
   the payload.

   The Key Identifier is a hint to the receiver indicating which
   security context was used to encrypt and integrity protect the
   message, and may be used as an identifier for the AEAD secret key.
   One key is used for each direction of the message transfer.

   The server and client can verify that the Sequence Number has not
   been received and used with this key before, and since Mode:COAP the
   client can additionally verify the freshness of the response, i.e.
   that the response message is generated as an answer to the received
   request message (see Section 5.3).




Selander, et al.       Expires September 10, 2015              [Page 31]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   The SEM also contains the Tag as specified by the Algorithm (not
   shown).


D.2 Application Layer Protection

   This section gives examples that illustrate Secure Message Mode:APPL.
    This mode assumes that only the intended receiver(s) has the
   relevant security context related to the resource.

D.2.1 Proxy Caching

   This example outlines how a proxy forwarding request and response of
   one client can cache a response whose payload is a SEM object, and
   serve this response to another client request, such that both clients
   can verify integrity and non-replay.

    Client1 Proxy  Server

       |      |      |
       |      |      |
       +----->|      |      Code: 0.01 (GET)
       | GET  |      |     Token: 0x83
       |      |      | Proxy-Uri: example.com/temp
       |      |      |
       |      |      |
       |      +----->|      Code: 0.01 (GET)
       |      | GET  |     Token: 0xbe
       |      |      |  Uri-Host: example.com
       |      |      |  Uri-Path: temp
       |      |      |
       |      |      |
       |      |<-----+      Code: 2.05 (Content)
       |      | 2.05 |     Token: 0xbe
       |      |      |   Payload: SEM {"mod"="0","seq":"000015b7",
       |      |      |            "kid":"c09bda155fd34e3c",
       |      |      |            ["471 F"], ...}
       |      |      |
       |<-----+      |      Code: 2.05 (Content)
       | 2.05 |      |     Token: 0x83
       |      |      |   Payload: SEM {"mod"="0","seq":"000015b7",
       |      |      |            "kid":"c09bda155fd34e3c",
              |      |            ["471 F"], ...}
   Client2    |      |
              |      |
       |      |      |
       |      |      |
       +----->|      |      Code: 0.01 (GET)



Selander, et al.       Expires September 10, 2015              [Page 32]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


       | GET  |      |     Token: 0xa1
       |      |      | Proxy-Uri: example.com/temp
       |      |      |
       |<-----+      |      Code: 2.05 (Content)
       | 2.05 |      |     Token: 0xa1
       |      |      |   Payload: SEM {"mod"="0","seq":"000015b7",
       |      |      |            "kid":"c09bda155fd34e3c",
       |      |      |            ["471 F"], ...}

        Figure 10: Proxy caching protected with SEM (Mode:APPL)



D.2.2 Publish-Subscribe

   This example outlines a publish-subscribe setting where the payload
   is integrity and replay protected end-to-end between Publisher and
   Subscriber.  The example illustrates a subscription registration and
   a new publication of birch pollen count of 300 per cubic meters.  The
   PubSub Broker can define the Observe count arbitrarily (as could any
   intermediary node, even in Mode:COAP), but cannot manipulate the
   Sequence Number without being noticed.

   Sub-    PubSub- Publisher
   scriber Broker

       |      |      |
       +----->|      |      Code: 0.01 (GET)
       | GET  |      |     Token: 0x72
       |      |      |  Uri-Path: ps
       |      |      |  Uri-Path: birch-pollen
       |      |      |   Observe: 0 (register)
       |      |      |
       |      |      |
       |<-----+      |      Code: 2.05 (Content)
       | 2.05 |      |     Token: 0x72
       |      |      |   Observe: 1
       |      |      |   Payload: SSM {"mod"="0","seq":"000015b7",
       |      |      |            "kid":"c09bda155fd34e3c",
       |      |      |            ["270"], ...}
       |      |      |
       |      |      |
       |      |      |
       |      |<-----+      Code: 0.03 (PUT)
       |      | PUT  |     Token: 0x1f
       |      |      |  Uri-Path: ps
       |      |      |  Uri-Path: birch-pollen
       |      |      |   Payload: SSM {"mod"="0","seq":"000015b8",



Selander, et al.       Expires September 10, 2015              [Page 33]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


       |      |      |            "kid":"c09bda155fd34e3c",
       |      |      |            ["300"], ...}
       |      |      |
       |      +----->|      Code: 2.04 (Changed)
       |      | 2.04 |     Token: 0x1f
       |      |      |
       |      |      |
       |<-----+      |      Code: 2.05 (Content)
       | 2.05 |      |     Token: 0x72
       |      |      |   Observe: 2
       |      |      |   Payload: SSM {"mod"="0","seq":"000015b8",
       |      |      |            "kid":"c09bda155fd34e3c",
       |      |      |            ["300"], ...}

        Figure 11: Publish-subscribe protected with SSM (Mode:APPL)

   This example deviates from encryption (SEM) by default (see Section
   6) just to illustrate the SSM in Mode:APPL.  If there is no
   compelling reason why the payload should be in plaintext, then SEM
   must be used.

D.2.3 Transporting Authorization Information

   This example outlines the transportation of authorization information
   from a node producing (Authorization Server, AS) to a node consuming
   (Resource Server, RS) such information.  Authorization information
   may for example be an authorization decision with respect to a Client
   (C) accessing a Resource to be enforced by RS.  See Section 4.4-4.5
   of [I-D.seitz-ace-problem-description].

   Here, C is clearly not trusted with modifying the information, but
   may need to be involved with mediating the authorization information
   to the RS, for example, because AS and RS does not have direct
   connectivity.  So end-to-end security is required and object security
   is a natural candidate (cf. "Access Tokens").

   This example considers the authorization information to be
   encapsulated in a SEM Mode:APPL object, generated by AS.  How C
   accesses the SSM is out of scope for this example, it may e.g. be
   using CoAP.  C then requests RS to configure the authorization
   information in the SEM by doing PUT to /authorization.  This
   particular resource has a default access policy that only new
   messages signed by AS are authorized.  RS thus verifies the integrity
   and sequence number by using the existing security context for the
   AS, and responds accordingly, a) or b), see Figure 12.

    Authz           Resource
    Server  Client  Server



Selander, et al.       Expires September 10, 2015              [Page 34]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


       |      |      |
       |      |      |        Client access Access Token:
       +- - ->|      |     SEM {"mod"="0","seq":"00000142",
       |      |      |          "kid":"c09bda1534e3c5fdc09bd", ...}
       |      |      |
       |      |      |
       |      +----->|      Code: 0.03 (PUT)
       |      | PUT  |     Token: 0xac
       |      |      |  Uri-Path: authorization
       |      |      |   Payload: SEM {"mod"="0","seq":"00000142",
       |      |      |            "kid":"c09bda1534e3c5fdc09bd", ...}

   a)
       |      |      |
       |      |<-----+      Code: 2.04 (Changed)
       |      | 2.04 |     Token: 0xac
       |      |      |

   b)
       |      |      |
       |      |<-----+      Code: 4.01 (Unauthorized)
       |      | 4.01 |     Token: 0xac
       |      |      |

        Figure 12: Protected Transfer of Access Token = SEM (Mode:APPL)


Authors' Addresses

   Goeran Selander
   Ericsson
   Farogatan 6
   16480 Kista
   SWEDEN
   EMail: goran.selander@ericsson.com

   John Mattsson
   Ericsson
   Farogatan 6
   16480 Kista
   SWEDEN
   EMail: john.mattsson@ericsson.com

   Ludwig Seitz
   SICS Swedish ICT AB
   Scheelevagen 17
   22370 Lund
   SWEDEN



Selander, et al.       Expires September 10, 2015              [Page 35]


INTERNET DRAFT          Object Security for ACE            March 9, 2015


   EMail: ludwig@sics.se


















































Selander, et al.       Expires September 10, 2015              [Page 36]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/