Skip to main content

October 27, 2014
draft-selander-ace-object-security-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Göran Selander , John Preuß Mattsson , Ludwig Seitz
Last updated 2014-10-27
Replaced by draft-ietf-core-object-security, draft-ietf-core-object-security, RFC 8613
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-selander-ace-object-security-00
ACE Working Group                                            G. Selander
Internet-Draft                                               J. Mattsson
Intended Status: Standards Track                                Ericsson
Expires: April 30, 2015                                         L. Seitz
                                                        SICS Swedish ICT
                                                                        
                                                        October 27, 2014

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

   We present a format for data object security in Constrained
   Application Protocol CoAP, i.e. protection of individual request and
   response messages between client and server.

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) 2014 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 April 30, 2015                 [Page 1]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   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. The JWS Option  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1 Option Structure . . . . . . . . . . . . . . . . . . . . . .  6
     3.2 Integrity Protection and Verification  . . . . . . . . . . .  7
     3.3 JOSE Header  . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.3.1 "seq" (Sequence Number) Header Parameter . . . . . . . .  8
       3.3.2 Message Sequence Numbers . . . . . . . . . . . . . . . .  8
     3.4 JWS Payload  . . . . . . . . . . . . . . . . . . . . . . . .  9
   4. Proxy Behavior  . . . . . . . . . . . . . . . . . . . . . . . . 10
   5. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1 GET  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2 POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
   7. Privacy Considerations  . . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1  Normative References  . . . . . . . . . . . . . . . . . . . 14
     9.2  Informative References  . . . . . . . . . . . . . . . . . . 15
   Appendix A. Design Considerations  . . . . . . . . . . . . . . . . 16
     A.1 Reducing Message Size  . . . . . . . . . . . . . . . . . . . 16
     A.2 REST Considerations  . . . . . . . . . . . . . . . . . . . . 17
     A.3 Protection of CoAP Message Fields  . . . . . . . . . . . . . 17
       A.3.1 CoAP Header  . . . . . . . . . . . . . . . . . . . . . . 18
       A.3.2 CoAP Options . . . . . . . . . . . . . . . . . . . . . . 18
   Appendix B. Replay Protection - Special Cases  . . . . . . . . . . 20
     B.1 "isi" (Integrity Scope Indication) Header Parameter  . . . . 21
       B.1.1 "isi":"01" . . . . . . . . . . . . . . . . . . . . . . . 21
       B.1.2 "isi":"10" . . . . . . . . . . . . . . . . . . . . . . . 21
       B.1.3 "isi":"11" . . . . . . . . . . . . . . . . . . . . . . . 21
       B.1.4 "isi":"00" . . . . . . . . . . . . . . . . . . . . . . . 22
     B.2 Advance Caching  . . . . . . . . . . . . . . . . . . . . . . 22
       B.2.1 Acquiring server sequence numbers  . . . . . . . . . . . 22
       B.2.2 Proxy caching  . . . . . . . . . . . . . . . . . . . . . 23
     B.3 Observe  . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25

 

Selander, et al.         Expires April 30, 2015                 [Page 2]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

 

Selander, et al.         Expires April 30, 2015                 [Page 3]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

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 exchange.  However, transport
   layer security is problematic in use cases built on store-and-forward
   or publish-subscribe, which require end-to-end security.  DTLS offers
   only hop-by-hop security and requires trusted intermediaries. 
   Moreover DTLS incurs a noticeable overhead in constrained devices due
   to the handshake procedure.

   This memo presents an object security approach for secure messaging
   in constrained environments based on the protection of individual
   request and response messages.  

   In this version of the draft we focus on end-to-end integrity
   protection, which addresses some of the use cases e.g. where it is
   necessary for endpoints or proxies to verify that the message is
   authentic.  We plan to add encryption in a later version since this
   is essential for other use cases.

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 including "resource", "representation", etc. are to be
   understood as used in HTTP [RFC7231] and CoAP [RFC7252].

   Terminology for constrained environments including "constrained
   device", "constrained-node network", "class 1", etc. are defined in
   [RFC7228].

   Client, Resource Server, and Authorization Server are defined in [I-
   D.seitz-ace-problem-description].  When we just use the term server,
   we refer to the Resource Server.

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

Selander, et al.         Expires April 30, 2015                 [Page 4]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   NOTE: A CoAP message has header, options and payload.  A JWS object
   has header, payload, and signature.  Hence the unqualified terms
   "header" and "payload" have two meanings.  

   The JWS option is a CoAP option defined in this memo.

2. Background

   The background for this work is provided by the use cases and problem
   description in [I-D.seitz-ace-usecases] and [I-D.seitz-ace-problem-
   description].  The specific part of the problem statement we address
   in this memo relates to sections 4.6 - 4.7 of [I-D.seitz-ace-problem-
   description].

   The overall objective in securing access requests is that only
   authorized requests are granted and that the message content is
   protected (according to requirements of the particular use case)
   between client and server.  As explained in the introduction, we are
   focusing on an efficient solution to protect requests and response
   end-to-end in constrained environments supporting e.g. store-and-
   forward use cases.  To give a few examples, end-to-end integrity
   protection can be used to:

      o prevent manipulation and allow multiple clients to verify sensor
        readings stored in un-trusted intermediary nodes;

      o protect configuration data or firmware updates stored in an
        intermediate node, e.g. because the device was not connected at
        the time of the update request;

      o protect transport of authorization information ("access tokens")
        to sleepy devices.

   The IETF has defined standardized content formats for
   cryptographically protected data (e.g. CMS [RFC5652], JWS [I-D.ietf-
   jose-json-web-signature]).  Other more compact representations are in
   discussion in the IETF, see section 5 of [JoseWgIetf90].  One
   potential approach for defining data object security for constrained
   environments is to wrap application layer data using such a format
   and sending it as payload in a CoAP message.  An alternative approach
   is to instead build data object security into the CoAP message
   format.  The second approach is the one we propose in this memo. 

   As is explained in Appendix A and B this approach enables some
   attractive features compared to transport of protected data on top of
   CoAP, including:  

 

Selander, et al.         Expires April 30, 2015                 [Page 5]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

      o Protection of certain CoAP header and option fields

      o Compliance with REST

      o Reduction of message size, by avoiding unnecessary duplication
        of data in payload and header/options

      o Reuse of CoAP specific mechanisms for caching and forwarding

   Independently of approach, the format needs to be complemented with a
   description how the client and the server establish the keys, and how
   the keys are used for wrapping and unwrapping the secured data
   object.  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.draft-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 to
   secure the request/response procedure.

   We emphasize that the solution sketched in this memo can be combined
   with DTLS [RFC6347], thus enabling end-to-end integrity protection of
   CoAP payload, certain CoAP headers and options, in combination with
   hop-by-hop protection of the entire CoAP messages during transport
   between end-points and intermediary devices.

3. The JWS Option

   In order to integrity protect individual request and responses, as
   well as request-response message exchanges, we introduce a new CoAP
   option, the JWS option, essentially containing a digital signature or
   Message Authentication Code (MAC) of the CoAP message.  Endpoints
   supporting this scheme MUST check for the presence of this option,
   and that the signature/MAC is valid before accepting a message as
   valid.  The design considerations leading up to this solution are
   presented in Appendix A.

3.1 Option Structure

   The JWS option indicates that certain CoAP header fields, options,
   and payload (if present) are integrity protected using JWS [I-D.ietf-
   jose-json-web-signature].  The JWS option SHALL contain a detached
   signature (JOSE Header and JWS Signature) as described in [I-D.ietf-
   jose-json-web-signature] Appendix F, using JWS Compact Serialization
   (see section 3.1 of [I-D.ietf-jose-json-web-signature]).

   This option is critical, safe to forward, it is not part of a cache
 

Selander, et al.         Expires April 30, 2015                 [Page 6]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   key, and it is not repeatable.  Table 1 illustrates the structure of
   this option.

   +-----+---+---+---+---+---------+--------+-----------+
   | No. | C | U | N | R | Name    | Format |  Length   |
   +-----+---+---+---+---+---------+--------+-----------+
   | TBD | x |   | x |   |   JWS   | opaque | 125-256 B |
   +-----+---+---+---+---+---------+--------+-----------+

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

                       Table 1: The JWS Option

3.2 Integrity Protection and Verification

   A CoAP endpoint composing a message using the JWS option SHALL
   process the JWS Payload and JOSE Header, defined in the following
   sections, according to the specification for producing the
   signature/MAC of a JWS object as described in Section 5.1 of the JWS
   specification [I-D.ietf-jose-json-web-signature].

   A CoAP endpoint receiving a message containing the JWS option SHALL
   first recreate the JWS Payload as described in Section 3.4, and then
   verify the signature/MAC as defined in Section 5.2 of the JWS
   specification [I-D.ietf-jose-json-web-signature].

3.3 JOSE Header

   Even if a signature/MAC of a received message can be verified, the
   message may still be old, e.g. a replay of a previous message.  As is
   noted in section 10.10 of [I-D.ietf-jose-json-web-signature]), one
   way to thwart replay attacks is to include a unique message
   identifier and having the recipient verify that the message has not
   been previously received or acted upon.  

   As unique JWS message identifier we propose to use the combination of
   a unique key identifier and a sequence number.  The JOSE Header of a
   JWS option SHALL contain either one of the "kid", "x5t", or
   "x5t#S256" header parameters to uniquely identify the key.  In this
   section we define a new JOSE Header parameter "seq" (Sequence Number)
   enumerating the JWS objects/CoAP messages generated using the key
   referenced in the JOSE Header.  In addition to replay protection, we
   want to be able to verify that a CoAP response is associated to a
   previously made CoAP request in order to ensure the freshness of a
   received response.  For this purpose we require the responder to
 

Selander, et al.         Expires April 30, 2015                 [Page 7]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   include the sender's sequence number and key identifier in the JWS
   Payload.

   The header field and procedures described in this section could have
   been replaced by similar procedures based on time-stamps, if the
   devices in question had reliable and synchronized clocks.  

3.3.1 "seq" (Sequence Number) Header Parameter

   The "seq" header parameter contains the sequence number associated to
   the key used to integrity protect the JWS object.  The sequence
   number SHALL be a 32-bit number in hexadecimal representation
   including leading zeroes.  The start sequence number SHALL be 0.  For
   a given key, any sequence number MUST NOT be used in "seq" more than
   once.

   The "seq" header parameter SHALL be marked as critical using the
   "crit" header parameter of JWS (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 JWS. 

3.3.2 Message Sequence Numbers

   In order to protect from replay and verify freshness of responses, a
   CoAP endpoint maintains sequence numbers.  

   A CoAP client supporting the JWS option SHALL store one sequence
   number per key it uses to protect the integrity of a message.  A CoAP
   server supporting the JWS option SHALL store on sequence number per
   key it uses to verify the integrity of a message.  Depending on use
   case, the endpoints MAY maintain a sliding receive window for
   sequence numbers associated to key identifiers in received messages,
   equivalent to the functionality described in section 4.1.2.6 of
   [RFC6347].

   Before composing a new message with a JWS option, a CoAP client SHALL
   step the associated sequence number and SHALL include it in the "seq"
   header parameter as defined in 3.3.1.  However, if the sequence
   number counter wraps, the client must first acquire a new key.  (The
   latter is out of scope of this memo.)

   A CoAP server supporting the JWS option SHALL verify the sequence
   number received in "seq" by comparing with the stored associated
   sequence number (or sliding window).  If a CoAP server receives a
   valid request with a JWS option, then the response SHALL include the
   sequence number and key identifier of the request in the JWS Payload
   as defined in section 3.4.
 

Selander, et al.         Expires April 30, 2015                 [Page 8]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   If the CoAP client receives a response message with a JWS option,
   then the client SHALL generate the JWS Payload using the key
   identifier and the sequence number of its own associated request as
   defined in section 3.4

   In Appendix B, we show how this can be extended to account for proxy
   caching functionality as well as the CoAP Observe option.

3.4 JWS Payload

   The JWS Payload is type-value-length encoded and consists of:

      o the CoAP header field Code;

      o all CoAP options present which are marked as signed in Table 2
        (see Appendix A); and

      o the CoAP payload (if any). 

      o if the message is a response, the sequence number "seq" from the
        request (see section 3.3.1);

      o if the message is a response, the key identifier from the
        request ("kid", "x5t" or "x5t#256", see section 3.3.2)

   To integrity protect the CoAP options requires the generation of a
   standalone representation of each option (without the option delta,
   see section 3.1 of [RFC7252]).  The following procedure SHALL be
   applied to generate an option representation:  Calculate the option
   number and represent it as a 8-bit unsigned integer.  Then
   concatenate the 8-bit option value with a 16-bit unsigned integer in
   network byte order indicating the length of the Option Value, in
   bytes.  Finally concatenate the option value (if any is present) with
   that bit-string.

   For a request, the JWS Payload SHALL be the concatenation of the 8-
   bit CoAP header field Code, the CoAP option representations (as
   described in the previous paragraph) which are marked signed in Table
   2 (see Appendix A) in the same order as given in the request, and
   finally a 16-bit unsigned integer in network byte order indicating
   the length of the CoAP payload, in bytes, and the CoAP payload of the
   message (if any present) as represented in the request.  

   For a reply, the JWS Payload SHALL be generated as above, but
   additionally the server SHALL append the concatenation of the 32-bit
   sequence number from the request, an 8-bit unsigned integer in
   network byte order indicating the length of the key identifier, in
 

Selander, et al.         Expires April 30, 2015                 [Page 9]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   bytes, and the key identifier from the request.

4. Proxy Behavior

   As we target end-to-end security, we must ensure that the solution is
   compliant with message handling in intermediary nodes. 

   CoAP distinguishes between two types of proxies; forward-proxies,
   which are explicitly selected by clients, and reverse-proxies, which
   handle requests transparently to the client.  Since the client is not
   aware of any nodes behind a reverse-proxy, it perceives the reverse-
   proxy as an origin server which terminates the end-to-end security.

   Forward-proxies are in scope and we cover two cases here: the CoAP-
   CoAP forward proxy and the HTTP-CoAP cross-proxy.  For CoAP-CoAP
   forward proxies, the JWS option SHALL be forwarded.  

   Using an HTTP-CoAP proxy requires that the client understands how to
   formulate a CoAP request.  In the "Default Mapping", the Target CoAP
   URI is appended as-is to a base URI [I-D.ietf-core-http-mapping]. 
   Analogously to a CoAP-CoAP forward proxy, the relevant options are
   copied from the HTTP URI.  The JWS option SHALL be transported in the
   HTTP URI as a Query:

      ?JWS=...

   where the dots "..." should be replaced by the JWS option.

   Proxies not supporting the JWS option handle messages containing a
   JWS option according to the CoAP option processing rules, i.e. they
   will not process such messages themselves (since the option is marked
   "critical") but they will forward such messages (since the option is
   marked as "safe-to-forward").

5. Examples

   In this section we give examples in order to illustrate and clarify
   the intended use of the JWS option.

5.1 GET

   This example outlines a GET message exchange forwarded by a proxy. 
   Integrity protection applies to Code, Uri-Path, Payload and other
   message fields.

 

Selander, et al.         Expires April 30, 2015                [Page 10]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

    Client  Proxy  Server
       |      |      |
       |      |      |
       +----->|      |  Header: GET (Code=0.01) Token: 0x8c
       | GET  |      |  Uri-Path: "temperature" 
       |      |      |  JWS: (JOSE Header: { "seq":"00000142" } ...)
       |      |      |
       |      |      |
       |      +----->|  Header: GET (Code=0.01) Token: 0x7b
       |      | GET  |  Uri-Path: "temperature" 
       |      |      |  JWS: (JOSE Header: { "seq":"00000142" } ...)
       |      |      |
       |      |      |
       |      |<-----+  Header: 2.05 Content (Code=2.05) Token: 0x7b
       |      | 2.05 |  JWS: (...)
       |      |      |  Payload: "23.1 C"   
       |      |      |  
       |      |      |
       |<-----+      |  Header: 2.05 Content (Code=2.05) Token: 0x8c
       | 2.05 |      |  JWS: (...) 
       |      |      |  Payload: "23.1 C"
       |      |      |     

   where the signature and other details are omitted. The complete JOSE
   header for the request is:

    {"alg":"HS256",
     "kid":"a1534e3c5fdc09bd",
     "crit":["seq"],
     "seq":"00000142"
    }

   and the JWS Payload consists of: 

   * 000 00001 (the header field code GET) 

   * 0x0B (option number 11, Uri-Path)

   * 0x000B (length of the option value: 11)

   * "temperature" (the option value)  

   * (Other options are omitted for brevity.)

   and for the response is:

    {"alg":"HS256",
 

Selander, et al.         Expires April 30, 2015                [Page 11]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

     "kid":"c1a6fa909502dd82"
    }       

   The "kid" is a hint to the receiver indicating which key was used to
   secure the JWS, 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.  Even if "kid"
   are different in request and response, it may reference the same
   symmetric key.

   The JWS Payload for the response consists of: 

   * 010 00101 (the header field code 2.05 Content) 

   * 0x0006 (length of the payload: 6)

   * "23.1 C" (the payload value)  

   * "a1534e3c5fdc09bd" (the key identifier from the request)

   * 0x00000142  (the sequence number from the request

5.2 POST

   This example outlines a POST message exchange forwarded by a proxy. 
   Integrity protection applies to Code, Uri-Path, Payload and other
   message fields.

    Client  Proxy  Server 
       |      |      |  
       |      |      | 
       |      |      |     
       +----->|      |  Header: POST (T=CON, Code=0.02, MID=0xf124)
       | POST |      |  Token: 0x8c
       |      |      |  Uri-Path: "lock" 
       |      |      |  JWS: (JOSE Header: { "x5t":"a9095...a32a7b", 
       |      |      |          "seq":"0000036f", ...} ...)
       |      |      |  Payload: "open"
       |      |      |   
       |      +----->|  Header: POST (T=CON, Code=0.02, MID=0xf124)
       |      | POST |  Token: 0x8c
       |      |      |  Uri-Path: "lock" 
       |      |      |  JWS: (JOSE Header: { "x5t":"a9095...a32a7b", 
       |      |      |          "seq":"0000036f", ...} ...)
       |      |      |  Payload: "open" 
       |      |      |
       |      |<-----+  Header: 2.04 Changed (T=ACK, Code=2.04,
       |      | 2.04 |      MID=0xf124) Token: 0x8c
       |      |      |  JWS: (JOSE Header: { "x5t":"9f2a...8520", 
 

Selander, et al.         Expires April 30, 2015                [Page 12]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

       |      |      |    ...} ...) 
       |      |      |  
       |<-----+      |  Header: 2.04 Changed (T=ACK, Code=2.04,
       | 2.04 |      |       MID=0xf124) Token: 0x8c
       |      |      |  JWS: (JOSE Header: { "x5t":"9f2a...8520",
       |      |      |    ...} ...) 
       |      |      | 

   Note that in this case the client and the server are using X.509
   certificates, which need to be available to both participants, so
   that they can look up the right public key using the thumbprint.  If
   the proxy also has the public keys available, it can perform
   signature verification and discard invalid messages, in order to
   offload work from the client and server.

6. Security Considerations

   In scenarios with proxies, gateways, or caching, DTLS only protects
   data hop-by-hop meaning that all intermediary nodes can 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 makes
   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, 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. 

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

   Since the Version header field is not integrity protected, in case of
   future versions of CoAP it may in theory be possible to launch a
   cross-version attack, e.g. something analogously to a bidding down
   attack. Future updates of CoAP should take this into account.
 

Selander, et al.         Expires April 30, 2015                [Page 13]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

7. Privacy Considerations

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

   As a next step we plan to extend this scheme by add encryption for
   addressing other privacy concerns, such as confidentiality of
   personal data and prevention of pervasive monitoring.

8.  IANA Considerations

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

                        +--------+---------+-------------------+
                        | Number | Name    |     Reference     |
                        +--------+---------+-------------------+
                        |  TBD   | JWS     | [[this document]] |
                        +--------+---------+-------------------+

   The following entries are added to the JSON Web Signature and
   Encryption Header Parameters registry for Header Parameter names:

      o  Header Parameter Name: "seq"
      o  Header Parameter Description: Message sequence number
      o  Header Parameter Usage Location(s): JWS
      o  Change Controller: IESG
      o  Specification Document(s): Section 3.3.1 of 
         [[ this document ]]]

9.  References

9.1  Normative References

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

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

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
 

Selander, et al.         Expires April 30, 2015                [Page 14]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

              Application Protocol (CoAP)", RFC 7252, June 2014.

9.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-01 (work in progress), July 2014. 

   [I-D.seitz-ace-usecases]
              Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
              Kumar, "ACE use cases", draft-seitz-ace-usecases-01 (work
              in progress), July 2014. 

              [JoseWgIetf90]
              Minutes of the JOSE WG meeting at IETF 90,
              http://www.ietf.org/proceedings/90/minutes/minutes-90-jose

   [I-D.ietf-core-http-mapping]
              Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
              E. Dijk, "Guidelines for HTTP-CoAP Mapping
              Implementations", draft-ietf-core-http-mapping-05 (work in
              progress), October 2014.

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

   [I-D.ietf-jose-cookbook]
              M. Miller, "Examples of Protecting Content using
              JavaScript Object Signing and Encryption (JOSE)", draft-
              ietf-jose-cookbook-05 (work in progress), October 2014.

   [I-D.ietf-core-observe]
               K. Hartke, "Observing Resources in CoAP", draft-ietf-
              core-observe-14 (work in progress), June 2014.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", FYI
              36, RFC 4949, August 2007.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, May 2014.

   [RFC7231]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
 

Selander, et al.         Expires April 30, 2015                [Page 15]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

              Transfer Protocol (HTTP/1.1): Semantics and Content",
              RFC 7231, June 2014.

Appendix A. Design Considerations 

   In this section we provide some motivation for the chosen solution. 
   The pedagogical attempt of this section is by means of iterative
   modifications of the trivial solution consisting of a secure object
   carried in the payload.

A.1 Reducing Message Size

   We noted in Section 2 that end-to-end security may be provided on
   application layer on top of CoAP by including, say, a JWS object [I-
   D.ietf-jose-json-web-signature] in the CoAP payload.  The JWS
   represents content secured with digital signatures or Message
   Authentication Codes (MACs) using JavaScript Object Notation (JSON)
   based data structures.

   However, if the content of the JWS object is independent from the
   CoAP message, it does not integrity protect CoAP header fields or
   options.  To address this, one solution is to repeat certain
   information, contained within CoAP header fields and options, in the
   JWS object.  However, this would not be optimal since some data would
   be duplicated in header/options and payload.  For example, a resource
   identifier would be transported both as a CoAP URI-Path/URI-Query
   option (to comply with the CoAP message format), and in the payload
   (to integrity protect the intended resource which the request is
   targeting).

   Fortunately, there is a solution to this problem known as "detached
   content" (Appendix F, [I-D.ietf-jose-json-web-signature]) a.k.a.
   "detached signature" ([I-D.ietf-jose-cookbook]).  As is described in
   these references, the detached signature is constructed from "a JWS
   object in the normal fashion using a representation of the content as
   the payload, but then delete the payload representation from the
   JWS". With the outcome that "the resulting JWS object do not include
   the integrity protected content. Instead, the application is expected
   to locate it elsewhere."

   Using JWS detached signature together with a specification for what
   message fields should be included in the digital signature or MAC, we
   can get integrity protection of relevant CoAP message fields without
   unnecessary duplication of message fields.

 

Selander, et al.         Expires April 30, 2015                [Page 16]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

A.2 REST Considerations

   As we saw in the previous section, a JWS detached signature in the
   CoAP payload would provide integrity protection and optimized message
   format.  However, not all CoAP request and response messages support
   payload.  E.g. GET and DELETE requests may not have defined body
   semantics and that could to some extent violate RESTful design. 
   Furthermore, some CoAP response messages are not allowed to have
   payload or are only intended to carry resource representations.

   We therefore propose to pass a JWS detached signature as a new CoAP
   option, as described in section 3.

   NOTE: The choice of JWS is based on its relative compactness.  Even
   compacter formats, as recently has been discussed [JoseWgIetf90],
   would be favorable.

A.3 Protection of CoAP Message Fields

   Having motivated how a signature or MAC should be carried, we now
   turn to the question what information should be integrity protected.

   Integrity protection should cover relevant message fields that are
   not supposed to change between client and server.  This must also
   take into account that there may be intermediary devices caching
   and/or forwarding requests or responses.

   In this section we study the message format (see Figure 1) and list
   the fields that need to be integrity protected as well as describe
   the procedure.   Clearly the payload should be protected, but not all
   headers fields or options.

    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     
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver| T |  TKL  |      Code     |          Message ID           |   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |   Token (if any, TKL bytes) ...                                   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |   Options (if any) ...                                            
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |1 1 1 1 1 1 1 1|    Payload (if any) ...                           
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: CoAP message Format

 

Selander, et al.         Expires April 30, 2015                [Page 17]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

A.3.1 CoAP Header

   We now describe which fields in the CoAP header that needs to be
   protected.

      o Version (Ver):  This field is fixed for a given implementation. 
        However, to allow backward compatibility with future versions of
        CoAP, Version SHALL NOT be integrity protected.

      o Type (T) and Message ID:  These fields are only relevant on CoAP
        messaging layer.  Different Types (CON, NON, ACK, RST) or
        Message IDs may be used to transport the same request/response
        and hence SHALL NOT be integrity protected.

      o Token Length (TKL) and Token:  CoAP is using the Token as a
        request identifier to match responses against requests.  In the
        case of multi-hop using intermediaries, the Token may be
        different between the hops and is not preserved end-to-end. 
        These fields SHALL NOT be integrity protected.

      o Code:  This field is an 8-bit unsigned integer, identifying
        request method or response code which should not change and
        hence SHALL be integrity protected.

   Summarizing: Only the Code header field is included in the JWS
   Payload of the JWS option.

A.3.2 CoAP Options

   The options need to be integrity protected as follows:

      o ETag:  This option defines resource local identifier of
        representation and hence SHALL be integrity protected. 

      o If-Match, If-None-Match:  These options are conditional control
        logic for requests which thus SHALL be integrity protected.

      o Observe:  This option is elective and unsafe so may be discarded
        by a proxy. Hence it SHALL NOT be integrity protected.

      o Location-Path, Location-Query:  These options are essentially
        the identifier of a new resource and hence SHALL be integrity
        protected.

      o Accept, Content-Format:  These options indicates representation
        format of payload and hence SHALL be integrity protected.
 

Selander, et al.         Expires April 30, 2015                [Page 18]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

      o Max-Age:   The Max-Age option in the response is intended to be
        decreased by an intermediary device caching the response. 
        Moreover it is elective and unsafe to forward. It SHALL NOT be
        integrity protected.

      o Size1:  This option provides size information about the resource
        representation in a request and SHALL be integrity protected. 

      o Proxy-Uri: This option contains the request URI, which
        identifies the requested resource, and hence it SHALL be
        integrity protected, see last item in this list.

      o Proxy-Scheme: This option contains the intended scheme to be
        used by a proxy, and hence it SHALL be integrity protected, see
        also last item in this list.

      o Uri-Host, Uri-Port, Uri-Path and Uri-Query:  In a request to an
        origin server the request URI is decomposed into these options. 
        In the case of requests made to an origin server, these options
        contain the complete information about the request URI.  On the
        other hand in a proxy request, the request URI is specified by
        the client as a string in the Proxy-Uri option.  The proxy which
        makes this a request to the origin server decomposes the Proxy-
        Uri into Uri-Host, Uri-Port, Uri-Path, and Uri-Query options. 
        However, the full URI can be reconstructed at any involved
        endpoint.

        To allow integrity verification of the request URI, the client
        and forward proxies SHALL use explicit Uri-Host and Uri-Port
        options.  The server SHALL compose the URI from options
        according to the method described in section 6.5 of the CoAP
        specification [RFC7252].  The so obtained URI is put into a
        Proxy-Uri option (no. 35), which is included in the integrity
        calculation.

   Table 2 summarizes which options to include in the integrity
   calculation.  Options marked with "x" are included.  Options marked
   with "d" are composed into a URI as described above and included as
   the Proxy-Uri option for the purpose of calculating the signature. 
   (Proxy-Uri and the options marked with "d" are mutually exclusive.)

   +-----+---+---+---+---+----------------+--------+--------+--------+  
   | No. | C | U | N | R | Name           | Format | Length | Signed |
   +-----+---+---+---+---+----------------+--------+--------+--------+  
   |   1 | x |   |   | x | If-Match       | opaque | 0-8    |    x   |  
   |   3 | x | x | - |   | Uri-Host       | string | 1-255  |    d   |  
 

Selander, et al.         Expires April 30, 2015                [Page 19]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   |   4 |   |   |   | x | ETag           | opaque | 1-8    |    x   |  
   |   5 | x |   |   |   | If-None-Match  | empty  | 0      |    x   | 
   |   6 |   | x | - |   | Observe        | uint   | 0-3    |        | 
   |   7 | x | x | - |   | Uri-Port       | uint   | 0-2    |    d   |  
   |   8 |   |   |   | x | Location-Path  | string | 0-255  |    x   |  
   |  11 | x | x | - | x | Uri-Path       | string | 0-255  |    d   |  
   |  12 |   |   |   |   | Content-Format | uint   | 0-2    |    x   |  
   |  14 |   | x | - |   | Max-Age        | uint   | 0-4    |        |  
   |  15 | x | x | - | x | Uri-Query      | string | 0-255  |    d   |  
   |  17 | x |   |   |   | Accept         | uint   | 0-2    |    x   | 
   |  20 |   |   |   | x | Location-Query | string | 0-255  |    x   |  
   |  35 | x | x | - |   | Proxy-Uri      | string | 1-1034 |    x   |  
   |  39 | x | x | - |   | Proxy-Scheme   | string | 1-255  |    x   |  
   |  60 |   |   | x |   | Size1          | uint   | 0-4    |    x   |  
   +-----+---+---+---+---+----------------+--------+--------+--------+
   | TBD | x |   | x |   | JWS            | opaque | 125-256|        | 
   +-----+---+---+---+---+----------------+--------+--------+--------+

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

            Table 2: Which options to integrity protect. 

Appendix B. Replay Protection - Special Cases

   In this section we show how one can use the JWS option to handle
   advance caching and subscribe (CoAP Observe) responses to GET
   requests.  Please note that this is work in progress.

   The general problem introduced in these settings is that there is no
   longer an end-to-end challenge-response protocol:

      o An intermediary forward proxies may cache a response to a
        corresponding GET request, and serve that response to another
        client's GET request.

      o A server may produce multiple responses to one GET Observe
        request, i.e. there is no unique matching request for each
        response.

   This induces a number of changes:

      o In general, we can't hope to prove freshness, but can still
        protect from replayed responses using server sequence numbers,
        indicated with the "seq" header parameter.

      o However, to define an initial server sequence number we propose
 

Selander, et al.         Expires April 30, 2015                [Page 20]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

        to rely on an end-to-end challenge-response protocol. 

      o A response message containing a challenge, is neither available
        nor meaningful to other clients.  Since we are using both server
        sequence numbers and challenge-response, we need to indicate
        which of these freshness/replay protection parameter is used in
        a given response.  We introduce an indicator in section B.1.

      o Since the resource identifier cannot be inferred from a default
        CoAP response message when there is no associated integrity
        protected challenge, we need to add this explicitly when we rely
        on server sequence numbers.

      o Note that since there may be multiple receivers of a response,
        this scenario makes most sense with asymmetric crypto, i.e. that
        the signature of the response can verified using the public key
        of the server.  

B.1 "isi" (Integrity Scope Indication) Header Parameter

   We introduce a new JOSE Header parameter indicating in requests, what
   freshness/replay parameter to integrity protect, and in responses,
   what freshness/replay protection parameter is integrity protected.

   The "isi" header parameter is a 2-bit indication of what value shall
   be or is integrity protected in the response.  The "isi" header
   parameter SHALL be marked as critical.

B.1.1 "isi":"01"   

   This indicates that the key identifier and sequence number of the
   request is placed in the JWS Payload of the response, and thus
   integrity protected.  There is no server sequence number in the
   response.  This the same procedure described in section 3.

B.1.2 "isi":"10"   

   This indicates that the server sequence number is in the "seq" header
   parameter of the response, and thus integrity protected.  The key
   identifier and sequence number of the request is not included in the
   JWS payload.  The response SHALL contain the request URI in the
   proxy-URI option.

B.1.3 "isi":"11"   

   This is a combination of the previous two.  This indicates that the
   key identifier and sequence number of the request is placed in the
   JWS Payload, and the server sequence number is placed in the "seq"
 

Selander, et al.         Expires April 30, 2015                [Page 21]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   header parameter of the response.  Thus both parameters are integrity
   protected.  

B.1.4 "isi":"00"

   This value is reserved for future use. 

B.2 Advance Caching

B.2.1 Acquiring server sequence numbers

    Client  Proxy  Server
       |      |      |
       |      |      |  
       |      |      |
       +----->|      |  Header: GET (Code=0.01) Token: 0x8c
       | GET  |      |  Uri-Path: "temperature" 
       |      |      |  JWS: (JOSE Header: { "kid":"b00d4272ae41433e", 
       |      |      |                       "seq":"00000142",
       |      |      |                       "isi":"11",     
       |      |      |                              ...} ...)
       |      |      |
       |      +----->|  Header: GET (Code=0.01) Token: 0x4b
       |      |  GET |  Uri-Path: "temperature" 
       |      |      |  JWS: (JOSE Header: { "kid":"b00d4272ae41433e", 
       |      |      |                       "seq":"00000142", 
       |      |      |                       "isi":"11",    
       |      |      |                              ...} ...)
       |      |      |
       |      |      |
       |      |<-----+  Header: 2.05 Content (Code=2.05) Token: 0x4b
       |      | 2.05 |  JWS: (JOSE Header: { "kid":"c1a6fa909502dd82",
       |      |      |                       "seq":"000000D7",
       |      |      |                       "isi":"11",    
       |      |      |                              ...} ...)
       |      |      |  Payload: "23.1 C"    
       |      |      |
       |      |      |
       |<-----+      |  Header: 2.05 Content (Code=2.05) Token: 0x8c
       | 2.05 |      |  JWS: (JOSE Header: { "kid":"c1a6fa909502dd82",
       |      |      |                       "seq":"000000D7",
       |      |      |                       "isi":"11",    
       |      |      |                              ...} ...)
       |      |      |  Payload: "23.1 C" 
       |      |      | 

 

Selander, et al.         Expires April 30, 2015                [Page 22]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

   In this case, the proxy recognizes that it cannot serve a verifiably
   fresh cached answer to the client and therefore obtains a new one by
   forwarding the client's request.  

   The CoAP server SHALL step the associated sequence number and SHALL
   include it in the "seq" header parameter.  However, if the sequence
   number counter wraps, the server must first acquire a new key.  (The
   latter is out of scope of this memo.) 

   The server includes the key identifier and sequence number of the
   request in the JWS payload as described in section 3.  The client can
   thus verify the freshness of the response and conclude the sequence
   number is fresh.  Here either symmetric and asymmetric keys may be
   used.

B.2.2 Proxy caching

    Client  Proxy  Server
       |      |      |
       |      |      |
       |      +----->|  Header: GET (Code=0.01) Token: 0x4c
       |      | GET  |  Uri-Path: "temperature"
       |      |      |  JWS: (JOSE Header: { "kid":"a1534e3c5fdc09bd",
       |      |      |                       "seq":"00000070",  
       |      |      |                       "isi":"10",    
       |      |      |                              ...} ...)
       |      |      |
       |      |<-----+  Header: 2.05 Content (Code=2.05) Token: 0x4c
       |      | 2.05 |  JWS: (JOSE Header: { "kid":"c1a6fa909502dd82",
       |      |      |                       "seq":"000000DA",
       |      |      |                       "isi":"10",    
       |      |      |                              ...} ...)
       |      |      |  Payload: "22.7 C"
       |      |      |  
       |      |      |
       |      |      |
       +----->|      |  Header: GET (Code=0.01) Token: 0x8d
       | GET  |      |  Uri-Path: "temperature" 
       |      |      |  JWS: (JOSE Header: { "kid":"b00d4272ae41433e", 
       |      |      |                       "seq":"00000044", 
       |      |      |                       "isi":"10",    
       |      |      |                              ...} ...)
       |      |      |
       |<-----+      |  Header: 2.05 Content (Code=2.05) Token: 0x8d
       | 2.05 |      |  JWS: (JOSE Header: { "kid":"c1a6fa909502dd82",
       |      |      |                       "seq":"000000DA",
       |      |      |                       "isi":"10",    
 

Selander, et al.         Expires April 30, 2015                [Page 23]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

       |      |      |                              ...} ...)
       |      |      |  Payload: "22.7 C" 
       |      |      | 

   In this case the proxy requests a response which includes the server
   sequence number but not the key identifier and the sequence number of
   the request.  The response also contains the resource URI for
   identification of resource.  

   When the proxy gets a request with an "isi" header parameter that is
   not required to be forwarded it is matched against the cached
   responses, and since a corresponding response is present, it is
   forwarded to the client.

   This setting makes most sense in the case of response "kid"
   identifies a public key of the server.

B.3 Observe

   In certain cases, there may be more than one response associated to a
   request, e.g. in the case of the CoAP option Observe ([I-D.ietf-core-
   observe]).  To securely distinguish between multiple responses and
   protect from replay of responses we propose the following approach:

   Client  Server
       |      |
       |      |
       +----->|  Header: GET (Code=0.02) Token: 0x4a
       | GET  |  Uri-Path: "temperature" 
       |      |  Observe: register
       |      |  JWS: (JOSE Header: { "kid":"a1534e3c5fdc09bd",     
       |      |                       "seq":"0000006F",
       |      |                       "isi":"11", ...} ...)
       |      |  
       |      |
       |<-----+  Header: 2.05 Content (Code=2.05) Token: 0x4a
       | 2.05 |  Observe: 12 
       |      |  JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", 
       |      |                       "seq":"000001D6", 
       |      |                       "isi":"11", ...} ...)
       |      |  Payload: "22.9 C"
       |      |
       |<-----+  Header: 2.05 Content (Code=2.05) Token: 0x4a
       | 2.05 |  Observe: 44 
       |      |  JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", 
       |      |                       "seq":"000001D7", 
       |      |                       "isi":"10", ...} ...)
 

Selander, et al.         Expires April 30, 2015                [Page 24]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

       |      |  Payload: "22.8 C"
       |      |
       |<-----+  Header: 2.05 Content (Code=2.05) Token: 0x4a
       | 2.05 |  Observe: 60 
       |      |  JWS: (JOSE Header: { "kid":"c1a6fa909502dd82", 
       |      |                       "seq":"000001D8",
       |      |                       "isi":"10", ...} ...)
       |      |  Payload: "23.1 C"
       |      |

   The "GET Observe: register" request SHALL contain the "isi" header
   parameter with value "11".  The response to the "GET Observe:
   register" shall contain the the "isi" header parameter with value
   "11".  This response SHALL NOT be cached.  GET Observe responses
   without a matching request SHALL contain the the "isi" header
   parameter with value "10", i.e. the response SHALL contain server
   sequence value "seq" in JOSE Header and no request key identifier and
   sequence number in the JWS payload.

   This procedure for replay protection of Observe also works in the
   presence of proxies by combining the procedures in section B.1 and
   B.2.  This applies both to the cases of a client observing a resource
   through a proxy, and a proxy observing a resource to keep its cache
   up to date (section A.2 of [I-D.ietf-core-observe]).

Authors' Addresses

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

   Ludwig Seitz
   SICS Swedish ICT AB
   Scheelevagen 17
   22370 Lund
   SWEDEN
   EMail: ludwig@sics.se

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

Selander, et al.         Expires April 30, 2015                [Page 25]
INTERNET DRAFT          Object Security for ACE         October 27, 2014

Selander, et al.         Expires April 30, 2015                [Page 26]